CVE-2026-42788
Allocation of Resources Without Limits or Throttling in Bandit
Publication date: 2026-05-01
Last updated on: 2026-05-05
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| elixir | bandit | From 0.3.6 (inc) to 1.11.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is an Allocation of Resources Without Limits or Throttling issue in the mtrudel bandit HTTP/2 implementation. Specifically, the function 'Elixir.Bandit.HTTP2.Frame':deserialize/2 in the file lib/bandit/http2/frame.ex does not properly enforce the SETTINGS_MAX_FRAME_SIZE limit before allocating memory for incoming HTTP/2 frames.
The code pattern-matches the payload binary size before checking the frame size limit, which means the entire frame body must be loaded into memory before the size is validated. An attacker can send frames up to the 24-bit maximum size (~16 MiB), causing the server to buffer large amounts of memory regardless of the negotiated max frame size (default 16 KiB).
This allows an unauthenticated attacker to open many concurrent connections and exhaust server memory by forcing it to buffer large frames, potentially leading to denial of service.
How can this vulnerability impact me? :
The vulnerability can lead to memory exhaustion on the affected server by allowing an attacker to force the server to allocate large amounts of memory for oversized HTTP/2 frames.
This memory pressure can degrade server performance or cause it to crash, resulting in a denial of service (DoS) condition.
Since the attack can be performed by an unauthenticated attacker holding many concurrent connections, it poses a significant risk to availability.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability primarily causes unauthenticated memory exhaustion leading to denial of service by allowing oversized HTTP/2 frames to be buffered in memory before size checks. It impacts system availability but does not directly involve unauthorized access to sensitive data or personal information.
Since the vulnerability affects availability rather than confidentiality or integrity, its impact on compliance with standards like GDPR or HIPAA is indirect. These regulations emphasize protecting personal data confidentiality, integrity, and availability. A denial-of-service condition could affect availability requirements, potentially leading to non-compliance if critical services are disrupted.
However, there is no indication from the provided information that this vulnerability leads to data breaches or exposure of personal data, so its compliance impact is limited to availability concerns.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusually large HTTP/2 frames being sent to the Bandit server, especially frames that exceed the negotiated maximum frame size (default 16 KiB) but are accepted and buffered by the server.
Network detection can involve capturing HTTP/2 traffic and inspecting frame sizes to identify oversized frames up to the 24-bit maximum (~16 MiB).
On the system side, monitoring memory usage spikes or many concurrent connections holding large buffers may indicate exploitation attempts.
- Use packet capture tools like tcpdump or Wireshark to capture HTTP/2 traffic and filter for large frame sizes.
- Example tcpdump command to capture HTTP/2 traffic on port 443: tcpdump -i <interface> -w capture.pcap port 443
- Analyze the capture with Wireshark, filtering for HTTP/2 frames and checking frame length fields for sizes exceeding the negotiated max_frame_size.
- On the server, use system monitoring tools (e.g., top, htop) to observe memory usage and number of concurrent connections.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade the Bandit HTTP/2 server to version 1.11.0 or later, where the vulnerability is fixed by rejecting oversized frames immediately upon receiving the frame header.
Until an upgrade is possible, consider implementing network-level protections such as limiting the size of HTTP/2 frames allowed through firewalls or reverse proxies.
Monitor and limit the number of concurrent connections to reduce the risk of memory exhaustion.
Apply rate limiting or connection throttling to prevent attackers from opening many concurrent connections.