CVE-2026-92103: Elixir Mint HTTP/2 DOS Vulnerability

CVE-2026-92103 Overview

CVE-2026-92103 is a resource exhaustion vulnerability in the Elixir mint HTTP client library. A malicious HTTP/2 server can force a mint client to buffer up to approximately 16 MiB of frame data per connection before the client rejects the frame. The flaw stems from Mint.HTTP2.Frame.decode_next/2 only validating a frame against max_frame_size after the entire declared payload has been received. By advertising a frame length up to the 24-bit maximum of 16,777,215 bytes and withholding the final byte, an attacker keeps the buffer populated for the lifetime of the connection. The issue affects mint versions 0.1.0 through versions prior to 1.10.2.

Critical Impact
A malicious HTTP/2 server can sustain roughly 1,024x the advertised max_frame_size (default 16 KiB) in client memory per connection, enabling memory pressure attacks against Elixir applications that use mint to make outbound HTTP/2 requests.

Affected Products

elixir-mint mint HTTP client library versions 0.1.0 through 1.10.1
Elixir and Erlang applications performing outbound HTTP/2 requests via mint
Downstream libraries that embed mint for HTTP/2 transport (e.g., Finch-based clients)

Discovery Timeline

2026-09-28 - CVE-2026-92103 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-92103

Vulnerability Analysis

The vulnerability is categorized as Allocation of Resources Without Limits or Throttling [CWE-770], a form of Resource Exhaustion. The defect lives in Mint.HTTP2.Frame.decode_next/2 within lib/mint/http2/frame.ex. The function compares an incoming frame against the client's configured max_frame_size only after the complete declared payload has arrived. Until all bytes are present, the decoder returns :more, and Mint.HTTP2 continues accumulating received bytes in the connection buffer.

The HTTP/2 frame header encodes the payload length in 24 bits, allowing a server to declare lengths up to 16,777,215 bytes. With the default max_frame_size of 16,384 bytes, a server can keep approximately 1,024 times the advertised limit buffered per connection by withholding the final byte of the payload indefinitely. Because the server must transmit every byte the client holds, there is no amplification factor and the buffered volume is capped by the 24-bit length field.

Root Cause

The size-limit check in decode_next/2 was reachable only in the branch that successfully parsed a full frame. Incomplete frames bypassed the check entirely, allowing untrusted length declarations to drive buffer growth on the client side.

Attack Vector

An attacker who controls or compromises an HTTP/2 server that an Elixir application connects to can respond with a frame header advertising a near-maximum payload length. The server then streams data up to one byte short of the declared length and holds the connection open. Each affected connection pins roughly 16 MiB of memory in the client's buffer until the connection is closed. Repeated or long-lived connections multiply the memory consumption against the client process.

elixir

# Patch excerpt from lib/mint/http2/frame.ex
#
# Before: the length check only ran after the full payload parsed successfully.
# After: the declared 24-bit length is validated against max_frame_size
# as soon as the 9-byte frame header is available, so oversized frames
# are rejected before the client buffers the payload.

-  def decode_next(bin, max_frame_size \\ 16_384) when is_binary(bin) do
-    case decode_next_raw(bin) do
-      {:ok, {_type, _flags, _stream_id, payload}, _rest}
-      when byte_size(payload) > max_frame_size ->
-        {:error, :payload_too_big}
+  def decode_next(bin, max_frame_size \\ 16_384)
+
+  def decode_next(<<length::24, _header::binary-size(6), _rest::binary>>, max_frame_size)
+      when length > max_frame_size do
+    {:error, :payload_too_big}
+  end

+  def decode_next(bin, _max_frame_size) when is_binary(bin) do
+    case decode_next_raw(bin) do
       {:ok, {type, flags, stream_id, payload}, rest} ->
         {:ok, decode_contents(type, flags, stream_id, payload), rest}

Source: GitHub Commit 20252ca

Detection Methods for CVE-2026-92103

Indicators of Compromise

Sustained growth of the Erlang VM's binary memory region on hosts running applications that use mint for outbound HTTP/2.
Long-lived HTTP/2 connections to external endpoints where byte counts received approach but never reach the declared frame length.
mint process heaps holding large binaries attributable to Mint.HTTP2 connection state.

Detection Strategies

Inventory Elixir and Erlang applications and their dependency graphs for mint versions below 1.10.2, including transitive use through Finch, Tesla, and similar libraries.
Capture HTTP/2 traffic from client hosts and alert on HEADERS or DATA frames whose declared Length field exceeds the negotiated SETTINGS_MAX_FRAME_SIZE.
Use software composition analysis (SCA) tooling against mix.lock files to flag vulnerable mint releases.

Monitoring Recommendations

Track per-connection buffer memory in Mint.HTTP2 state and alert when any single connection sustains buffered data above the configured max_frame_size.
Monitor the Erlang VM's :binary memory metric and correlate spikes with outbound HTTP/2 connection counts.
Log connection lifetimes and byte counters for outbound HTTP/2 destinations to surface servers that stall at the end of oversized frames.

How to Mitigate CVE-2026-92103

Immediate Actions Required

Upgrade the mint dependency to version 1.10.2 or later in mix.exs and refresh mix.lock.
Rebuild and redeploy any application or library that embeds mint, including HTTP client wrappers such as Finch.
Restrict outbound HTTP/2 connections to trusted hosts where upgrade cannot be performed immediately.

Patch Information

The fix is included in mint1.10.2. The patch rewrites Mint.HTTP2.Frame.decode_next/2 to validate the 24-bit length field in the frame header against max_frame_size before any payload is buffered, returning {:error, :payload_too_big} immediately. Full details are available in the GitHub Security Advisory GHSA-q95c-ccq6-j5j6, the CNA advisory, and the fix commits 20252ca and 44d7ce4.

Workarounds

Enforce per-process memory limits on BEAM processes handling HTTP/2 connections so a runaway connection is killed before it affects the node.
Terminate outbound HTTP/2 connections through a trusted egress proxy that validates frame lengths against the negotiated SETTINGS_MAX_FRAME_SIZE.
Impose aggressive connection and idle timeouts on mint clients to limit how long a stalled frame can occupy memory.

bash

# Upgrade mint to the patched release and refresh the lockfile
mix deps.update mint
mix deps.get
mix deps.compile mint

# Verify the installed version is 1.10.2 or later
mix deps | grep mint