This vulnerability is a specification compliance failure, not a configuration oversight. The W3C Trace Context specification explicitly requires implementations to enforce limits on baggage entries and total header size — the language is mandatory ('MUST'), not advisory. The micrometer-tracing-bridge-brave library parses W3C baggage without applying these required limits, making it non-compliant with its own standard's security requirements. This is the same failure pattern seen in Log4Shell, JSON bombs, and XML entity expansion: a library defers validation upstream while the specification requires in-library enforcement precisely because upstream enforcement cannot be assumed across the ecosystem.
If you're running Spring Boot 3.x, you're exposed by default. The W3C propagation and baggage parsing activates automatically through transitive dependencies, meaning you inherited this vulnerability without making any explicit choice. The 'untrusted input' framing in the advisory is misleading for service mesh environments — tracing headers cross every trust boundary in your system by design, so treating internal service-to-service calls as 'trusted' collapses the threat model's assumptions.
The CVSS 5.3 score undersells the severity. An OutOfMemoryError triggering application crash via unbounded heap allocation is an availability impact beyond what the score conveys. Attack complexity is low — sending large HTTP headers requires no elevation, no special positioning, and many HTTP servers don't limit header sizes by default.
For remediation: update the micrometer-tracing-bridge-brave dependency to the patched version. More importantly, understand that this patch adds spec-compliant limit enforcement that should have been there from the start. If you're relying on upstream network components to limit header sizes, that's the exact architectural choice the W3C spec was written to prevent. Verify your tracing configuration explicitly enables the new limits rather than assuming they're enforced.