Am I affected?
Description
Mint's HTTP/1 Content-Length parser, 'Elixir.Mint.HTTP1.Parse':content_length_header/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 = 1*DIGIT, 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.
Weaknesses & attack patterns
Weakness
CWE-444
·
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
in catalog →
MITRE ↗
Attack patterns
CAPEC-273
·
HTTP Response Smuggling
MITRE ↗
Affected — Hex / mint Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / elixir-mint/mint Repository ↗
modules · source files · routines
References
GHSA-mjqx-c6f6-7rc2 ↗
vendor-advisory
EEF-CVE-2026-49753 ↗
related
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N