CVE-2026-42788: Bandit HTTP/2 Frame DoS Vulnerability

CVE-2026-42788 Overview

CVE-2026-42788 is an unauthenticated denial-of-service vulnerability in the mtrudel bandit Elixir HTTP server. The flaw resides in Elixir.Bandit.HTTP2.Frame.deserialize/2 within lib/bandit/http2/frame.ex, where the SETTINGS_MAX_FRAME_SIZE limit is enforced only after the full frame payload has been pattern-matched into memory. A remote attacker can advertise frame lengths up to the 24-bit HTTP/2 maximum of approximately 16 MiB, forcing the server to buffer the entire body before the size guard rejects it. The issue is classified under [CWE-770: Allocation of Resources Without Limits or Throttling] and affects bandit versions 0.3.6 through versions prior to 1.11.0.

Critical Impact

An unauthenticated attacker holding multiple concurrent HTTP/2 connections can force the server to buffer far more memory than the negotiated frame size permits, causing memory pressure and denial of service.

Affected Products

• mtrudel bandit (Elixir HTTP server) versions 0.3.6 through 1.10.x
• Phoenix and Plug applications using bandit as the HTTP adapter
• Any Elixir/Erlang service exposing HTTP/2 endpoints via vulnerable bandit releases

Discovery Timeline

• 2026-05-01 - CVE-2026-42788 published to NVD
• 2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-42788

Vulnerability Analysis

The defect is a logic-ordering flaw in HTTP/2 frame deserialization. RFC 9113 specifies a default SETTINGS_MAX_FRAME_SIZE of 16 KiB, with peers free to negotiate higher values up to roughly 16 MiB. Bandit's deserialize/2 function declares a binary pattern match of the form payload::binary-size(length) before any guard clause inspects the announced length. The Erlang/Elixir runtime must materialize the full length bytes into a binary before either the accept or reject branch can execute. Consequently, the server allocates memory proportional to the attacker-controlled length field, regardless of the negotiated max_frame_size.

The vulnerability does not require authentication, prior session state, or valid application data. An attacker only needs to complete the HTTP/2 connection preface and emit frame headers declaring oversized payloads.

Root Cause

The size check executes after binary pattern matching rather than before. The correct sequence is to inspect the 24-bit length field from the 9-byte frame header, compare it against the negotiated SETTINGS_MAX_FRAME_SIZE, and reject the frame with a FRAME_SIZE_ERROR connection error before allocating buffer space for the payload.

Attack Vector

The attack is fully remote and unauthenticated. An attacker opens many concurrent TLS or cleartext HTTP/2 connections, completes the connection preface, and on each connection sends frame headers that advertise lengths approaching the 24-bit maximum. The server buffers up to ~16 MiB per frame per connection, multiplying memory usage across the connection pool until the BEAM virtual machine exhausts available memory or triggers OOM termination.

No exploit code is required beyond a basic HTTP/2 frame generator. See the GitHub Security Advisory GHSA-q6v9-r226-v65f and the upstream commit for the technical fix.

Detection Methods for CVE-2026-42788

Indicators of Compromise

• Sustained spikes in BEAM virtual machine memory consumption on bandit-fronted services without a corresponding rise in completed requests
• HTTP/2 connections from a small set of source IPs that open, transmit frame headers, and stall before sending complete payloads
• Elevated rates of FRAME_SIZE_ERROR (0x6) GOAWAY frames once the patched version is deployed

Detection Strategies

• Inspect HTTP/2 frame headers at the reverse proxy or WAF and alert on declared frame lengths exceeding the negotiated SETTINGS_MAX_FRAME_SIZE
• Correlate per-connection memory growth with HTTP/2 frame counts using application telemetry from :telemetry or Prometheus exporters
• Monitor for many concurrent HTTP/2 connections from a single source that exhibit low request completion rates

Monitoring Recommendations

• Track BEAM memory metrics (erlang:memory/0) and process counts on bandit hosts and alert on rapid growth
• Log peer-advertised frame sizes and connection durations to identify abuse patterns
• Forward HTTP/2 protocol errors and connection-level GOAWAY events to a centralized SIEM or data lake for correlation

How to Mitigate CVE-2026-42788

Immediate Actions Required

• Upgrade bandit to version 1.11.0 or later in all mix.exs dependencies and redeploy affected services
• Inventory Phoenix and Plug applications to identify which use bandit versus alternative adapters such as Cowboy
• Place a hardened reverse proxy in front of bandit endpoints to enforce HTTP/2 frame size limits at the network edge until patching completes

Patch Information

The maintainer fixed the issue in bandit 1.11.0 by validating the frame length field against SETTINGS_MAX_FRAME_SIZE before binary pattern matching the payload. The remediation commit is referenced in the GitHub commit log. Additional details are available in the CNA advisory at cna.erlef.org and the OSV vulnerability report.

Workarounds

• Terminate HTTP/2 at an upstream proxy (such as nginx, HAProxy, or a CDN) that enforces strict frame size limits before traffic reaches bandit
• Apply per-IP connection and rate limits to reduce the multiplier available to an attacker abusing many concurrent connections
• Constrain BEAM memory using OS-level cgroup limits so that exhaustion fails fast and triggers automated restarts rather than host-wide impact

# Upgrade bandit in mix.exs and refresh the lockfile
# {:bandit, "~> 1.11"}
mix deps.update bandit
mix deps.get
mix compile