CVE-2026-47077
Analyzed Analyzed - Analysis Complete
Allocation of Resources Without Limits or Throttling in hackney

Publication date: 2026-05-25

Last updated on: 2026-05-27

Assigner: EEF

Description
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame β€” it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition. This issue affects hackney: from 2.0.0 before 4.0.1.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-25
Last Modified
2026-05-27
Generated
2026-06-15
AI Q&A
2026-05-26
EPSS Evaluated
2026-06-14
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
benoitc hackney From 2.0.0 (inc) to 4.0.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-400 The product does not properly control the allocation and maintenance of a limited resource.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Detection Guidance

This vulnerability involves unbounded accumulation of HTTP/3 response body data in memory when using the hackney HTTP client library with HTTP/3 transport. Detection involves monitoring for abnormal memory usage patterns in processes running hackney versions from 2.0.0 before 4.0.1, especially those using HTTP/3.

Since the issue is specific to HTTP/3 transport and involves the function hackney_h3:await_response_loop/6 accumulating data without limits, you can detect it by observing unusually high memory consumption or out-of-memory conditions in BEAM processes handling HTTP/3 responses.

There are no explicit commands provided in the resources, but general approaches include:

  • Monitor BEAM process memory usage with Erlang tools such as observer or recon.
  • Use system monitoring tools (e.g., top, htop) to detect processes with growing memory consumption.
  • Capture and analyze HTTP/3 traffic to identify servers sending small chunks repeatedly just before the inactivity timeout.
  • Check hackney version in use to confirm if it is vulnerable (versions from 2.0.0 before 4.0.1).
Mitigation Strategies

The primary mitigation is to upgrade hackney to version 4.0.1 or later, where the vulnerability has been patched.

The patch introduces an absolute wall-clock deadline for the entire HTTP/3 response and caps the buffered response body size to a configurable maximum (default 512 MiB). If the body exceeds this limit, the connection aborts with an error, preventing unbounded memory growth.

If upgrading immediately is not possible, consider avoiding the use of HTTP/3 transport in hackney or explicitly configure hackney to not use HTTP/3 by not setting `{transport, h3}` in `hackney:request/5`.

Additionally, monitor memory usage of BEAM processes to detect potential exploitation attempts and restart affected processes if necessary.

Executive Summary

This vulnerability is an Allocation of Resources Without Limits or Throttling issue in the benoitc hackney library, specifically in the hackney_h3:await_response_loop/6 function. The function accumulates the HTTP/3 response body in memory without any size limit. A malicious HTTP/3 server can exploit this by sending small chunks of data just before the timeout expires, keeping the loop alive indefinitely without sending a final frame. This causes the accumulation buffer to grow continuously, eventually exhausting the memory of the BEAM process and causing an out-of-memory condition.

Impact Analysis

The impact of this vulnerability is that a malicious HTTP/3 server can cause a denial of service by exhausting the memory of the affected process. This happens because the vulnerable function accumulates response data without limits, leading to an out-of-memory condition that can crash or severely degrade the performance of applications using the affected hackney versions.

Compliance Impact

The provided information does not specify any direct impact of the CVE-2026-47077 vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-47077. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart