CVE-2026-59323: Micrometer Tracing Brave Bridge W3C Baggage propagation DoS vulnerability
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. Micrometer Tracing 1.7.0 Micrometer Tracing 1.6.0 - 1.6.6 Micrometer Tracing 1.5.0 - 1.5.12 Micrometer Tracing 1.4.13 and earlier
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.micrometer:micrometer-tracing-bridge-braveto a version that resolves this vulnerability.Fixed in 1.4.13 - Upgrade
Upgrade
io.micrometer:micrometer-tracing-bridge-braveto a version that resolves this vulnerability.Fixed in 1.5.12 - Upgrade
Upgrade
io.micrometer:micrometer-tracing-bridge-braveto a version that resolves this vulnerability.Fixed in 1.6.6 - Upgrade
Upgrade
io.micrometer:micrometer-tracing-bridge-braveto a version that resolves this vulnerability.Fixed in 1.7.0 - Configuration
Configure the HTTP server (and any upstream network components) to limit the maximum header size so artificially inflated W3C baggage headers cannot exhaust resources.
Network components / (HTTP) server receiving requests Header size limit (baggage header) = Limit/ensure it is not high enough to cause issues - Compensating control
Ensure the application does not process W3C baggage headers from untrusted sources (untrusted inbound requests/messages should not be accepted or used for baggage extraction).
Event History
Frequently Asked Questions
Are Spring Boot applications affected by default?
Spring Boot 3.x+ can meet key affected conditions by default: W3C propagation and baggage propagation are active by default. Exposure also requires a vulnerable Brave bridge version, a configured baggage manager, and acceptance of baggage headers from untrusted sources.
What does an attacker need to exploit this issue?
An attacker needs to send requests or messages with baggage headers to an affected application from an untrusted source. The receiving network path, including the HTTP server, must allow headers large enough to trigger problematic unbounded allocation.
Which deployments are most realistically exposed?
Deployments that process untrusted, effectively unlimited baggage-header input are the primary concern. The advisory notes that applications normally should not receive untrusted and unlimited baggage input, so environments with enforced header-size limits are less likely to be affected.
What can be done if the dependency cannot be changed immediately?
Limit incoming header sizes at the HTTP server and other network components, and prevent untrusted sources from supplying baggage headers where possible. These measures address the conditions that permit oversized baggage input to reach the application.