GHSA-rcgg-9c38-7xpx
OpenTelemetry Java SDK has Unbounded Memory Allocation in W3C Baggage Propagation
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Maven | io.opentelemetry:opentelemetry-api | < 1.62.0 | 1.62.0 |
| Maven | io.opentelemetry:opentelemetry-extension-trace-propagators | < 1.62.0 | 1.62.0 |
Details
As written in the advisory (Markdown source, shown as plain text).
## Overview
A vulnerability affects the baggage propagation implementation in
`opentelemetry-api` and `opentelemetry-extension-trace-propagators`. Parsing oversized baggage
causes unbounded memory allocation and CPU consumption. Because baggage is automatically
re-injected into every outgoing request, the effect can fan out to downstream services that
never received the original malicious request.
## Technical Details
- `W3CBaggagePropagator` did not enforce any limit on the total size or entry count of the
`baggage` header. The parser iterated character-by-character through the entire value
regardless of length.
- `JaegerPropagator` and `OtTracePropagator` had the same gap in their respective baggage
extraction paths.
- The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; none of
these limits were enforced.
## Impact
The practical availability impact for most deployments is limited. Every major Java HTTP server
enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to
8 KiB), constraining what an external attacker can deliver before the application is reached.
The risk is higher when transport-layer limits are absent — e.g., a compromised internal service
communicating over a non-HTTP or custom transport.
## Remediation
Update to version 1.62.0 or later ([#8380](https://github.com/open-telemetry/opentelemetry-java/pull/8380)).
The fix enforces limits consistent with the W3C Baggage specification at the propagator level:
- Maximum total baggage size: 8,192 bytes across all `baggage` header values
- Maximum number of entries: 64
Headers that would exceed either limit are dropped at the point the limit is reached;
already-extracted valid entries are retained.
## Workarounds
Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP
servers enforce an 8 KiB header limit by default, which mitigates external attack vectors
independently of this fix.
## References
- [W3C Baggage Specification §Limits](https://www.w3.org/TR/baggage/#limits)
References
External links from the advisory. They lead to third-party sites.
- https://github.com/open-telemetry/opentelemetry-java/security/advisories/GHSA-rcgg-9c38-7xpx
- https://nvd.nist.gov/vuln/detail/CVE-2026-45292
- https://github.com/open-telemetry/opentelemetry-java/pull/8380
- https://github.com/open-telemetry/opentelemetry-java/commit/03837d3c1763bc35464aea1078671e2ef2336a5f
- https://github.com/open-telemetry/opentelemetry-java
- https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.62.0