CVE-2026-49753: HTTP response smuggling in Mint HTTP/1 client via lenient Content-Length parsing
Summary
Mint's HTTP/1 client accepts Content-Length header values with a leading + sign (e.g. +0, +123), which RFC 7230 forbids (Content-Length = 1DIGIT). 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.
Details
'Elixir.Mint.HTTP1.Parse':contentlengthheader/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.
PoC
1. Stand up a raw TCP server that returns HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n<smuggled bytes>. 2. Connect a Mint HTTP/1 client to the server and issue a request. 3. Observe that Mint reports the response as status 200 with Content-Length: "+0" and an empty body, leaving the smuggled bytes sitting in the socket buffer for the next response.
Impact
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.
Resources
Introduction commit: https://github.com/elixir-mint/mint/commit/65e0e86d799a6d3b08e4372fccdd9747535e0dd6 Patch commit: https://github.com/elixir-mint/mint/commit/47e48027480228e4e32a0b4df39db497b4804921
Other sources
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint Mint allows attacker-controlled HTTP/1 servers to desynchronise response framing on shared connections.
Mint's HTTP/1 Content-Length parser, Mint.HTTP1.Parse.contentlengthheader/1 in lib/mint/http1/parse.ex, parses the header value with Integer.parse/1, which accepts an optional + or - sign prefix. The length >= 0 guard rejects negatives, but inputs such as +0 or +123 are returned as valid lengths. RFC 7230 specifies Content-Length = 1DIGIT, with no sign character permitted.
A fronting proxy or load balancer that strictly enforces the grammar will reject or reframe a header like Content-Length: +0, while Mint silently treats it as zero. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection shared across requesters), the parser disagreement is a response-smuggling primitive: the proxy delimits the body one way, Mint another, and bytes from one response get attributed to the next. Where the same Mint connection is shared across trust boundaries, an attacker-controlled upstream can leak bytes into a different consumer's response stream.
This issue affects mint: from 0.1.0 before 1.9.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/mintto a version that resolves this vulnerability.Fixed in 1.9.0 - Upgrade
Upgrade
elixir-mint/mintto a version that resolves this vulnerability.Fixed in 1.9.0Patch 47e48027480228e4e32a0b4df39db497b4804921 - Configuration
Ensure the Mint HTTP/1 client rejects or strips a leading '+' sign in Content-Length parsing; the problematic code path is `Mint.HTTP1.Parse.content_length_header/1` in `lib/mint/http1/parse.ex`, which currently uses `Integer.parse/1` (accepts optional '+'/'-' sign prefixes).
elixir-mint Mint HTTP/1 Content-Length parser Mint.HTTP1.Parse.content_length_header/1 (Integer.parse/1 usage) = reject signed Content-Length values (no leading '+' or '-' allowed) per RFC 7230 - Compensating control
When Mint HTTP/1 clients communicate through a shared/pool connection where a fronting proxy/load balancer strictly enforces RFC 7230 grammar, avoid sharing that connection across trust boundaries (e.g., separate pools/disable pooling across different trust domains) to reduce response-smuggling impact.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-49753?
CVE-2026-49753 has a medium severity rating of 6.3 based on the CVSS score.
What type of vulnerability is CVE-2026-49753?
CVE-2026-49753 is an HTTP request/response smuggling vulnerability due to lenient Content-Length parsing in the Mint HTTP/1 client.
How do I fix CVE-2026-49753?
To fix CVE-2026-49753, ensure you update your Mint HTTP client to a version that addresses the Content-Length parsing issue.
Who is affected by CVE-2026-49753?
CVE-2026-49753 affects applications using the Mint HTTP/1 client that interact with attacker-controlled HTTP/1 servers.
What are the consequences of exploiting CVE-2026-49753?
Exploiting CVE-2026-49753 can lead to desynchronisation of response framing on shared connections, potentially affecting data integrity.