GHSA-h73q-4w9q-82h4
Hackney: Cross-origin Redirect Leaks Authorization, Cookie, and Request Body
Blast Radius
hackneyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The HTTP/3 redirect handler in src/hackney_h3.erl forwards the original request headers (Authorization, Cookie, Proxy-Authorization) and, for 307/308 responses, the original request body to the redirect target without checking whether the target host matches the origin. When follow_redirect is enabled and a server responds with a cross-origin Location, hackney delivers the caller's credentials verbatim to the attacker-controlled host. The main hackney HTTP/1 client has maybe_strip_auth_on_redirect/2 (the fix for CVE-2018-1000007); the H3 client was added later without it.
Details
In src/hackney_h3.erl, handle_redirect/11 (line 165) extracts the redirect target from the server-controlled Location header via get_redirect_location/1 and resolves it with resolve_redirect_url/2, which accepts any absolute http:// or https:// URL. It then calls do_request_with_redirect/8 passing the original Headers list unchanged. For 307/308 responses, redirect_method/2 preserves the original method and body, so the POST body is also forwarded.
No comparison is made between the original URL's scheme, host, or port and the redirect target. The downstream connect/3 opens a new QUIC connection to whatever the Location header named, and build_request_headers/4 serializes the unmodified headers into the QPACK-encoded request.
PoC
- Issue an HTTP/3 POST to an attacker-controlled origin with
follow_redirect => trueand anAuthorization: Bearer ...header. - The attacker's server responds
307 Location: https://other.host/collect. - hackney opens a new connection to
other.hostand re-sends the original headers and body, including the bearer token and anyCookieheaders.
Impact
Credential and request-body disclosure to attacker-controlled origins. Affects hackney 3.1.1 through 4.0.0 when using the HTTP/3 client with follow_redirect enabled. Any upstream that is malicious, compromised, or reachable via DNS/MITM can steal session tokens, bearer credentials, and POST bodies. CVSS v4.0: 6.0 (MEDIUM).
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | hackney | ≥ 3.1.1&&< 4.0.1 | 4.0.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hackney. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update hackney to 4.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h73q-4w9q-82h4 is resolved across your whole dependency graph.
Workarounds
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 pinpoints whether GHSA-h73q-4w9q-82h4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h73q-4w9q-82h4. 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-h73q-4w9q-82h4 in your dependencies?
O3 detects GHSA-h73q-4w9q-82h4 across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.