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

CVE-2026-91043 Overview

CVE-2026-91043 is a denial-of-service vulnerability in the elixir-mint mint HTTP client library. The flaw lives in Mint.HTTP2, which enforces the client's max_header_list_size against the compressed on-wire size of inbound header blocks instead of the decoded header list size required by RFC 9113 section 6.5.2. A malicious HTTP/2 server can craft a header block that stays under the default 256 KB wire limit yet decodes into roughly 1 GB of memory on the client. Repeated responses exhaust the Erlang process that owns the connection or the entire BEAM virtual machine. The issue affects mint from version 1.1.0 before 1.10.2.

Critical Impact
A single malicious HTTP/2 server can crash Elixir and Erlang client applications, including proxies, scrapers, and service-to-service HTTP callers, by sending compact header blocks that decompress into gigabyte-scale allocations.

Affected Products

elixir-mint mint 1.1.0 through 1.10.1
Elixir and Erlang applications embedding Mint.HTTP2 as an HTTP/2 client
Downstream libraries built on top of mint (for example, HTTP client wrappers and connection pools)

Discovery Timeline

2026-09-28 - CVE-2026-91043 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-91043

Vulnerability Analysis

The vulnerability is a resource exhaustion issue tracked as [CWE-770: Allocation of Resources Without Limits or Throttling]. HPACK, the HTTP/2 header compression format, allows a single indexed field to occupy one byte on the wire while expanding to a dynamic table entry of up to 4 KB after decoding. Mint.HTTP2 validated inbound HEADERS and CONTINUATION frames against the wire size only, so a 256 KB header block could expand to a decoded list approximately 4,000 times larger.

The join_cookie_headers/1 function in lib/mint/http2.ex compounds the issue by copying every cookie value from a response into a single new binary. The concatenation forces an additional large allocation on top of the already decoded header list. A handful of such responses on one connection drives the owning Erlang process, or the entire virtual machine, into out-of-memory conditions.

The EPSS score at publication is 0.384% at the 29.8th percentile, reflecting a specialized exploitation path that still carries a direct and reliable denial-of-service outcome once triggered.

Root Cause

The client enforced the HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE parameter against the compressed on-wire size of the header block rather than against the decoded header list size. RFC 9113 specifies the limit on decoded data, including the 32-byte per-entry overhead. The mismatch allowed indexed HPACK references and cookie fan-out to produce unbounded memory growth within a nominally compliant frame budget.

Attack Vector

Exploitation requires the Elixir or Erlang client to initiate an HTTP/2 connection to a server controlled by the attacker. This is practical for any application that fetches arbitrary URLs, follows redirects, or communicates with untrusted upstream services. The attacker returns a HEADERS frame, optionally followed by CONTINUATION frames, filled with indexed HPACK references and oversized cookie values. No authentication is required.

text

// Patch excerpt: lib/mint/http2.ex - cookie header concatenation moved behind the size check
       [{":status", status} | headers] when not received_first_headers? ->
         conn = put_in(conn.streams[stream.id].received_first_headers?, true)
         status = String.to_integer(status)
+        headers = join_cookie_headers(headers)
         new_responses = [{:headers, ref, headers}, {:status, ref, status} | responses]

         cond do

Source: GitHub Commit 8e0e046

Detection Methods for CVE-2026-91043

Indicators of Compromise

Elixir or Erlang application processes terminating with system_limit, enomem, or BEAM VM out-of-memory crashes shortly after outbound HTTP/2 requests.
Connections to unfamiliar upstream HTTP/2 servers immediately preceding memory spikes in services that embed mint.
Error tuples of the form {:max_header_list_size_exceeded, size, max_size} appearing after patching, indicating attempted exploitation.

Detection Strategies

Inventory running Elixir and Erlang services and identify any that bundle mint versions 1.1.0 through 1.10.1 via mix.lock or release manifests.
Correlate sudden resident set size growth on BEAM nodes with outbound TCP flows to HTTP/2 endpoints on port 443.
Review proxy and egress logs for repeated requests to the same remote host that terminate with abrupt client-side disconnects.

Monitoring Recommendations

Alert on BEAM VM memory telemetry crossing historical baselines, particularly :memory reports for :processes and :binary.
Track supervisor restart rates for HTTP client workers and connection pool processes.
Capture packet-level or application-level telemetry on HEADERS and CONTINUATION frame counts per HTTP/2 connection.

How to Mitigate CVE-2026-91043

Immediate Actions Required

Upgrade mint to version 1.10.2 or later across all applications and transitive dependencies.
Rebuild and redeploy OTP releases to ensure the patched library is loaded in production.
Restrict outbound HTTP/2 traffic from server-side components to vetted upstream hosts where feasible.

Patch Information

The fix lands across commits 65a0d61, 8e0e046, and c7895cb. Patched versions enforce max_header_list_size against the decoded header list, close the connection on server header blocks that exceed the wire budget, refuse oversized server pushes, and fail requests with {:max_header_list_size_exceeded, size, max_size} when the decoded size is exceeded. See the GitHub Security Advisory GHSA-9x8p-qrf4-jq7g and the CNA advisory for full details.

Workarounds

Lower the client max_header_list_size setting substantially below the 256 KB default to shrink the worst-case allocation.
Route outbound HTTP/2 traffic through a reverse proxy that enforces decoded header size limits in front of mint clients.
Disable HTTP/2 and fall back to HTTP/1.1 for callers that connect to untrusted servers until patching is complete.

bash

# Pin the patched release in mix.exs and refresh the lockfile
# {:mint, "~> 1.10.2"}
mix deps.update mint
mix deps.get
mix compile --force