CVE-2026-54285: OpenTelemetry JavaScript Baggage Parser Memory Exhaustion Vulnerability

Technical summary

The W3CBaggagePropagator.extract() method in @opentelemetry/core does not enforce size constraints during the parsing of inbound W3C Baggage headers. While the W3C Baggage specification recommends a maximum payload of 8,192 bytes and 180 entries—limits that are already enforced during the inject() (outbound) phase—the extract() (inbound) phase accepts headers of any size. This asymmetry allows memory allocation to scale linearly with malicious header size, creating a denial-of-service condition. The vulnerability is rooted in CWE-770 (Allocation of Resources Without Limits or Throttling).

Business impact

This vulnerability can degrade or disable observability infrastructure that relies on OpenTelemetry. If your application uses OpenTelemetry for distributed tracing, metrics, or logging, an attacker sending crafted baggage headers could exhaust server memory, triggering application restarts, latency spikes, or complete service unavailability. The impact is most severe in high-traffic environments or in microservices architectures where many services parse the same malicious header. Organizations relying on OpenTelemetry for production observability should treat this as a stability and availability risk.

Affected systems

This vulnerability affects applications using the OpenTelemetry JavaScript client library (@opentelemetry/core) in versions prior to 2.8.0. Any Node.js or browser-based application that imports and uses the W3C Baggage propagator to process inbound HTTP headers is at risk. Microservices that receive traffic from untrusted or internet-facing sources are particularly vulnerable, as attackers can inject malicious baggage headers in HTTP requests.

Exploitability

The vulnerability is straightforward to exploit: an attacker simply needs to send an HTTP request with an oversized or high-cardinality W3C Baggage header to a target application running a vulnerable version of OpenTelemetry. No authentication, user interaction, or complex setup is required. The attack is network-accessible and requires no special privileges. However, the practical impact depends on the attacker's ability to send sustained traffic and the victim's memory capacity. A single malicious request may cause a temporary spike; repeated requests could force service degradation or failure.

Remediation

Upgrade @opentelemetry/core to version 2.8.0 or later. This version enforces both inbound and outbound size limits on baggage headers, aligning with W3C recommendations. After patching, validate that your application correctly initializes and uses the W3C Baggage propagator. Organizations unable to upgrade immediately should consider network-level mitigations such as WAF rules to reject oversized baggage headers or rate-limiting on inbound requests.

Patch guidance

Update @opentelemetry/core to 2.8.0 or later through your dependency management tool (npm, yarn, or pnpm). Review your package.json and package-lock.json to identify if @opentelemetry/core is a direct or transitive dependency. After upgrading, run your test suite to ensure compatibility with your observability configuration. If you use a monorepo or lock file, verify that all workspaces receive the patched version. Confirm the fix by checking that baggage header parsing now respects the 8,192-byte and 180-entry limits on both inbound and outbound paths.

Detection guidance

Monitor application logs and memory usage for anomalous patterns: sudden memory spikes without corresponding traffic increases, frequent garbage collection cycles, or out-of-memory exceptions correlated with specific HTTP requests. Network inspection tools can flag HTTP headers exceeding expected baggage sizes. Enable verbose logging in OpenTelemetry if available to capture header parsing behavior. If you run distributed tracing infrastructure, look for requests with unusually large baggage payloads or cardinality. Alert on memory pressure in services that parse baggage headers, especially during low-traffic periods when spikes are more visible.

Why prioritize this

While the CVSS score of 5.3 (Medium) reflects a denial-of-service vector with no confidentiality or integrity impact, the practical priority depends on your architecture. If your services are internet-facing or receive traffic from untrusted sources, the ease of exploitation and potential for cascading failures in microservices environments warrant near-term patching. If your OpenTelemetry infrastructure is internal-only, the risk is lower but should still be remediated during a planned maintenance window.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects a network-accessible vulnerability with low attack complexity, no privilege requirement, and no user interaction—factors that elevate exploitability. However, the impact is limited to availability (memory exhaustion), not confidentiality or integrity. The score does not capture the context-dependent risk: organizations with resilient auto-scaling or memory limits may see lower real-world impact than those with fixed infrastructure. The score serves as a baseline; contextualize it against your deployment topology and traffic sources.

Frequently asked questions