EEF-CVE-2026-97200: Unbounded response body buffering and decompression in hackney
Allocation of Resources Without Limits or Throttling vulnerability in hackneyconn in benoitc hackney allows a malicious HTTP server to exhaust client memory via an oversized or highly compressed response body. hackney:request/5 and hackney:body/1 return the whole response body, and nothing bounds how much the connection process buffers. Any server the client requests can trigger it.
hackneyconn:readfullbody/2 and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With {autodecompress, true} the buffered body is then inflated in one step with zlib:gunzip/1 or zlib:inflate/2, which return the whole output at once.
This issue affects hackney: from 2.0.0-beta.1 before 4.9.0.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using affected hackney versions that request HTTP resources from untrusted or potentially malicious servers are exposed. Any server the client requests can send a response designed to exhaust the client's memory.
What does an attacker need to exploit it?
An attacker needs to control, or be able to influence responses from, an HTTP server requested by the application. No client-side privileges or user interaction are required; the server can send an oversized response or a highly compressed response body.
Are compressed responses a distinct risk?
Yes. When auto_decompress is enabled, the fully buffered response is decompressed in one operation, and zlib can return the entire inflated output at once. A small compressed payload can therefore produce a much larger memory allocation.
How can I determine whether my application is affected?
Check whether the application uses hackney versions from 2.0.0-beta.1 before 4.9.0 and calls hackney:request/5 or hackney:body/1, or uses code paths relying on hackney_conn:read_full_body/2 or HTTP/2 or HTTP/3 body accumulation. Exposure is especially relevant where those requests reach servers not fully trusted by the application.
What should be done if an immediate upgrade is not possible?
Avoid making affected full-body request paths to untrusted servers where possible, and do not enable auto_decompress for such requests. Restrict outbound requests to trusted endpoints until the dependency can be updated to 4.9.0 or later.