@opentelemetry/core EUVD-2026-38321

For standard Node.js HTTP servers with default settings, exploitation is practically constrained: Node.js's built-in --max-http-header-size limit of 16,384 bytes caps the total inbound header payload before the propagator is reached, and the baggage header must compete with all other headers for that budget. Exploitation risk is elevated - approaching the full CVSS severity - only when one or more of the following apply: (1) the service consumes baggage over a non-HTTP transport such as AMQP, Kafka, or a custom TextMapGetter implementation that does not impose independent size limits; (2) the operator has explicitly raised --max-http-header-size above its 16 KB default; or (3) the attacker is positioned on the internal network and can inject crafted baggage after a gateway strips its own header size enforcement. No authentication is required (CVSS PR:N). No user interaction is required. The vulnerability is present in any deployment using @opentelemetry/core < 2.8.0 with W3C Baggage propagation enabled.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) scores 5.3 Medium, and this rating is well-calibrated for the standard HTTP deployment case. Node.js enforces a default --max-http-header-size of 16,384 bytes on the aggregate of all HTTP headers, which independently constrains what an external attacker can deliver before the propagator is invoked. Furthermore, the baggage header is already resident in memory when extract() is called; the additional cost is object allocation overhead for splitting into entries, not an unbounded network read. The true risk surface expands materially for non-HTTP transports (AMQP, Kafka, gRPC custom propagators) or when operators have raised --max-http-header-size, both of which remove the natural ceiling. No EPSS score was provided in the intelligence data. No KEV listing exists and no public exploit code has been identified, consistent with the moderate-impact, configuration-dependent nature of the issue. SSVC signals: exploitation status is none/PoC, automatable is yes for vulnerable non-HTTP configs, technical impact is partial - overall this is a low-to-medium priority outside of non-HTTP transport deployments.

An attacker targeting a Node.js microservice that consumes baggage from an AMQP or Kafka message queue (bypassing the Node.js HTTP header size cap) crafts a message with a baggage value exceeding 8,192 bytes containing hundreds of key-value entries. When the service's instrumentation layer invokes W3CBaggagePropagator.extract() on the message carrier, the propagator allocates memory proportional to the oversized input across all entry objects with no cap, potentially exhausting heap resources under sustained message volume. No public exploit code exists at time of analysis, but the attack requires only the ability to publish messages to a queue consumed by the target service.