pyLoad patches authenticated SSRF enabling cloud metadata theft

TL;DR — An authenticated SSRF in pyLoad can be abused to fetch internal URLs (including cloud metadata endpoints), enabling high-impact secret and infrastructure-data exfiltration from the host.

What happened

pyLoad is a free, open-source download manager written in Python that exposes a web UI/API to submit links for the server to retrieve.

CVE-2026-33992 describes a Server-Side Request Forgery (SSRF) issue where pyLoad’s download engine accepts arbitrary URLs without destination validation. An authenticated attacker can use this to make the pyLoad server initiate requests to internal network services and to cloud provider metadata endpoints.

The CVE record specifically calls out DigitalOcean droplets: retrieving metadata can expose sensitive infrastructure data such as droplet ID, network configuration, region, authentication keys, and SSH keys configured via user-data/cloud-init.

This is the classic “feature-driven SSRF” pattern: any app that fetches attacker-influenced URLs can become an internal-network pivot and a cloud-credential theft primitive, especially when deployed with broad egress and default metadata reachability.

Who is impacted

• Deployments running pyload versions < 0.5.0b3.dev97.
• Environments where untrusted users can obtain valid pyLoad credentials (the CVE describes an authenticated attacker).
• Cloud-hosted installs are at higher risk if instance metadata endpoints are reachable from the pyLoad process.

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Version 0.5.0b3.dev97 contains a patch."

• Treat this as an egress-control and trust-boundary issue as much as a patching issue: restrict which users can submit download URLs, and constrain outbound network access from the pyLoad service where feasible.
• If you operate pyLoad on cloud infrastructure, explicitly block access from the application to cloud metadata endpoints and other internal-only destinations (this reduces blast radius even after patching).
• If you suspect exposure, review application logs and outbound proxy/VPC flow logs for requests to link-local metadata IPs and internal hostnames, then rotate any credentials that could have been reachable from the instance.