Description

An application using Micrometer Tracing with W3C baggage propagation in the Brave bridge is vulnerable to denial of service (DoS) due to unbounded object allocation when extracting incoming baggage headers. Specifically, an application is vulnerable when all the following are true: * The application uses a vulnerable version of io.micrometer:micrometer-tracing-bridge-brave. * W3C propagation is active (either configured manually or active by default, such as in Spring Boot 3.x+). * Baggage propagation is enabled (which is the default in Spring Boot 3.x+) and a baggage manager (such as BraveBaggageManager) is configured to handle baggage fields. * The application processes requests or messages from untrusted sources with baggage headers which it normally should not, see:  https://www.w3.org/TR/trace-context/#security-considerations . * Network components including the (HTTP) server that receives the request do not limit the header size or the limit is high enough to cause issues. The last two points are very important: normally this should not affect applications because they should not receive untrusted and unlimited input for baggage. * The application processes requests or messages from untrusted sources with baggage headers. When extracting baggage from the W3C baggage header, incoming entries are parsed without enforcing limits on the number of entries or header size as mandated by the W3C Baggage specification. An attacker can send requests or messages with artificially inflated baggage headers containing many key-value pairs, causing unconditional BaggageField allocations per entry. This leads to garbage collection pressure, high CPU usage, and potential application crash via OutOfMemoryError.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-21T10:16:38.910Z",
  "pubdate": "2026-08-21T10:16:38.910Z",
  "executiveSummary": "A denial of service vulnerability exists in the Micrometer Tracing integration using the Brave bridge due to unbounded object allocation during the extraction of W3C baggage headers. The vulnerability arises when processing incoming requests or messages containing maliciously crafted, artificially inflated baggage headers without proper size or entry count restrictions.\nThe primary impact of this flaw is severe resource exhaustion, manifesting as high CPU utilization, extreme garbage collection pressure, and potential application termination via an OutOfMemoryError. Systems affected include applications utilizing io.micrometer:micrometer-tracing-bridge-brave with W3C propagation active, baggage propagation enabled, and a configured baggage manager such as BraveBaggageManager.\nExploitation requires the targeted application to process requests or messages from untrusted sources carrying manipulated baggage headers, coupled with network components or HTTP servers that fail to sufficiently restrict header sizes. Attackers do not require prior authentication or elevated privileges, provided they can transmit network traffic directly to the vulnerable application endpoint. Mitigation relies on restricting header sizes at the network perimeter, disabling unnecessary baggage propagation, or upgrading to a patched version when available.",
  "technicalDetails": "The root cause of the vulnerability lies in the W3C baggage header extraction logic within the io.micrometer:micrometer-tracing-bridge-brave component. When parsing incoming W3C baggage headers, the implementation fails to enforce mandatory limits on the total header size and the maximum number of individual baggage entries as specified by the W3C Baggage standard.\nThe vulnerable component is the baggage extraction and handling mechanism, specifically interacting with classes such as BraveBaggageManager when handling W3C propagation. In environments such as Spring Boot 3.x+, W3C propagation and baggage propagation are active by default, widening the potential attack surface if applications inadvertently process untrusted inputs.\nThe attack flow proceeds as follows. An unauthenticated attacker crafts an HTTP request or messaging payload containing a heavily inflated W3C baggage header packed with an excessive quantity of key-value pairs. This payload is transmitted over the network to the vulnerable application. Upon receipt, the underlying HTTP server or network component passes the large header to the Micrometer Tracing Brave bridge without rejection, due to insufficient header size constraints at the perimeter.\nDuring the extraction phase, the application parses the incoming baggage header and executes unconditional BaggageField allocations for every parsed entry. Because the parsing engine lacks defensive validation checks against the quantity of incoming entries or total payload volume, processing a maliciously saturated header forces the Java Virtual Machine to instantly allocate thousands of transient objects.\nThis uncontrolled object allocation induces severe garbage collection pressure and spikes CPU consumption as the runtime struggles to manage the memory overhead. If the volume of requests is sustained or the header payload is sufficiently massive, the application exhausts its available heap memory, resulting in an OutOfMemoryError and subsequent denial of service via application crash."
}