CVE-2026-59323 in Spring
Summary
by MITRE • 08/21/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability described constitutes a denial of service condition within applications utilizing the Micrometer Tracing library with the Brave bridge implementation, specifically affecting versions where W3C baggage propagation is active. This security flaw arises from an unbounded object allocation mechanism during the extraction and parsing of incoming HTTP headers designated for distributed tracing context. The core technical deficiency lies in the absence of validation logic to enforce limits on either the number of key-value pairs or the total size of the Baggage header field as it is processed by components such as BraveBaggageManager. According to industry standards, this flaw aligns with CWE-400, which describes uncontrolled resource consumption, and can be mapped to MITRE ATT&CK technique T1496, representing Resource Hijacking where an attacker consumes system resources to degrade service availability.
The operational impact of this vulnerability is severe for any application that inadvertently accepts baggage headers from untrusted sources without adequate input validation or size restrictions at the network edge. When a malicious actor sends requests containing artificially inflated Baggage headers with numerous key-value pairs, the application iterates through each entry and allocates new objects corresponding to those fields. Because there are no safeguards against excessive entries, this process triggers continuous garbage collection pressure and spikes in CPU utilization as the JVM attempts to manage the rapidly expanding heap space. In extreme cases, the memory consumption exceeds available resources, leading directly to an OutOfMemoryError that crashes the application or renders it unresponsive to legitimate traffic. This effectively allows a low-effort attack vector to disrupt service availability without requiring authentication or complex exploitation steps beyond crafting specific HTTP headers.
Mitigation strategies must address both the immediate code-level deficiency and broader architectural security practices. Developers should immediately upgrade to patched versions of io.micrometer:micrometer-tracing-bridge-brave that implement strict limits on baggage entry counts and header sizes as recommended by the W3C specification. Additionally, network infrastructure components such as reverse proxies or load balancers must be configured to enforce hard limits on HTTP header size, thereby preventing oversized headers from reaching the application server in the first place. It is also critical for security teams to audit configurations ensuring that baggage propagation is not enabled for endpoints processing untrusted input unless strictly necessary and properly sanitized. Adhering to these controls ensures compliance with W3C Trace Context security considerations which explicitly warn against trusting incoming baggage data without validation, thereby closing the gap between default library behavior and secure operational requirements.