CVE-2026-48861 Root-Cause Fix for Mint HTTP/1 Method CRLF Injection

Vulnerability

CVE-2026-48861 describes an HTTP request splitting and smuggling issue in Elixir Mint caused by accepting attacker-controlled control characters in the HTTP method parameter. The vulnerable behavior is consistent with the request-line construction shown in the related one-hop reference, where the method is concatenated directly into the HTTP/1.1 request line without validation: commit 8db1acff30b6a9433762c18b1e1f891b8c1f74f7.

If a caller can supply a method containing CR, LF, spaces, or other non-token bytes, the serialized request line can be broken into multiple protocol elements. That enables classic request splitting and can become request smuggling when an intermediary and origin disagree on message boundaries. The issue is especially severe because the method appears at the very start of the request line, so injected CRLF can terminate the line before the intended path and version are emitted.

[method, ?\s, path, " HTTP/1.1\r\n"]

The CVE and MITRE records establish the vulnerability scope and impact: NVD, CVE.org. The patch source confirms the root cause was specifically lack of validation on the method field before encoding: commit fad091454cbb7449b19edb8e1fee12ca7cf28c3a.

Patch

The fix adds explicit method validation in Mint’s HTTP/1 request encoder before request-line serialization. The new logic iterates each byte of the method and rejects any character that is not an HTTP token character via is_tchar(char). On failure it throws a structured Mint error that is surfaced as {:invalid_request_method, method}. The public error formatter in lib/mint/http1.ex was updated accordingly, and regression tests were added for CRLF injection, embedded spaces, and control characters, while preserving acceptance of a valid extension method such as PROPFIND: commit fad091454cbb7449b19edb8e1fee12ca7cf28c3a.

defp validate_method!(method) do
  _ =
    for <<char <- method>> do
      unless is_tchar(char) do
        throw({:mint, {:invalid_request_method, method}})
      end
    end

  :ok
end

The tests directly exercise the exploit class by attempting to encode a method containing CRLF and a smuggled header, and expecting an error instead of serialized wire data. This is the correct choke point because it prevents malformed bytes from ever reaching the transport layer.

Review

Pros

• The patch addresses the actual injection primitive: untrusted method bytes entering the request line without validation.
• Validation is aligned with HTTP token semantics by checking each byte with is_tchar, which is stricter and more protocol-correct than ad hoc CRLF filtering.
• The new error type {:invalid_request_method, method} improves diagnosability for callers and keeps failure explicit.
• Regression coverage is well targeted: CRLF payload, whitespace in method, tab/control character, and a valid custom token method.
• The fix preserves legitimate extension methods, avoiding an overly narrow allowlist of common verbs only.

Cons

• The provided patch evidence is scoped to method validation only. The related reference still contains a TODO noting header validation concerns, which indicates other request components may require separate hardening against CRLF or syntax abuse: commit 8db1acff30b6a9433762c18b1e1f891b8c1f74f7.
• No patch snippet here shows equivalent validation for path, header names, or header values. That does not invalidate this fix for CVE-2026-48861, but it means the review should not overstate broader request serialization safety.
• The implementation uses throw/catch-style internal control flow. That is consistent with existing Mint patterns, but it is less direct than returning tagged errors from the validator itself.

Verdict

Root-cause.

This patch fixes the documented vulnerability at the correct boundary by enforcing protocol-valid method tokens before request-line construction. Because the exploit depends on injecting CRLF and other illegal bytes through the method field, rejecting non-tchar bytes removes the vulnerable state rather than merely detecting a few payload variants. The added tests are source-grounded and map directly to the attack described in NVD. The remaining concerns around other request components are separate hardening opportunities, not evidence that this method-specific fix is incomplete for CVE-2026-48861.