GHSA-q8jg-fgj4-fphf
Fix: benoitc/hackney@ce0109eGHSA-q8jg-fgj4-fphf is a Uncontrolled Resource Consumption vulnerability in hackney. O3 Security confirms whether GHSA-q8jg-fgj4-fphf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Hackney has unbounded buffer accumulation in WebSocket
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-q8jg-fgj4-fphf.
Real-World Exposure
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 WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption across three distinct code paths. In each case, an attacker-controlled WebSocket server can exhaust the connecting process's memory without any authentication or special client configuration.
Details
1. Handshake response buffer (read_handshake_response/3)
The function accumulates received bytes into a growing buffer waiting for \r\n\r\n. The per-receive timeout resets on every chunk, so a server that trickles bytes indefinitely without completing the HTTP upgrade response grows the buffer until OOM. No total-size cap exists.
2. Frame payload accumulation (parse_payload/9, parse_active_payload/8)
parse_payload/9 (lines 816–817 and 825–826) appends each received chunk into a Buffer binary via <<Buffer/binary, MoreData/binary>> whenever the frame parser returns {more, ...}. parse_active_payload/8 does the same in active mode by appending each incoming tcp/ssl message to #ws_data.buffer. RFC 6455 permits payload lengths up to 2⁶³-1 bytes, and neither path validates the declared Len against any limit. The recv_timeout applies per chunk, not to the whole frame, so a slow trickle never triggers it.
3. Fragmentation buffer (frag_buffer)
The frag_buffer field of #ws_data{} accumulates continuation frames. A server that sends an unbounded stream of non-final (nofin) fragments without ever sending a final (fin) frame grows frag_buffer without bound.
PoC
- Stand up a WebSocket server and connect to it with hackney's WebSocket client.
- Trigger any of the three paths: (a) never send
\r\n\r\nduring the handshake; (b) announce a very large frame payload and dribble bytes slowly; (c) send an endless stream ofnofincontinuation frames. - Observe the hackney process's memory growing until the BEAM OOM-kills it or the node crashes.
Impact
Denial of service via unbounded memory consumption. Affects hackney 2.0.0 through 4.0.0 for any application using the WebSocket client against an attacker-controlled server. No authentication or special configuration is required on the client side. CVSS v4.0: 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-q8jg-fgj4-fphf 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-q8jg-fgj4-fphf 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-q8jg-fgj4-fphf. 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-q8jg-fgj4-fphf in your dependencies?
O3 detects GHSA-q8jg-fgj4-fphf across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.