Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-49753

CVE-2026-49753: Elixir Mint HTTP Smuggling Vulnerability

CVE-2026-49753 is an HTTP request/response smuggling flaw in elixir-mint Mint that allows desynchronization of response framing on shared connections. This post covers technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-49753 Overview

CVE-2026-49753 is an HTTP Request/Response Smuggling vulnerability [CWE-444] in the elixir-mint Mint HTTP client library. The flaw exists in the HTTP/1 Content-Length parser at Mint.HTTP1.Parse.content_length_header/1 in lib/mint/http1/parse.ex. Mint uses Integer.parse/1, which accepts an optional + or - sign prefix, so values such as +0 or +123 are silently accepted as valid lengths. RFC 7230 defines Content-Length = 1*DIGIT and forbids sign characters. When a fronting proxy enforces the grammar strictly while Mint accepts the signed value, response framing desynchronises on shared connections. The issue affects Mint versions from 0.1.0 before 1.9.0.

Critical Impact

An attacker-controlled HTTP/1 upstream can leak response bytes into another consumer's stream when a Mint connection is shared across trust boundaries via keep-alive, pipelining, or connection pooling.

Affected Products

  • elixir-mint Mint HTTP client versions 0.1.0 through 1.8.x
  • Elixir applications using Mint for outbound HTTP/1 requests with pooled or shared connections
  • Downstream libraries depending on vulnerable Mint releases (e.g., Finch, Tesla adapters)

Discovery Timeline

  • 2026-06-02 - CVE-2026-49753 published to NVD
  • 2026-06-02 - Last updated in NVD database

Technical Details for CVE-2026-49753

Vulnerability Analysis

The vulnerability stems from lenient parsing of the Content-Length header in Mint's HTTP/1 implementation. Mint calls Integer.parse/1 on the raw header value, an Elixir standard library function that tolerates a leading + or - sign. A guard clause rejects negative values, but signed positives such as +0, +123, or +1024 pass through and are returned as valid body lengths. RFC 7230 explicitly restricts Content-Length to one or more decimal digits with no sign character permitted.

The security impact arises when Mint shares a TCP connection with another HTTP/1 actor that enforces the standard strictly. A fronting reverse proxy or load balancer will either reject the malformed header or reframe the request, while Mint silently treats +0 as zero. The two parties now disagree on where one response ends and the next begins. Bytes intended for one response can be attributed to another, producing a classic HTTP response smuggling primitive.

Root Cause

The root cause is an input validation defect in Mint.HTTP1.Parse.content_length_header/1. The parser delegates numeric validation to a general-purpose integer parser rather than enforcing the protocol grammar 1*DIGIT. This produces a parser-differential between Mint and any RFC-compliant intermediary on the same connection path.

Attack Vector

Exploitation requires that a Mint client share a pooled HTTP/1 connection across multiple requesters or trust boundaries, and that an attacker control an upstream HTTP/1 server reachable through a fronting proxy. The malicious origin returns a response containing Content-Length: +0 or a similar signed value, plus additional bytes in the socket buffer. The proxy and Mint disagree on the body length, so subsequent reads attribute leaked bytes to the next consumer's response. The vulnerability does not require authentication and is exploitable over the network.

No public proof-of-concept code has been published for CVE-2026-49753. Technical details are available in the GitHub Security Advisory GHSA-mjqx-c6f6-7rc2 and the fix commit 47e48027.

Detection Methods for CVE-2026-49753

Indicators of Compromise

  • HTTP response headers observed on the wire containing Content-Length with a leading + or - sign character.
  • Unexpected response body content delivered to a Mint client that does not match the issued request (size or content mismatch).
  • Proxy or WAF logs showing rejected or rewritten Content-Length headers from upstream origins served through a Mint-based gateway.

Detection Strategies

  • Inspect application dependency manifests (mix.exs, mix.lock) for mint versions below 1.9.0 and flag for upgrade.
  • Deploy network traffic inspection rules that match malformed Content-Length values containing non-digit prefixes on HTTP/1 responses.
  • Correlate proxy access logs with Mint client logs to identify response-length disagreements between hops on shared keep-alive connections.

Monitoring Recommendations

  • Enable structured logging in Mint-based clients to capture response framing anomalies and unexpected connection resets.
  • Monitor connection pool metrics for elevated rates of socket closure or response parse errors after upgrading.
  • Alert on outbound HTTP/1 traffic to untrusted origins from services that also handle multi-tenant traffic over pooled connections.

How to Mitigate CVE-2026-49753

Immediate Actions Required

  • Upgrade mint to version 1.9.0 or later in all Elixir applications and rebuild release artifacts.
  • Audit downstream libraries such as Finch and Tesla adapters that depend on Mint and update their transitive Mint dependency.
  • Identify deployments where a single Mint connection pool is shared across multiple tenants or trust boundaries and prioritise patching those first.

Patch Information

The maintainers fixed the issue in Mint 1.9.0. The patch tightens Mint.HTTP1.Parse.content_length_header/1 to reject Content-Length values containing any sign character, conforming to the 1*DIGIT grammar in RFC 7230. See GitHub commit 47e48027 and the CNA advisory at cna.erlef.org for the authoritative fix details. The OSV record EEF-CVE-2026-49753 tracks affected version ranges.

Workarounds

  • Disable HTTP/1 connection reuse and pipelining in Mint client configuration where upgrade is not immediately possible.
  • Place a strict RFC 7230-compliant reverse proxy in front of untrusted HTTP/1 origins to normalise or reject malformed Content-Length headers before they reach Mint.
  • Segregate Mint connection pools so that no single pool is shared across distinct tenants or trust boundaries until the patched version is deployed.
bash
# Configuration example: pin patched Mint version in mix.exs
defp deps do
  [
    {:mint, "~> 1.9.0"}
  ]
end

# Then update and verify
mix deps.update mint
mix deps.get
mix deps | grep mint

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.