Description

blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. Prior to 0.23.18 and 1.0.0-M42, 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 and values, including X-Forwarded-For and internal authorization headers, that a fronting proxy sanitized from the request-header section, bypassing header-based trust decisions in the application. Any http4s application using BlazeServerBuilder over HTTP/1.1 whose routes or middleware trust proxy-set headers, including X-Forwarded-For, X-Real-IP, and X-Forwarded-Host, is affected. If a fronting proxy strips or normalizes those headers but forwards chunked bodies with trailers intact, an attacker can spoof client IP for allow-lists, rate limits, or auditing, forge the https scheme, or inject internal authorization headers. A promoted Connection: close trailer is also honored, allowing attacker-controlled termination of pooled backend connections. This issue is fixed in versions 0.23.18 and 1.0.0-M42.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-12T22:17:16.820Z",
  "pubdate": "2026-08-12T22:17:16.820Z",
  "executiveSummary": "An improper handling vulnerability exists in the blaze-server component of the blaze Scala library, specifically within HTTP/1.1 chunked-body processing. The vulnerability arises because the server improperly merges attacker-controlled chunked-body trailer fields directly into the primary Request.headers collection.\nThis flaw allows unauthenticated remote clients to inject arbitrary HTTP header names and values, successfully bypassing security trust boundaries established by fronting proxies. Applications utilizing http4s with BlazeServerBuilder over HTTP/1.1 that rely on proxy-set headers—such as X-Forwarded-For, X-Real-IP, X-Forwarded-Host, and internal authorization headers—are directly affected.\nThe risk implications are severe, enabling remote attackers to spoof client IP addresses to bypass rate limits, allow-lists, or security auditing, forge the https scheme, or inject internal authorization tokens. Additionally, attackers can promote a Connection: close trailer to forcefully terminate pooled backend connections.\nSuccessful exploitation requires the fronting proxy to strip or normalize standard request headers while forwarding chunked bodies with trailers intact. The vulnerability is fully resolved in blaze versions 0.23.18 and 1.0.0-M42.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper processing logic of HTTP/1.1 chunked transfer encoding within the blaze-server component. When processing HTTP/1.1 requests with chunked bodies, the server reads trailer fields sent at the termination of the chunked stream and merges them directly into the application's Request.headers data structure without adequate validation, sanitization, or segregation.\nBecause HTTP/1.1 trailer fields are fully controlled by the remote client, an unauthenticated attacker can append arbitrary key-value pairs in the trailer section of a chunked request. In typical architectures, a fronting reverse proxy inspects and sanitizes the initial request-header section (e.g., stripping client-supplied X-Forwarded-For or internal authorization headers to prevent spoofing). However, if the fronting proxy preserves and forwards the chunked-body trailers downstream, the blaze-server accepts these injected trailers and treats them as legitimate headers originating from the trusted proxy.\nThe step-by-step attack flow proceeds as follows: First, the unauthenticated remote client initiates an HTTP/1.1 request to the vulnerable blaze-server through a fronting proxy, utilizing chunked transfer encoding. Second, the client crafts the initial request headers to pass proxy filtering. Third, upon transmitting the chunked body, the client appends malicious trailer fields, such as 'X-Forwarded-For: 1.2.3.4' or internal authorization headers. Fourth, the fronting proxy forwards the chunked body and trailers to the backend blaze-server. Fifth, the blaze-server merges the trailer fields into Request.headers. Sixth, the application or its middleware consumes the forged headers, falsely trusting them for IP allow-listing, rate-limiting, auditing, or authorization decisions.\nFurthermore, the server honors a promoted 'Connection: close' trailer, allowing an attacker to trigger the premature termination of pooled backend connections, leading to potential denial of service or connection exhaustion conditions.\nThe vulnerable component is the HTTP/1.1 chunked-body handling mechanism within blaze-server, affecting all blaze versions prior to 0.23.18 and 1.0.0-M42. The attack requires network exposure to the blaze-server (either directly or via a misconfigured fronting proxy that forwards chunked trailers) and requires no authentication or special privileges."
}