Server-Side Request Forgery (SSRF) via HTTP Redirect Bypass in pyLoad – Incomplete CVE-2026-33992 Fix

Vulnerability Description

This is a Server-Side Request Forgery (CWE-601/CWE-918) vulnerability resulting from an incomplete security patch. The original CVE-2026-33992 added hostname validation to BaseDownloader.download() to block SSRF attacks targeting private IP ranges. However, the fix only inspects the initial URL's hostname before pycurl processes the request. Since pycurl is configured with FOLLOWLOCATION=1 and MAXREDIRS=10 enabled, and no CURLOPT_REDIR_PROTOCOLS restriction exists, the underlying HTTP client automatically follows up to 10 redirects without re-validating against the SSRF filter. An attacker can supply a legitimate external URL that redirects to internal addresses (169.254.x.x, 10.x.x.x, 172.16-31.x.x, 127.x.x.x, or cloud metadata endpoints like 169.254.169.254), allowing access to internal services, cloud metadata APIs, or network resources.

Proof-of-Concept Significance

The disclosed PoC (incomplete in the advisory) demonstrates a redirect server returning a 302 Location header pointing to an internal address. The significance lies in proving that: (1) the SSRF validation is incomplete—it operates only on pre-request state, not on the effective request target; (2) the vulnerability is reliable—HTTP redirects are fundamental protocol behavior automatically handled by pycurl; (3) exploitation requires authentication (ADD permission), limiting scope but not eliminating risk in shared hosting or compromised accounts. The advisory explicitly confirms pycurl follows redirects, making this a logic flaw rather than a library limitation.

Detection Guidance

Log Indicators:

• HTTP requests to external domains immediately followed by successful connections to private IP ranges (check source logs and pycurl/network debug output)
• Multiple 30x/40x responses followed by 200 responses in download logs
• Asymmetric DNS resolution: hostname resolves to public IP, but effective request connects privately
• Pattern: ADD permission user submits URL with attacker-controlled or compromised redirect domain

Network IDS/IPS: Flag outbound connections from pyLoad to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, 127.0.0.0/8) from the application container. Alert on multiple sequential HTTP requests from single user action within ADD permission context.

Application Monitoring: Instrument _download() calls to log all HTTP status codes (including 30x) and final effective URL. Compare initial URL hostname against final request IP address.

Mitigation Steps

Immediate Workarounds (Temporary):

• Disable redirect following: Set pycurl.FOLLOWLOCATION to 0 in http_request.py:114
• Reduce redirect limit: Set pycurl.MAXREDIRS to 0
• Restrict redirect protocols to HTTPS only via pycurl.REDIR_PROTOCOLS (value: pycurl.PROTO_HTTPS)

Proper Patch (Required):

• Move SSRF validation into redirect-handling logic: validate each intermediate redirect target (Location header) before following
• Use pycurl.REDIR_PROTOCOLS to restrict redirects to HTTPS only, blocking legacy HTTP redirects
• Implement a custom redirect handler that validates hostnames against the SSRF allowlist before each redirect
• Add pycurl.FOLLOWLOCATION = 0 and handle redirects manually in application code with per-redirect validation

Configuration Hardening:

• Restrict ADD permission to trusted users only
• Implement network-level egress filtering: deny outbound connections to private IP ranges from the pyLoad process
• Use cloud security groups/network policies to block access to metadata APIs (169.254.169.254)

Risk Assessment

Likelihood of Exploitation: Moderate-to-High. The vulnerability requires authentication (ADD permission), but many pyLoad deployments run on shared systems or have permissive user roles. The fix is simple to exploit (one HTTP 302 redirect), making it attractive to threat actors post-compromise. The incomplete security patch suggests this is an active bypassable vulnerability—not theoretical.

Threat Actor Interest: High. Cloud environments and containerized deployments store sensitive credentials in metadata APIs (AWS IMDSv2, GCP Metadata Server, Azure IMDS), making SSRF a high-value attack vector. Insiders or compromised accounts with ADD permissions provide a low-friction path to exploitation.

Prevalence: Unknown, but confirmed in live pyLoad deployments. Real-world exploitation likelihood increases if CVE-2026-33992 was widely publicized; attackers testing the fix for bypasses is expected behavior.