{"id":"CVE-2026-49754","aliases":["EEF-CVE-2026-49754","EUVD-2026-33940","GHSA-2p26-p43x-fhp8"],"status":"published","title":"HTTP/2 CONTINUATION flood in Mint client via unbounded header-block accumulation","description":"Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.","severity":{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00384,"percentile":0.32712,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-770"],"published":"2026-06-02T14:15:14Z","modified":"2026-10-28T02:30:45Z","fixes":[{"ecosystem":"Hex","package":"mint","fixed_in":["1.9.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Hex","package":"mint","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.0"}]}]},{"source":"osv","ecosystem":"Hex","package":"mint","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.0"},{"fixed":"1.9.0"}]}],"versions":["0.1.0","0.2.0","0.2.1","0.3.0","0.4.0","0.5.0","1.0.0","1.1.0","1.2.0","1.2.1","1.3.0","1.4.0","1.4.1","1.4.2","1.5.0","1.5.1","1.5.2","1.6.0","1.6.1","1.6.2","1.7.0","1.7.1","1.8.0"]},{"source":"osv","ecosystem":"Hex","package":"mint","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.9.0"}]}],"versions":["0.1.0","0.2.0","0.2.1","0.3.0","0.4.0","0.5.0","1.0.0","1.1.0","1.2.0","1.2.1","1.3.0","1.4.0","1.4.1","1.4.2","1.5.0","1.5.1","1.5.2","1.6.0","1.6.1","1.6.2","1.7.0","1.7.1","1.8.0"]}],"products":[{"vendor":"elixir-mint","product":"mint"},{"vendor":"linuxmint","product":"mint"}],"references":[{"url":"https://github.com/elixir-mint/mint/security/advisories/GHSA-2p26-p43x-fhp8","tags":["vendor-advisory","related","exploit","advisory","web"]},{"url":"https://cna.erlef.org/cves/CVE-2026-49754.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-49754","tags":["related","web"]},{"url":"https://github.com/elixir-mint/mint/commit/b662d127d3028b5426c88d4c9cc7fe430491a10b","tags":["patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49754","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-2p26-p43x-fhp8"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/49xxx/CVE-2026-49754.json","tags":["advisory"]},{"url":"https://github.com/elixir-mint/mint","tags":["package"]},{"url":"https://github.com/elixir-mint/mint.git","tags":["package"]},{"url":"https://hex.pm/packages/mint","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-49754","title":"HTTP/2 CONTINUATION flood in Mint client via unbounded header-block accumulation","description":"Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.","status":"published","published":"2026-06-02T14:15:14.951Z","modified":"2026-06-02T19:14:33.1Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T13:34:59.78118Z"}],"euvd":[{"id":"EUVD-2026-33940","description":"Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.","status":"published","published":"2026-06-02T14:15:14Z","modified":"2026-06-02T19:14:33Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:20:55.651138Z"}],"ghsa":[{"id":"GHSA-2p26-p43x-fhp8","title":"mint: Unbounded CONTINUATION/HEADERS frame accumulation (CONTINUATION flood)","description":"### Summary\n\nMint's HTTP/2 client accumulates `CONTINUATION` header-block fragments into a per-connection buffer with no cap on size or frame count. A malicious or compromised HTTP/2 server can drive the client's memory to arbitrary size by streaming an endless chain of `CONTINUATION` frames after a `HEADERS` frame that omits `END_HEADERS`, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\n### Details\n\nWhen Mint's HTTP/2 receive path observes a `HEADERS` frame without the `END_HEADERS` flag, `'Elixir.Mint.HTTP2':handle_headers/3` parks the unparsed header-block fragment in `conn.headers_being_processed`. Every subsequent `CONTINUATION` frame on that stream is then appended to the accumulator by `'Elixir.Mint.HTTP2':handle_continuation/3`.\n\nNothing in the receive path bounds this accumulator: there is no per-stream size cap, no `CONTINUATION` frame-count cap, and `max_header_list_size` is only enforced on outgoing requests (its default is `:infinity`, and the only enforcement helper inspects `server_settings` for request encoding, never inbound header blocks). Each `CONTINUATION` payload can be up to the peer-advertised `SETTINGS_MAX_FRAME_SIZE`, so the attacker can grow `headers_being_processed` to arbitrary size at line rate.\n\n### PoC\n\n1. Stand up a raw TCP server that speaks the HTTP/2 handshake.\n2. After the client's request `HEADERS` arrives, respond with a `HEADERS` frame on stream 1 with `flags = 0` (no `END_HEADERS`, no `END_STREAM`) and an empty header-block fragment.\n3. Stream `CONTINUATION` frames on stream 1, each with `flags = 0` and a payload up to `SETTINGS_MAX_FRAME_SIZE`. Never set `END_HEADERS`.\n4. The client's process memory grows linearly with the flood and the BEAM process eventually crashes with OOM.\n\n### Impact\n\nRemote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. A single connection is sufficient to drive memory to arbitrary size and crash the BEAM process. The default Mint configuration is vulnerable; no client-side opt-in is required. Scored CVSS v4.0 8.2 (HIGH).\n\n## Workarounds\n\nRestrict Mint to HTTP/1 on connections to untrusted servers by passing `protocols: [:http1]` to `'Elixir.Mint.HTTP':connect/4`. This avoids the vulnerable HTTP/2 receive path entirely, at the cost of losing HTTP/2 for those connections.\n\n## Resources\n\n* Introduction commit: https://github.com/elixir-mint/mint/commit/596ca4304504be68939c4929e0831557097962b8\n* Patch commit: https://github.com/elixir-mint/mint/commit/b662d127d3028b5426c88d4c9cc7fe430491a10b","status":"published","published":"2026-07-09T23:19:23Z","modified":"2026-07-09T23:19:24Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:40:41.501474Z"}],"nvd":[{"id":"CVE-2026-49754","description":"Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.","status":"published","published":"2026-06-02T16:16:44.93Z","modified":"2026-07-22T19:10:00.12Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:12:22.022466Z"}],"osv":[{"id":"CVE-2026-49754","title":"HTTP/2 CONTINUATION flood in Mint client via unbounded header-block accumulation","description":"Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.","status":"published","published":"2026-06-02T14:15:14.951Z","modified":"2026-10-28T02:30:45.988829329Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:45:07.060148Z"},{"id":"EEF-CVE-2026-49754","title":"HTTP/2 CONTINUATION flood in Mint client via unbounded header-block accumulation","description":"## Summary\n\nAllocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood).\n\nWhen Mint's HTTP/2 receive path observes a HEADERS frame without the END\\_HEADERS flag, the unparsed header-block fragment is parked in conn.headers\\_being\\_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max\\_header\\_list\\_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).\n\nA malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS\\_MAX\\_FRAME\\_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\nThis issue affects mint: from 0.1.0 before 1.9.0.\n\n## Workarounds\n\nRestrict Mint to HTTP/1 on connections to untrusted servers by passing protocols: \\[:http1\\] to Mint.HTTP.connect/4. This avoids the vulnerable HTTP/2 receive path entirely, at the cost of losing HTTP/2 for those connections.","status":"published","published":"2026-06-02T14:15:14.951Z","modified":"2026-09-08T03:45:05.058267146Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:33.520522Z"},{"id":"GHSA-2p26-p43x-fhp8","title":"mint: Unbounded CONTINUATION/HEADERS frame accumulation (CONTINUATION flood)","description":"### Summary\n\nMint's HTTP/2 client accumulates `CONTINUATION` header-block fragments into a per-connection buffer with no cap on size or frame count. A malicious or compromised HTTP/2 server can drive the client's memory to arbitrary size by streaming an endless chain of `CONTINUATION` frames after a `HEADERS` frame that omits `END_HEADERS`, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.\n\n### Details\n\nWhen Mint's HTTP/2 receive path observes a `HEADERS` frame without the `END_HEADERS` flag, `'Elixir.Mint.HTTP2':handle_headers/3` parks the unparsed header-block fragment in `conn.headers_being_processed`. Every subsequent `CONTINUATION` frame on that stream is then appended to the accumulator by `'Elixir.Mint.HTTP2':handle_continuation/3`.\n\nNothing in the receive path bounds this accumulator: there is no per-stream size cap, no `CONTINUATION` frame-count cap, and `max_header_list_size` is only enforced on outgoing requests (its default is `:infinity`, and the only enforcement helper inspects `server_settings` for request encoding, never inbound header blocks). Each `CONTINUATION` payload can be up to the peer-advertised `SETTINGS_MAX_FRAME_SIZE`, so the attacker can grow `headers_being_processed` to arbitrary size at line rate.\n\n### PoC\n\n1. Stand up a raw TCP server that speaks the HTTP/2 handshake.\n2. After the client's request `HEADERS` arrives, respond with a `HEADERS` frame on stream 1 with `flags = 0` (no `END_HEADERS`, no `END_STREAM`) and an empty header-block fragment.\n3. Stream `CONTINUATION` frames on stream 1, each with `flags = 0` and a payload up to `SETTINGS_MAX_FRAME_SIZE`. Never set `END_HEADERS`.\n4. The client's process memory grows linearly with the flood and the BEAM process eventually crashes with OOM.\n\n### Impact\n\nRemote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. A single connection is sufficient to drive memory to arbitrary size and crash the BEAM process. The default Mint configuration is vulnerable; no client-side opt-in is required. Scored CVSS v4.0 8.2 (HIGH).\n\n## Workarounds\n\nRestrict Mint to HTTP/1 on connections to untrusted servers by passing `protocols: [:http1]` to `'Elixir.Mint.HTTP':connect/4`. This avoids the vulnerable HTTP/2 receive path entirely, at the cost of losing HTTP/2 for those connections.\n\n## Resources\n\n* Introduction commit: https://github.com/elixir-mint/mint/commit/596ca4304504be68939c4929e0831557097962b8\n* Patch commit: https://github.com/elixir-mint/mint/commit/b662d127d3028b5426c88d4c9cc7fe430491a10b","status":"published","published":"2026-07-09T23:19:23Z","modified":"2026-07-09T23:30:10.359407206Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:34.700741Z"}]}}