CVE-2026-35459 is a server-side request forgery flaw in pyLoad, scored 9.1 (Critical) in the CVE record. It bypasses the fix for CVE-2026-33992 because redirect targets are not checked. The GitHub advisory lists pyload-ng 0.5.0b3.dev97 as the patched version, so upgrade to it.
What's affected
- Product: pyLoad (pip package
pyload-ng) - Affected versions: 0.5.0b3.dev96 and earlier, per the record. The GitHub advisory lists "up to 0.5.0b3"
- Fixed version: pyload-ng 0.5.0b3.dev97, per the GitHub advisory
- Condition: an authenticated user with the ADD permission
The record scores the flaw with no privileges required, while the advisory text says authentication with ADD permission is needed and that this lowered its own rating from Critical to High. Treat the permission requirement as real but do not rely on it. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
pip show pyload-ng
For container setups, check the image tag and run the same command inside the container. If the version is older than 0.5.0b3.dev97, you are in the affected range.
Also check which users hold the ADD permission, since that is the entry point the advisory describes.
What to do now
- Upgrade pyload-ng to 0.5.0b3.dev97 or later.
- Review which accounts have the ADD permission and remove it where it is not needed.
- Keep the web interface off the public internet, or put it behind a VPN or access proxy.
- If pyLoad runs on a cloud host, make sure the instance metadata service requires session tokens, so a request forgery cannot read credentials easily.
- Review recent downloads for URLs you do not recognise.
Why it matters
Server-side request forgery, CWE-918, means the server can be made to fetch a URL chosen by someone else, including addresses that only the server can reach. pyLoad had added a check on the first URL of a download after the earlier CVE. The advisory explains that the download library follows up to ten redirects, and the redirect targets never went through that check.
This is a common pattern. A filter applied at one point is bypassed through a path that bypasses the filter. A good fix validates every hop, or does not follow redirects blindly.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is the earlier SSRF fixed by this patch too?
The advisory describes this one as a bypass of the earlier fix. Upgrading to a release at or after 0.5.0b3.dev97 addresses the redirect path described.
Why does cloud metadata come up?
The advisory lists cloud metadata endpoints and internal network services as places a forged request could reach.
Sources
Last reviewed: 19 October 2026.
