GHSA-6cp8-v795-jr2j
Hackney has an infinite loop on non-token byte at start of an Alt-Svc entry
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
CVE-2026-47066 is an infinite loop (CWE-835) in hackney's Alt-Svc response header parser (src/hackney_altsvc.erl). When an HTTP server returns an Alt-Svc header whose value begins with a non-token byte (e.g. !, @, =, ;), the parser enters a tight tail-recursive loop that pins an Erlang scheduler at 100% CPU and permanently hangs the calling connection process. Because the parser is invoked synchronously on every HTTP response, any attacker-controlled origin can trigger the hang with a single-byte header value.
Details
1. Parser dispatch
parse_and_cache/3 is called inside the hackney connection process on each HTTP response. It collects all Alt-Svc header values via collect_altsvc_headers/1, concatenates them, and passes the result to parse/1, which calls parse_entries(Header, []).
2. Failed token consumption
parse_entries/2 → parse_entry/1 → parse_protocol/1 → parse_token(Data, <<>>). The function parse_token/2 pattern-matches leading bytes: alphanumeric, -, _, whitespace, and comma all have explicit clauses. Any other byte (e.g. !) falls through to the catch-all:
parse_token(Rest, <<>>) -> {undefined, Rest}.
This returns the input unchanged — no byte is consumed.
3. No-progress loop
parse_entry propagates {undefined, Rest} back to parse_entries/2, which calls skip_comma(Rest). Because the first byte is not ,, skip_comma also returns Rest unchanged. parse_entries then recurses with the identical buffer:
parse_entries(Data, Acc) % Data identical to previous iteration
Erlang tail recursion never preempts on a pure CPU loop, so the scheduler is pinned and the process never yields or returns.
4. Root cause
parse_entries/2 has no guard that detects zero-byte progress after a failed parse_entry call and no fallback to advance past the offending byte.
PoC
- Start an HTTP server that responds with the header
Alt-Svc: !(any single non-token byte suffices). - Issue any HTTP GET request via hackney to that server:
hackney:request(get, "http://attacker.example/", [], <<>>, []) - Observe that the call never returns; the Erlang scheduler hosting the connection process is pinned at 100% CPU indefinitely.
Alternatively, call the parser directly: hackney_altsvc:parse(<<"!">>) — the process hangs immediately.
Impact
Denial of service via unbounded CPU consumption. Any application using hackney 2.0.0-beta.1 through 4.0.0 that connects to attacker-controlled HTTP endpoints is affected. No authentication is required; a single response header byte is sufficient to hang the connection process. Fixed in hackney 4.0.1. CVSS v4.0 score: 8.7 (HIGH).
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | hackney | ≥ 2.0.0&&< 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-6cp8-v795-jr2j 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-6cp8-v795-jr2j 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-6cp8-v795-jr2j. 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-6cp8-v795-jr2j in your dependencies?
O3 detects GHSA-6cp8-v795-jr2j across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.