CVE-2026-45292

What it actually does

CVE-2026-45292 is a denial-of-service flaw in OpenTelemetry Java baggage propagation before version 1.62.0. The vulnerable baggage parser can allocate unbounded memory and consume excessive CPU when processing oversized W3C baggage values from incoming requests. Because OpenTelemetry baggage is propagated automatically, a malicious baggage header can also be re-injected into outbound requests, amplifying resource consumption across downstream Java services that did not directly receive the original malicious request. The impact is availability-focused; confidentiality and integrity are not directly affected.

Why it matters to the business

An unauthenticated remote attacker can degrade or interrupt Java services that use vulnerable OpenTelemetry baggage propagation by sending oversized telemetry context data. This can cause slow responses, elevated infrastructure costs, container restarts, JVM out-of-memory failures, cascading failures across service-to-service calls, and reduced reliability of business applications. Although EPSS is currently low and the issue is not listed in CISA KEV or known ransomware use, OpenTelemetry is commonly deployed across microservice environments, so a single exposed edge service may propagate the condition into internal dependencies.

How an attack unfolds

An attacker identifies an HTTP endpoint backed by a Java service using a vulnerable OpenTelemetry Java version. The attacker sends requests containing an excessively large or complex baggage header. When the service parses the header, the vulnerable implementation performs unbounded allocation and CPU-intensive processing, which can trigger high garbage collection activity, thread starvation, request latency, or JVM out-of-memory termination. If the service makes outbound calls while preserving baggage context, the same oversized baggage value may be inserted into downstream requests, causing additional services to parse and propagate the malicious value. The attack can therefore expand from one reachable endpoint into a broader service mesh or microservice chain until upstream gateways, application limits, or patched OpenTelemetry libraries stop propagation.

How to fix it

Upgrade affected OpenTelemetry Java components to version 1.62.0 or later, specifically any use of opentelemetry-api and opentelemetry-extension-trace-propagators prior to 1.62.0. Review dependency lockfiles, Maven dependency trees, Gradle dependency reports, shaded JARs, and vendor-packaged agents or frameworks that may bundle OpenTelemetry Java. Where immediate upgrade is not possible, apply compensating controls: enforce strict maximum HTTP header size at load balancers, API gateways, ingress controllers, reverse proxies, and application servers; reject or strip oversized baggage headers; disable or limit baggage propagation where it is not required; and add service-level resource limits and circuit breakers to reduce blast radius. Ensure transitive dependencies are also updated so older OpenTelemetry artifacts are not retained alongside patched versions.

How to confirm the fix worked

Confirm that all deployed Java applications and packaged artifacts resolve OpenTelemetry Java libraries to 1.62.0 or later. For Maven, review `mvn dependency:tree` output for `io.opentelemetry:opentelemetry-api` and `io.opentelemetry:opentelemetry-extension-trace-propagators`; for Gradle, review `gradle dependencies` or dependency lockfiles. Validate container images and fat JARs with software composition analysis to detect embedded older versions. Confirm gateway, proxy, servlet container, and application server limits reject unusually large request headers before they reach application code. In a controlled non-production environment, test that oversized baggage input is rejected, truncated, or handled without abnormal CPU, memory, garbage collection, or downstream propagation behavior.

Typical attack path

1. Find an externally reachable application or API likely instrumented with OpenTelemetry Java.
2. Send HTTP requests containing an oversized W3C baggage header.
3. Trigger excessive memory allocation and CPU consumption during baggage parsing.
4. Cause application latency, garbage collection pressure, thread exhaustion, or JVM out-of-memory failures.
5. Rely on automatic baggage re-injection so outbound service calls carry the same oversized value.
6. Induce cascading degradation or restarts in downstream Java services using vulnerable OpenTelemetry baggage propagation.

How to detect it

To determine whether this was already exploited, correlate edge, load balancer, API gateway, reverse proxy, application, JVM, container, and APM logs. Look for requests with unusually large `baggage` headers, repeated 400/431/413 responses, sudden spikes in 500/502/503/504 errors, high CPU, prolonged garbage collection pauses, JVM heap exhaustion, and container restarts or OOMKilled events. Review access logs that capture request headers or header sizes, WAF logs, ingress controller logs, service mesh telemetry, and distributed tracing metadata. Pay special attention to time windows where a single inbound request is followed by multiple downstream requests carrying an identical or similarly large baggage value. For Java applications, inspect stack traces, GC logs, heap-dump creation events, and application logs referencing OpenTelemetry baggage propagation classes. There are no named threat actors or KEV-driven campaigns currently associated with this issue, so detection should focus on behavioral evidence of oversized baggage processing and propagation rather than actor-specific infrastructure.

• baggage:
• Baggage
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Requested array size exceeds VM limit
• io.opentelemetry.api.baggage
• io.opentelemetry.api.baggage.propagation
• io.opentelemetry.api.baggage.propagation.W3CBaggagePropagator
• io.opentelemetry.extension.trace.propagation
• OOMKilled
• HTTP 431
• Request Header Fields Too Large
• upstream sent too big header
• request header too large
• HeaderTooLarge
• GC overhead limit exceeded

What your security team should do

• Prioritize upgrading OpenTelemetry Java dependencies to 1.62.0 or later across internet-facing and high-traffic Java services.
• Inventory services that use W3C baggage propagation, especially services that automatically forward context to downstream dependencies.
• Add or verify HTTP request header size limits at ingress, API gateway, reverse proxy, and application-server layers.
• Consider stripping or disabling baggage propagation at trust boundaries unless there is a clear business need to accept external baggage values.
• Search historical logs for large baggage headers correlated with JVM memory pressure, high CPU, 5xx spikes, OOM kills, or container restarts.
• Add monitoring for abnormal baggage header sizes and repeated requests carrying baggage headers near configured limits.
• Review downstream service logs for the same oversized baggage value appearing after a single upstream request, which may indicate propagation fan-out.
• Because the vulnerability was published 75 days ago, treat unpatched deployments as overdue even though there is no current KEV listing or known mature public exploit signal.