Summary
mint: Unbounded streams map growth via PUSH_PROMISE without follow-up HEADERS
Mint's HTTP/2 client accepts PUSH_PROMISE frames from any server it connects to and inserts every promised stream into a per-connection map without consulting max_concurrent_streams. A malicious or compromised HTTP/2 server can flood the client with PUSH_PROMISE frames and withhold the matching response HEADERS, pinning one map entry per frame indefinitely until the client process runs out of memory.
Details
'Elixir.Mint.HTTP2':handle_push_promise/3 in lib/mint/http2.ex dispatches every inbound PUSH_PROMISE frame to 'Elixir.Mint.HTTP2':decode_push_promise_headers_and_add_response/5, which inserts a :reserved_remote entry into conn.streams for the promised ID. The only validation applied is that the promised ID is even and not already present; client_settings.max_concurrent_streams is not consulted at promise time.
The concurrency cap is only checked when the response HEADERS for the promised stream arrive. A server that emits PUSH_PROMISE frames and never sends the matching HEADERS never trips that check, and the existing tally counts only streams in open states, not :reserved_remote entries.
HTTP/2 server push is accepted by default (client_settings.enable_push defaults to true), so no application opt-in is required. A single long-lived HTTP/2 connection to a hostile server lets it pin one conn.streams entry per PUSH_PROMISE frame, with no upper bound.
PoC
- Stand up a raw TCP HTTP/2 server that completes the handshake and ACKs the client's
SETTINGS. - Wait for the client's request
HEADERSand capture its odd stream ID. - Send a flood of
PUSH_PROMISEframes (flags = END_HEADERS) associated with the captured stream, each promising a fresh even stream ID and carrying a minimal HPACK-encoded header block. - Never send the matching response
HEADERSfor any of the promised IDs. - The client's
conn.streamsmap grows by one entry perPUSH_PROMISEframe (~148 bytes/entry); memory grows linearly and the BEAM process eventually crashes with OOM.
Workarounds
Disable HTTP/2 server push on connections to untrusted servers by passing client_settings: [enable_push: false] to 'Elixir.Mint.HTTP':connect/4. Mint will then reject any inbound PUSH_PROMISE frame with a PROTOCOL_ERROR before the vulnerable code path is reached.
Resources
Impact
Remote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. Server push is on by default, so no application code change can prevent it short of disabling push or upgrading. Affected populations include outbound HTTP/2 clients in web backends, webhook delivery systems, scrapers, federated and proxy components, and any service that follows redirects to third-party HTTP/2 origins.
The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-48862? CVE-2026-48862 is a high-severity allocation of resources without limits or throttling vulnerability in mint (erlang), affecting versions >= 0.2.0, < 1.9.0. It is fixed in 1.9.0. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
- Which versions of mint are affected by CVE-2026-48862? mint (erlang) versions >= 0.2.0, < 1.9.0 is affected.
- Is there a fix for CVE-2026-48862? Yes. CVE-2026-48862 is fixed in 1.9.0. Upgrade to this version or later.
- Is CVE-2026-48862 exploitable, and should I be worried? Whether CVE-2026-48862 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-48862 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-48862? Upgrade
mintto 1.9.0 or later.