Listen to this Post
The vulnerability resides in the baggage propagation logic of OpenTelemetry Java components: opentelemetry-api and opentelemetry-extension-trace-propagators. The affected classes (W3CBaggagePropagator, JaegerPropagator, OtTracePropagator) parse the `baggage` header without enforcing size or entry limits. An attacker can craft an HTTP request with an oversized `baggage` header (e.g., >8KB or with hundreds of entries). The parser iterates character-by-character through the entire header value, causing unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, a single malicious request can trigger cascading DoS: the first service propagates the oversized baggage to downstream services, which also parse it and suffer the same resource exhaustion. This fan-out effect amplifies the attack even to services that never directly received the original malicious request. The W3C Baggage specification recommends a maximum of 8192 bytes and 180 entries, but no limits were enforced. The fix in version 1.62.0 introduces propagator-level caps: 8192 total bytes across all baggage header values, and maximum 64 entries. Headers exceeding either limit are dropped at the point of limit violation, while already-extracted valid entries are retained. Workarounds rely on existing HTTP server header limits (e.g., Tomcat, Jetty, Netty default 8KB), which block external oversized headers but not internal non-HTTP or custom transport attacks.
dailycve form:
Platform: OpenTelemetry Java
Version: <1.62.0
Vulnerability: Unbounded baggage parsing
Severity: Medium
date: 2026-05-14
Prediction: Already patched 1.62.0
What Undercode Say:
Check vulnerable version
mvn dependency:tree | grep opentelemetry
Test oversized baggage header
curl -H "baggage: $(python3 -c 'print("a=b,"2000)')" http://target:8080
Verify fix in 1.62.0
grep 'opentelemetry.version' pom.xml
Monitor memory usage during attack
jstat -gc $(pgrep java) 1s
Simulate fan-out propagation
for i in {1..5}; do curl -H "baggage: $(dd if=/dev/zero bs=8193 count=1 | base64)" http://service-$i/; done
Exploit:
Send HTTP request with `baggage` header exceeding 8192 bytes or >180 entries. Example: `baggage: a=b,` repeated 10,000 times. No authentication needed. Internal attacker on non-HTTP transport (e.g., custom TCP) can send arbitrary length. The service hangs during parsing, memory spikes, CPU 100%. If upstream propagates baggage, downstream services also crash.
Protection from this CVE
Update to opentelemetry-api 1.62.0+. If unable, enforce HTTP header limits: Tomcat maxHttpHeaderSize, Jetty requestHeaderSize, Netty maxInitialLineLength. Gateway-level limit (e.g., 8KB) blocks external attackers. Disable baggage propagation if not needed: OpenTelemetry.getGlobalPropagators().remove(BaggagePropagator).
Impact
Denial of service via memory/CPU exhaustion. Limited impact for external attackers on default Java HTTP servers (8KB header limit). High impact for internal services using non-HTTP protocols (gRPC, custom TCP) where no transport limit exists. Fan-out amplification allows single compromised service to cascade DoS across microservice mesh.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
