CVE-2026-73494: 
Java vulnerability analysis and mitigation

CVE-2026-73494 is an HTTP request smuggling vulnerability (CWE-444) in blaze, a Scala library for building asynchronous pipelines used by the http4s ecosystem. Five HTTP/1.1 conformance laxities in blaze's hand-written Java parser allow it to derive different request boundaries than a stricter fronting intermediary, enabling smuggling attacks. Affected versions are blaze prior to 0.23.18 and from 1.0.0-M1 through 1.0.0-M41 (inclusive). The advisory was published on July 23, 2026, with the CVE formally assigned and published on September 14, 2026. It carries a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory).

The root cause (CWE-444) lies in five distinct HTTP/1.1 conformance gaps in blaze's BodyAndHeaderParser.java and Http1ServerParser.scala under http/src/main/java/org/http4s/blaze/http/parser/. Specifically, a default BlazeServerBuilder accepts: (1) invalid or valueless header field names violating tchar syntax, (2) obsolete folded field lines (obs-fold), (3) unsupported Transfer-Encoding values beyond chunked, (4) duplicate Content-Length headers, and (5) requests containing both Transfer-Encoding and Content-Length. When a lenient or legacy proxy forwards these malformed bytes while interpreting them differently than blaze does, the boundary disagreement creates a smuggling primitive. Exploitation requires no non-default blaze configuration and no attacker privileges, but does require a pair of disagreeing parsers — blaze and a fronting intermediary that forwards rather than rejects the malformed input (GitHub Advisory, Commit 4eec200, Commit 3f7c022).

Successful exploitation can lead to front-end ACL/authorization bypass, response-queue poisoning on pooled backend connections, and cache poisoning. Confidentiality and integrity are both rated High, as an attacker could access resources protected by front-end authorization controls or inject malicious content into responses served to other users. Availability is not directly impacted. Risk is concentrated in deployments behind lenient or legacy reverse proxies that forward malformed HTTP/1.1 requests rather than rejecting them (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the publication date. The EPSS score is 0.0, indicating very low current exploitation probability, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation is network-accessible and requires no authentication or user interaction, but attack complexity is rated High because it requires a specific combination of a lenient/legacy fronting proxy and a blaze backend that disagrees on request boundaries (GitHub Advisory, Feedly).

1. Identify target: Locate a deployment where a blaze-based http4s server (versions < 0.23.18 or 1.0.0-M1 through 1.0.0-M41) sits behind a lenient or legacy reverse proxy (e.g., an older nginx, HAProxy, or custom proxy) that forwards malformed HTTP/1.1 requests without rejecting them.
2. Craft a smuggling payload: Construct an HTTP/1.1 request exploiting one of the five laxities — for example, send a request with both a Transfer-Encoding: chunked header and a Content-Length header, or include a duplicate Content-Length header with differing values, or use an unsupported Transfer-Encoding value.
3. Send via the fronting proxy: Transmit the malformed request through the fronting proxy. The proxy interprets one boundary (e.g., using Content-Length) while blaze interprets another (e.g., using Transfer-Encoding), causing the backend to treat the tail of the first request as the beginning of a second request.
4. Achieve objective: Depending on the disagreement, the attacker can: (a) bypass front-end authorization by prepending a smuggled request that appears to originate from a trusted internal source; (b) poison the response queue on a pooled connection to inject a crafted response to another user; or (c) poison a shared cache with a malicious response (GitHub Advisory).

• Network: Unexpected HTTP/1.1 requests containing both Transfer-Encoding and Content-Length headers reaching the blaze backend; requests with duplicate Content-Length headers; requests with non-chunked Transfer-Encoding values (e.g., identity, gzip) forwarded by the proxy.
• Logs: Blaze/http4s access logs showing 400 Bad Message responses after patching (indicating prior acceptance of such requests); unusual sequences of requests where a single TCP connection appears to carry more requests than expected.
• Application Behavior: Unexpected authorization decisions (e.g., protected endpoints accessed without credentials); users receiving responses intended for other users; cache serving unexpected or injected content.
• Network: Requests with obs-fold (line-folded) header values or valueless/invalid header field names forwarded from the proxy to the blaze backend (GitHub Advisory).

Upgrade blaze to version 0.23.18 or 1.0.0-M42, which enforce strict HTTP/1.1 parsing by rejecting all five malformed request patterns with HTTP 400 responses (GitHub Advisory, Commit 3f7c022, Commit 927b677, Commit a54bc9c). As a workaround for deployments that cannot upgrade immediately, place blaze behind an RFC-strict reverse proxy (nginx, HAProxy, Envoy, or AWS ALB) configured to reject or re-serialize malformed HTTP/1.1 requests at the edge — this neutralizes most smuggling primitives by ensuring the proxy and backend agree on request boundaries. Avoid using lenient or legacy proxies that forward malformed bytes without normalization.

The vulnerability was discovered by ERobertGII and reviewed by rossabaker (a core http4s maintainer), as credited in the GitHub Security Advisory. The advisory references RFC 9110 §8.6 and RFC 9112 as the authoritative standards against which blaze's parser was found non-conformant. No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and standard CVE tracking databases (GitHub Advisory).