Elixir Mint CVE-2026-48862

The victim application must use Mint (versions 0.2.0 through 1.8.x) to make an HTTP/2 connection to an attacker-controlled or attacker-influenced server, and HTTP/2 server push must remain enabled - which is the default (client_settings.enable_push=true). No authentication or user interaction with the Mint host is required, and the attack works against default configurations. Exploitation is LIMITED by the fact that the client must initiate the outbound connection (reflected in CVSS AT:P), so purely server-side Mint deployments that never act as a client, or clients restricted to trusted origins via egress controls, are not exposed. Lowering max_concurrent_streams does NOT limit exploitation on unpatched versions because the cap is not enforced at PUSH_PROMISE time.

The CVSS 4.0 vector AV:N/AC:L/AT:P/PR:N/UI:N with VA:H accurately captures a network-reachable, low-complexity, unauthenticated denial of service with no confidentiality or integrity impact; the AT:P (attack requirements: present) component correctly reflects that the victim must initiate a connection to the attacker's HTTP/2 server, which materially limits exploitability compared to a server-side DoS. Real-world risk depends heavily on deployment: services using Mint (directly or via Finch/Tesla) to fetch attacker-controlled URLs (webhooks, link previews, SSRF-style fetchers, federated polling) face meaningful exposure, while Mint clients that only talk to trusted origins are at low risk. No EPSS score, KEV listing, or POC was supplied in the input, and the tag set lists only 'Denial Of Service'; combined with the limited blast radius (process crash, not RCE) this is a real but tier-2 priority - patch on a normal cadence unless the application fetches arbitrary remote URLs, in which case treat as high.

An attacker stands up an HTTP/2 server (or compromises one already reached by the target) and waits for a Mint-based client - for example a Phoenix app fetching link previews or a Finch-backed webhook dispatcher - to open a connection. The malicious server replies to the first request by streaming a continuous flood of PUSH_PROMISE frames with monotonically increasing even stream IDs but never sends the matching response HEADERS, so each promise pins a :reserved_remote entry in conn.streams without bound. Within seconds to minutes the Elixir process backing the connection exhausts BEAM memory and is killed, taking dependent supervision trees down with it; no public exploit code is identified at time of analysis but the test case added in the patch (100 promises against a 5-stream cap) is a working proof of concept.