https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-09-30T14:26:57.429280+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/fkie_cve-2026-73494 fkie_cve-2026-73494 2026-09-30T14:26:57.431665+00:00

blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. Prior to 0.23.18 and from 1.0.0-M1 until 1.0.0-M42, five HTTP/1.1 conformance laxities in the hand-written Java parser under http/src/main/java/org/http4s/blaze/http/parser/ can cause blaze to derive a different request boundary than a stricter fronting intermediary. A default BlazeServerBuilder accepts invalid or valueless header field names that violate tchar syntax, obsolete folded field lines (obs-fold), unsupported Transfer-Encoding values, duplicate Content-Length fields, and requests containing both Transfer-Encoding and Content-Length. If a lenient or legacy proxy forwards the malformed bytes but interprets them differently, the disagreement can permit front-end authorization bypass, response-queue poisoning on pooled backend connections, or cache poisoning. Exploitation requires a pair of disagreeing parsers; no non-default blaze configuration is required. The affected checks are enforced in BodyAndHeaderParser and Http1ServerParser. This issue is fixed in versions 0.23.18 and 1.0.0-M42.

 https://db.gcve.eu/vuln/ghsa-mhvj-jhpq-885v GHSA-mhvj-jhpq-885v — blaze: Multiple HTTP/1.1 request-smuggling primitives in blaze's Java wire parser 2026-09-30T14:26:57.431768+00:00

Affected: Maven: org.http4s:http4s-blaze-server_2.13, Maven: org.http4s:blaze-http_2.13, Maven: org.http4s:blaze-http_3

### Summary Five independent HTTP/1.1 conformance laxities in blaze's hand-written Java parser (`http/src/main/java/org/http4s/blaze/http/parser/`) cause request-boundary disagreement with a stricter intermediary. All are reachable from a default `BlazeServerBuilder` with no non-default configuration.

### Impact Actual exploitability depends on the fronting proxy — a boundary disagreement requires a *pair* of parsers that disagree. Where the proxy forwards the malformed bytes and derives a different message boundary, the consequences are the standard set: front-end ACL/auth bypass, response-queue poisoning on pooled backend connections, and cache poisoning. Risk concentrates on lenient or legacy intermediaries.

### Workarounds Deploy behind an RFC-strict reverse proxy (nginx, HAProxy, Envoy, ALB) that rejects or re-serializes malformed requests at the edge; this neutralizes most of these for deployments that cannot upgrade immediately.