Live › vulnerability › CVE-2026-97200
Go to dashboardThe Erlang HTTP client hackney buffers entire response bodies without any size limit, and decompresses them in one step. A malicious HTTP server the client calls can send an oversized or highly compressed body and exhaust the client's memory.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 14:30 UTC. All times on this page are UTC.
Erlang or Elixir services that use hackney as an HTTP client and fetch data from servers they do not fully trust, such as third-party APIs, webhooks or user-supplied URLs. Services that only call fixed internal endpoints under your control are at much lower risk. Teams not using hackney can skip it.
No product ranges from the sources yet.
rebar.lock or mix.lock (or the lock file for your build tool) and see whether it falls in 2.0.0-beta.1 to before 4.9.0.hackney:request/5 or hackney:body/1 that fetch from servers you do not control.4.9.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Allocation of Resources Without Limits or Throttling vulnerability in hackney_conn 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.
hackney_conn:read_full_body/2 and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With {auto_decompress, 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.
This page as .md · .json · in your agent: get_signal("CVE-2026-97200")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.