CVE-2026-45292
Memory Exhaustion in OpenTelemetry Java Baggage Propagation
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open_telemetry | opentelemetry-java | to 1.62.0 (exc) |
| open_telemetry | opentelemetry-api | to 1.62.0 (exc) |
| open_telemetry | opentelemetry-extension-trace-propagators | to 1.62.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-45292 is a vulnerability in the OpenTelemetry Java implementation affecting the baggage propagation feature in opentelemetry-api and opentelemetry-extension-trace-propagators. Prior to version 1.62.0, the system did not enforce limits on the size or number of baggage entries, allowing parsing of oversized baggage headers. This caused unbounded memory allocation and excessive CPU consumption.
Because baggage is automatically re-injected into every outgoing request, the excessive resource consumption can propagate to downstream services that never received the original malicious request, amplifying the impact.
The vulnerability was fixed in version 1.62.0 by introducing limits on baggage entries: a maximum of 64 entries per baggage header and a maximum total size of 8192 bytes. Headers exceeding these limits are rejected or truncated to prevent resource exhaustion.
How can this vulnerability impact me? :
This vulnerability can lead to unbounded memory allocation and high CPU usage in applications using vulnerable versions of OpenTelemetry Java. This resource exhaustion can degrade the performance or availability of your services.
Because baggage data is propagated automatically to downstream services, the impact can cascade, affecting multiple services even if they never received the original malicious request.
In environments without transport-layer restrictions or HTTP header size limits, such as internal services using custom protocols, the risk of exploitation is higher.
To mitigate the risk, users should update to OpenTelemetry Java version 1.62.0 or later, which enforces baggage size and entry limits, or configure HTTP header size limits at the server or gateway level.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves oversized W3C baggage headers causing unbounded memory and CPU usage. Detection involves monitoring for unusually large or excessive baggage headers in requests handled by OpenTelemetry Java components.
Since headers exceeding limits are rejected and warnings are logged during extraction, reviewing application logs for warnings related to baggage header size or entry count can help detect exploitation attempts.
Network-level detection can include inspecting HTTP headers for baggage entries exceeding 8192 bytes or more than 64 entries.
Suggested commands (assuming a Linux environment) to detect oversized baggage headers in network traffic might include:
- Using tcpdump or tshark to capture HTTP traffic and filter for large headers, e.g., `tshark -Y 'http.header contains "baggage" and frame.len > 9000'`
- Using grep or similar tools on application logs to find warnings about baggage header rejection, e.g., `grep -i "baggage header rejected" /var/log/app.log`
- Monitoring CPU and memory usage spikes in services using vulnerable OpenTelemetry Java versions as indirect indicators.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade all affected OpenTelemetry Java components (opentelemetry-api and opentelemetry-extension-trace-propagators) to version 1.62.0 or later, where baggage size and entry limits are enforced.
If upgrading immediately is not possible, configure HTTP server or gateway layer header size limits to restrict baggage header sizes to 8192 bytes or less to prevent oversized baggage propagation.
Monitor application logs for warnings about baggage header rejections to identify potential attack attempts.
Consider limiting or validating baggage entries in custom transports or internal services that do not enforce HTTP header size limits.