In the Mint HTTP/1 client the Content‑Length header is parsed by Integer.parse/1, which accepts an optional "+" or "-" sign. Although a guard later rejects negative values, inputs such as "+0" or "+123" are treated as valid lengths. RFC 7230 defines Content‑Length as a sequence of digits only, so this permissive parsing introduces a mismatch with strictly following implementations. Because Mint silently accepts the signed value while a fronting proxy or load balancer rejects it, the two parties disagree on where the body ends, allowing a malicious upstream server to transmit data across the demarcation intended for the next response. The result is that bytes from one response can be delivered into another consumer’s stream, leaking confidential information or enabling injection of arbitrary content. This flaw corresponds to CWE‑444, which describes inconsistent interpretation of input.

The vulnerability impacts the Elixir Mint library, affecting all releases from 0.1.0 up to, but not including, 1.9.0. Any application that depends on any of those versions and uses shared or pooled HTTP/1 connections is potentially exposed.

The CVSS score of 6.3 places the issue in the medium severity range. No EPSS score is available, and the vulnerability is not listed in CISA’s KEV catalog. The attack can be carried out by an attacker who controls an upstream HTTP/1 server that shares a connection with the client, such as a fronting proxy or load balancer that enforces strict grammar on incoming responses. By sending a signed Content‑Length header over a keep‑alive or pooled connection, the attacker can desynchronise the framing and smuggle data into a downstream response. Exploitation therefore requires the ability to serve HTTP/1 responses to the vulnerable client.