CVE-2026-73494: Blaze HTTP Parser Auth Bypass Vulnerability

CVE-2026-73494 Overview

CVE-2026-73494 is an HTTP request smuggling vulnerability [CWE-444] in blaze, a Scala library for building asynchronous network I/O pipelines. The hand-written Java HTTP/1.1 parser under http/src/main/java/org/http4s/blaze/http/parser/ contains five conformance laxities that can cause blaze to derive a different request boundary than a stricter fronting proxy. When paired with a lenient intermediary, the disagreement enables front-end authorization bypass, response-queue poisoning on pooled backend connections, and cache poisoning. The issue affects versions prior to 0.23.18 and versions 1.0.0-M1 through 1.0.0-M41, and is fixed in 0.23.18 and 1.0.0-M42.

Critical Impact
A default BlazeServerBuilder deployed behind a lenient proxy can be leveraged to smuggle requests, bypass authorization at the edge, and poison shared caches or backend connection pools.

Affected Products

blaze versions prior to 0.23.18
blaze milestone versions 1.0.0-M1 through 1.0.0-M41
Any http4s server deployment using the default BlazeServerBuilder behind an HTTP/1.1 intermediary

Discovery Timeline

2026-09-14 - CVE-2026-73494 published to the National Vulnerability Database
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-73494

Vulnerability Analysis

The blaze parser accepts five categories of malformed HTTP/1.1 constructs that RFC 9112 forbids. It permits header field names containing characters outside the tchar set, accepts valueless header fields, honors obsolete line folding (obs-fold), tolerates unsupported Transfer-Encoding values, allows duplicate Content-Length headers, and processes requests carrying both Transfer-Encoding and Content-Length. Each laxity creates an opportunity for two parsers on the same request path to disagree on where one request ends and the next begins.

When a fronting proxy interprets the malformed bytes differently from blaze, an attacker can prepend crafted bytes that the proxy treats as part of one request while blaze treats them as the start of the next. This mismatch is the classic precondition for HTTP request smuggling.

Root Cause

The checks that enforce field-name syntax, single Content-Length values, and rejection of non-chunked Transfer-Encoding were missing from BodyAndHeaderParser and Http1ServerParser. The parser prioritized permissive behavior over strict RFC compliance.

Attack Vector

Exploitation is network-based and requires no authentication or user interaction, but depends on a specific topology: blaze must sit behind an intermediary that parses HTTP/1.1 differently. No non-default blaze configuration is required.

java

// Security patch: HttpTokens.java - enforce RFC 9110 tchar in header field names
// Source: https://github.com/http4s/blaze/commit/4eec2007806aa9acfefb00ebb636ddc39a147a96
public static boolean isTchar(char ch) {
  if ((ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || (ch >= '0' && ch <= '9')) {
    return true;
  }
  // https://www.rfc-editor.org/info/rfc9110/#name-tokens
  switch (ch) {
    case '!': case '#': case '$': case '%': case '&': case '\'':
    case '*': case '+': case '-': case '.': case '^': case '_':
    case '`': case '|': case '~':
      return true;
    default:
      return false;
  }
}

java

// Security patch: BodyAndHeaderParser.java - reject invalid characters in header names
// Source: https://github.com/http4s/blaze/commit/4eec2007806aa9acfefb00ebb636ddc39a147a96
case HEADER_IN_NAME:
  for (ch = next(in, false); ch != ':' && ch != HttpTokens.LF; ch = next(in, false)) {
    if (ch == HttpTokens.EMPTY_BUFF) return false;
    if (!HttpTokens.isTchar(ch)) {
      shutdownParser();
      throw new BadMessage("Invalid header name");
    }
    putChar(ch);
  }

Detection Methods for CVE-2026-73494

Indicators of Compromise

Inbound HTTP requests containing both Transfer-Encoding and Content-Length headers on the same message.
Requests presenting duplicate Content-Length values or Transfer-Encoding values other than chunked.
Header field names containing whitespace, control characters, or bytes outside the RFC 9110 tchar set.
Requests using obsolete line folding (obs-fold) where a header value begins with SP or HTAB on a continuation line.

Detection Strategies

Deploy an HTTP-aware inspection layer between clients and blaze that rejects the five malformed constructs listed above before they reach the application.
Correlate front-end proxy access logs against blaze application logs to identify request-count or byte-boundary mismatches on the same TCP connection.
Alert on backend responses returned to the wrong client identity, which is a downstream symptom of response-queue poisoning.

Monitoring Recommendations

Track HTTP/1.1 parse-error and BadMessage rates from blaze after upgrading; sustained spikes indicate probing.
Monitor cache-hit anomalies where cached responses do not match the originating request URL or method.
Log and review any request that arrives with a Transfer-Encoding value other than chunked.

How to Mitigate CVE-2026-73494

Immediate Actions Required

Upgrade blaze to 0.23.18 (stable line) or 1.0.0-M42 (milestone line) as soon as possible.
Inventory http4s services that use BlazeServerBuilder and prioritize any exposed behind shared proxies, CDNs, or load balancers.
Configure fronting intermediaries to strictly reject requests with duplicate Content-Length, both Transfer-Encoding and Content-Length, or non-chunkedTransfer-Encoding values.

Patch Information

The fix is delivered in blaze v0.23.18 and blaze v1.0.0-M42. Technical details are documented in GitHub Security Advisory GHSA-mhvj-jhpq-885v. Enforcement is added in BodyAndHeaderParser and Http1ServerParser to validate tchar in field names, require header values, reject obs-fold, reject non-chunked Transfer-Encoding, and reject duplicate or conflicting length declarations.

Workarounds

If immediate patching is not possible, place a strict HTTP/1.1-conformant reverse proxy in front of blaze and configure it to reject the five malformed constructs.
Disable HTTP connection reuse to backend blaze instances where feasible, reducing the impact of response-queue poisoning.
Where practical, migrate exposed endpoints to HTTP/2 termination at the edge to eliminate HTTP/1.1 boundary ambiguity between hops.

bash

# Example sbt dependency update to the patched blaze release
libraryDependencies += "org.http4s" %% "blaze-http" % "0.23.18"
# Or for the milestone line:
# libraryDependencies += "org.http4s" %% "blaze-http" % "1.0.0-M42"