CVE-2026-49753Medium▾ Sunlitmint: Content-Length header accepts non-RFC "+" sign prefix
▾ Sunlit zone — Low / medium · no exploitation signal
impact 27.5 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 29.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.5%
Mint's HTTP/1 client accepts Content-Length header values with a leading + sign (e.g. +0, +123), which RFC 7230 forbids (Content-Length = 1*DIGIT). On a connection shared with a strict fronting proxy or load balancer, this parser disagreement is a response-smuggling primitive: the proxy frames the body one way, Mint frames it another, and bytes meant for one response leak into the next consumer's response stream.
'Elixir.Mint.HTTP1.Parse':content_length_header/1 in lib/mint/http1/parse.ex parses the header value with Integer.parse/1. By design, Integer.parse/1 accepts an optional + or - sign prefix. The length >= 0 guard rules out negatives, but inputs such as "+0", "+123", or "+1" pass through and are returned as valid lengths.
A strict proxy or load balancer rejects or reframes Content-Length: +0\r\n, while Mint silently treats it as 0. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection) and the connection is shared with a proxy that frames the same bytes differently, trailing bytes the proxy attributes to response N are attributed by Mint to response N+1. Across trust boundaries (shared pools, multi-tenant fronting) this enables response smuggling.
HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n<smuggled bytes>.Content-Length: "+0" and an empty body, leaving the smuggled bytes sitting in the socket buffer for the next response.Response-smuggling / request-response desync primitive in Mint's HTTP/1 client parser. Anyone using Mint (directly or via Finch, Tesla's Mint adapter, Req, etc.) to talk through a shared or pooled connection where a fronting proxy enforces RFC 7230 strictly while Mint does not is exposed. The attacker is the response producer (a malicious or compromised upstream, or anything that can inject bytes into a shared origin response); exploitation into a cross-request data leak additionally requires the deployment to share a Mint connection across trust boundaries.
mint < 1.9.0Upgrade to a patched release:
mint 1.9.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-94194Medium· 6.3Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning th…
CVE-2026-82672Medium· 6.3Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabli…
CVE-2026-48861Lowmint has potential CRLF injection in its HTTP request line via unvalidated `method`/`target`
CVE-2026-49754Highmint: Unbounded CONTINUATION/HEADERS frame accumulation (CONTINUATION flood)
CVE-2026-48862Highmint: Unbounded streams map growth via PUSH_PROMISE without follow-up HEADERS
CVE-2026-92103Medium· 6.3Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory. Mint.…