Description

dd-trace-java is a Datadog APM client for Java. Prior to 1.62.0, W3C baggage extraction does not enforce DD_TRACE_BAGGAGE_MAX_ITEMS, which defaults to 64, or DD_TRACE_BAGGAGE_MAX_BYTES, which defaults to 8192, although those limits apply during baggage injection. A remote unauthenticated attacker can send a baggage HTTP header containing many comma-separated key-value pairs or a single very large value. The extraction path allocates map entries while parsing the attacker-controlled header on every request, causing unbounded CPU and memory consumption in an HTTP service where the baggage propagation style is enabled, which is the default for most affected tracers. This can cause denial of service. This issue is fixed in version 1.62.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T18:17:49.830Z",
  "pubdate": "2026-09-14T18:17:49.830Z",
  "executiveSummary": "The vulnerability in dd-trace-java, existing prior to version 1.62.0, involves an improper resource management flaw during the parsing of W3C baggage HTTP headers. Specifically, the tracer fails to enforce configured constraints on baggage item count and total byte size during the extraction phase, despite these limits being strictly applied during the injection phase.\nThis flaw allows a remote, unauthenticated attacker to trigger a Denial-of-Service (DoS) condition by supplying maliciously crafted, oversized, or excessively complex baggage headers. When processed by an HTTP service utilizing the default W3C baggage propagation style, the application allocates excessive heap memory and consumes significant CPU cycles to parse these headers.\nThe vulnerability represents a critical availability risk for JVM-based services instrumented with the affected tracer. Since the extraction logic executes automatically upon receiving incoming requests, an attacker can leverage this primitive to induce memory exhaustion or CPU starvation, potentially crashing the service or rendering it unresponsive to legitimate traffic. No authentication or elevated privileges are required to exploit this flaw, as the attack is performed via standard HTTP request headers sent to the service's public endpoints.",
  "technicalDetails": "The root cause of this vulnerability lies in an asymmetry between the injection and extraction logic within the dd-trace-java instrumentation library. While the library defines limits—specifically DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192)—to prevent header bloat, these constraints are only validated during the outbound propagation (injection) phase. The inbound processing (extraction) logic fails to apply these same validations when parsing W3C baggage headers.\nWhen an HTTP request containing a W3C baggage header is received, the tracer's extraction component attempts to parse the comma-separated key-value pairs. Because there are no bounds checking on the header length or the number of parsed map entries, the library performs dynamic memory allocation proportional to the size and density of the attacker-supplied header. An attacker can craft a payload containing thousands of distinct key-value pairs or a single massive value to force the JVM to perform excessive string splitting, object instantiation, and map insertion.\nThe attack flow is as follows: 1) The attacker identifies a service instrumented with dd-trace-java (prior to version 1.62.0) that has the default W3C baggage propagation style enabled. 2) The attacker transmits an HTTP request featuring a crafted 'baggage' header containing an arbitrarily high number of key-value pairs. 3) The target service's extraction logic iterates through this payload, attempting to parse and store each entry in an internal data structure without verification against DD_TRACE_BAGGAGE_MAX_ITEMS or DD_TRACE_BAGGAGE_MAX_BYTES. 4) The application experiences a sudden spike in heap usage due to uncontrolled object allocation, leading to frequent Garbage Collection (GC) pauses or an OutOfMemoryError (OOME). 5) Concurrently, the CPU is saturated by the parsing overhead of the oversized header. \nThe affected component is the W3C baggage propagation module within the tracer. Because this process occurs early in the request lifecycle, the impact is severe, enabling a low-effort DoS attack that does not require interaction with internal business logic. The lack of validation ensures that even a single request can cause significant latency or process failure if the payload is sufficiently large. This vulnerability is fixed in dd-trace-java version 1.62.0, which ensures the extraction logic correctly adheres to the configured resource limits, effectively dropping or truncating headers that exceed the defined maximums."
}