GHSA-mhvj-jhpq-885v blaze: Multiple HTTP/1.1 request-smuggling primitives in blaze's Java wire parser

• Maven org.http4s:http4s-blaze-server_2.13: < 0.23.18 → fixed in 0.23.18 • Maven org.http4s:blaze-http_2.13: < 0.23.18 → fixed in 0.23.18 • Maven org.http4s:blaze-http_3: < 0.23.18 → fixed in 0.23.18 • Maven org.http4s:blaze-http_3: >= 1.0.0-M1, < 1.0.0-M42 → fixed in 1.0.0-M42 • Maven org.http4s:blaze-http_2.13: >= 1.0.0-M1, < 1.0.0-M42 → fixed in 1.0.0-M42

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.