GHSA-m74m-f7cr-432x — pyload-ng
Fix: pyload/pyload@b76b6d4GHSA-m74m-f7cr-432x is a Server-Side Request Forgery (SSRF) vulnerability in pyload-ng. No vendor fix is recorded yet; mitigation options are listed below.
pyLoad: Server-Side Request Forgery via Download Link Submission Enables Cloud Metadata Exfiltration
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-m74m-f7cr-432x.
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.
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
Summary
PyLoad's download engine accepts arbitrary URLs without validation, enabling Server-Side Request Forgery (SSRF) attacks. An authenticated attacker can exploit this to access internal network services and exfiltrate cloud provider metadata. On DigitalOcean droplets, this exposes sensitive infrastructure data including droplet ID, network configuration, region, authentication keys, and SSH keys configured in user-data/cloud-init.
Details
The vulnerability exists in PyLoad's download package functionality (/api/addPackage endpoint), which directly passes user-supplied URLs to the download engine without validating the destination. The affected code in src/pyload/webui/app/blueprints/api_blueprint.py:
@bp.route("/addPackage", methods=["POST"], endpoint="add_package")
@login_required
def add_package():
name = flask.request.form["add_name"]
links = flask.request.form["add_links"].split("\n")
# ... validation omitted ...
api.add_package(name, links, dest) # No URL validation
The download engine in src/pyload/core/managers/download.py accepts any URL scheme and initiates HTTP requests to arbitrary destinations, including internal network addresses and cloud metadata endpoints.
Proof of Concept
Live Demo Instance: http://143.244.141.81:8000
Credentials: pyload / pyload
- Login into the pyload application
- Navigate to package tab and enter the package name and fill the Link section with the following URL
http://169.254.169.254/metadata/v1.json
- Now navigate to Files section and download the link.
- It was observed that we are able to Read the Digital Ocean Metadata
The downloaded v1.json file contains sensitive cloud infrastructure data:
- Droplet ID: Unique identifier for the instance
- Network Configuration: Public/private IP addresses, VPC topology
- Authentication Keys: Cloud provider auth tokens
- SSH Keys: Public keys configured in droplet metadata
- Region and Datacenter: Infrastructure location
Impact
Vulnerability Type: Server-Side Request Forgery (SSRF)
CVSS Score: 7.7 - 9.1 (High to Critical, depending on cloud deployment)
Affected Systems
- All PyLoad installations (version 0.5.0 and potentially earlier)
- Critical Impact on cloud deployments (AWS EC2, DigitalOcean, Google Cloud, Azure) where metadata contains:
- IAM credentials (AWS)
- SSH private keys (configured in user-data)
- API tokens and secrets
- Database credentials stored in cloud-init
Attack Requirements
- Valid PyLoad user account (any role - ADMIN or USER)
- Network connectivity to PyLoad instance
Security Impact
- Cloud Metadata Theft: Complete exfiltration of instance metadata
- Lateral Movement: Discovery and enumeration of internal network services
- Credential Exposure: Theft of cloud IAM credentials, SSH keys, API tokens
- Infrastructure Mapping: Network topology, IP addressing, service discovery
Remediation
Implement URL validation in the download engine:
- Whitelist allowed URL schemes (http/https only)
- Block requests to private IP ranges (RFC 1918, link-local addresses)
- Block cloud metadata endpoints (169.254.169.254, metadata.google.internal, etc.)
- Implement request destination validation before initiating downloads
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | pyload-ng | all versions | No fix |
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.
Remediation status
No patched version of pyload-ng has shipped for GHSA-m74m-f7cr-432x yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
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 GHSA-m74m-f7cr-432x can be triaged on real exposure rather than presence alone.
Tailored to GHSA-m74m-f7cr-432x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-m74m-f7cr-432x in your dependencies?
O3 Security finds GHSA-m74m-f7cr-432x across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.