Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
blaze-server can merge HTTP/1.1 chunked-body trailer fields into Request.headers. Because trailer fields are attacker-controlled, an unauthenticated remote client can inject arbitrary header names/values (e.g. X-Forwarded-For, internal-auth headers) that a fronting proxy sanitized from the request-header section, bypassing header-based trust decisions in the application. Impact Any http4s application using BlazeServerBuilder over HTTP/1.1 whose routes or middleware trust proxy-set headers (e.g., X-Forwarded-For, X-Real-IP, X-Forwarded-Host, org-internal auth headers) is affected. Where a fronting proxy strips/normalizes those headers but forwards chunked bodies with trailers intact, an attacker can spoof client IP for allow-lists/rate-limits/audit, forge the https scheme, or inject internal-auth headers. A promoted Connection: close trailer is also honored, allowing attacker-controlled termination of pooled backend connections. Workarounds Deploy behind a proxy that…
Recommended action: Upgrade to 1.0.0-M42 (pre-release) or 0.23.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.0.0-M42 (pre-release) or 0.23.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.