Vulnerabilities

Vulnerability · CVE-2026-97200

Unbounded response body buffering and decompression in hackney

Published Oct 26, 2026 · catalog updated Oct 26, 2026 · Unbounded response body buffering

Last checked Nov 5, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-97200. EPSS is 0.56%. Act only if a listed version of Unbounded response body buffering is installed.

Severity

Unknown—

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.56%

Remediation

Advisory link

Affected products

Hex hackney

## Summary Allocation of Resources Without Limits or Throttling vulnerability in in benoitc hackney allows a malicious HTTP server to exhaust client memory via an oversized or highly compressed response body. and return the whole response body, and nothing bounds how much the connection process buffers. Any server the client requests can trigger it. and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With the buffered body is then inflated in one step with or , which return the whole output at once. This issue affects hackney: from 2.0.0-beta.1 before 4.9.0. ## Details **1. Unbounded accumulation.** with a body, and after , read the response in through , which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size. **2. One-step decompression.** With hackney sends . Once the body is complete, dispatches on to ( ) or ( ). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4. ## Proof of concept 1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire. 2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers with , a matching the stream, , and the stream as body. 3. From a node running a vulnerable hackney, call against that listener. 4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without , drives the node out of memory. ## Impact A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory. ## Workarounds Leave disabled (the default). Without it n