CVE-2026-54285

What it actually does

CVE-2026-54285 is a network-reachable denial-of-service weakness in OpenTelemetry JavaScript @opentelemetry/core before 2.8.0. The W3CBaggagePropagator.extract() function parses inbound W3C baggage HTTP headers without enforcing the W3C-recommended limits of 8,192 bytes and 180 entries. An unauthenticated remote sender can provide an oversized baggage header, causing memory allocation and parsing work proportional to attacker-controlled header size. The expected impact is increased memory consumption, CPU overhead, garbage-collection pressure, request latency, and potential process instability or service degradation. The flaw does not provide confidentiality or integrity compromise by itself.

Why it matters to the business

Applications and services using vulnerable OpenTelemetry JavaScript baggage propagation can be degraded or made less available by crafted HTTP requests. In practical terms, this can cause slow responses, increased infrastructure cost from autoscaling or resource exhaustion, failed health checks, container restarts, and reduced reliability of customer-facing or internal APIs. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the issue is easy to trigger over the network and should be remediated during normal patch cycles, with higher urgency for internet-facing Node.js services and high-traffic API gateways.

How an attack unfolds

An attacker identifies a Node.js or JavaScript service that uses OpenTelemetry JS context propagation and accepts inbound HTTP traffic. The attacker sends one or many HTTP requests containing a very large Baggage/baggage header or a header with an excessive number of comma-separated baggage entries. In vulnerable versions, inbound extraction parses the entire header without applying the expected size and entry-count limits. Repeated requests force the service to allocate memory and spend CPU time parsing attacker-controlled input. At low volume this may increase latency; at higher volume it can trigger garbage-collection churn, memory exhaustion, worker crashes, container restarts, or upstream timeout failures. No authentication or user interaction is required if the affected endpoint is reachable.

How to fix it

Upgrade OpenTelemetry JavaScript @opentelemetry/core to version 2.8.0 or later. Where dependencies are indirect, update lockfiles and dependency constraints so all deployed applications resolve to the fixed package version. Rebuild and redeploy affected services after the dependency update. As defense in depth, enforce request-header limits at reverse proxies, load balancers, API gateways, and application servers; specifically reject or truncate Baggage/baggage headers larger than 8,192 bytes or with more than 180 entries. If immediate upgrade is not possible, disable baggage propagation where operationally acceptable or add middleware that drops oversized baggage headers before OpenTelemetry extraction runs.

How to confirm the fix worked

Confirm package resolution shows @opentelemetry/core version 2.8.0 or later in package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and deployed artifacts. Verify that running containers or serverless bundles include the fixed version, not only source repositories. Test inbound requests with baggage headers larger than 8,192 bytes and with more than 180 entries; patched or mitigated services should reject, truncate, or ignore those headers without significant memory growth, latency increase, or process instability. Validate proxy/API gateway rules by sending oversized Baggage headers and confirming the request is blocked or normalized before reaching the application.

Typical attack path

1. Discover or select an HTTP endpoint backed by a Node.js service using OpenTelemetry JS baggage propagation.
2. Send crafted HTTP requests containing an oversized Baggage/baggage header, often much larger than 8,192 bytes or containing more than 180 comma-separated entries.
3. Cause the vulnerable W3CBaggagePropagator.extract() path to parse the oversized inbound header without enforcing limits.
4. Repeat or parallelize requests to amplify memory allocation, CPU usage, and garbage-collection pressure.
5. Observe service latency, errors, process restarts, failed health checks, or denial of service.

How to detect it

To determine whether exploitation was attempted or occurred, review HTTP access logs, API gateway logs, reverse proxy logs, WAF logs, APM traces, and application logs for unusually large Baggage/baggage headers or requests with excessive comma-separated baggage values. Correlate those requests with elevated Node.js memory usage, increased garbage-collection time, request latency spikes, HTTP 502/503/504 responses, process restarts, container OOMKilled events, Kubernetes CrashLoopBackOff events, or autoscaling bursts. Because the vulnerability is a resource-exhaustion issue, evidence may appear as performance degradation rather than a clean exploit marker. Prioritize searches around endpoints receiving repeated requests with very large request headers, abnormal total header sizes, or a high count of baggage key-value pairs. If logs do not retain request headers, use load balancer/WAF telemetry, packet captures, or temporary enhanced logging to measure Baggage header length and entry count.

• HTTP header name: Baggage
• HTTP header name: baggage
• Baggage header length > 8192 bytes
• baggage header length > 8192 bytes
• Baggage header entry count > 180
• baggage header entry count > 180
• Kubernetes container state reason: OOMKilled
• Kubernetes pod status: CrashLoopBackOff
• Node.js fatal error: JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• HTTP 502 responses correlated with oversized Baggage headers
• HTTP 503 responses correlated with oversized Baggage headers
• HTTP 504 responses correlated with oversized Baggage headers

What your security team should do

• Inventory Node.js and JavaScript services using OpenTelemetry JS, especially those using @opentelemetry/core and W3C baggage propagation on inbound HTTP requests.
• Prioritize internet-facing APIs, public web services, high-throughput services, and workloads with tight memory limits for upgrade to @opentelemetry/core 2.8.0 or later.
• Add or verify edge controls that cap total HTTP header size and specifically limit Baggage/baggage headers to the W3C-recommended 8,192 bytes and 180 entries.
• Review dependency lockfiles and container images to ensure vulnerable transitive versions are not still present after upgrade.
• Monitor for anomalously large Baggage headers, spikes in 4xx/5xx responses, Node.js heap usage, garbage-collection activity, request latency, OOM kills, and container restarts.
• Create regression tests that send oversized baggage headers to confirm future dependency or configuration changes do not reintroduce exposure.