Description

dd-trace-rb is Datadog's client library for Ruby. Prior to 2.32.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 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 2.32.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T18:17:49.990Z",
  "pubdate": "2026-09-14T18:17:49.990Z",
  "executiveSummary": "The dd-trace-rb library is susceptible to a Denial of Service (DoS) vulnerability due to improper input validation during the parsing of W3C baggage headers.\nThe vulnerability originates from the library's failure to enforce configured constraints on baggage items and byte sizes during the extraction process, despite these limits being strictly applied during injection.\nA remote, unauthenticated attacker can exploit this by crafting malicious HTTP requests containing excessive or oversized baggage headers.\nSuccessful exploitation triggers unbounded memory allocation and high CPU utilization during the parsing routine, potentially leading to service exhaustion and instability.\nThis issue affects all versions of dd-trace-rb prior to 2.32.0 where baggage propagation is enabled, which is the default configuration for the tracer.\nGiven the nature of the vulnerability—allowing remote, unauthenticated actors to degrade service availability—the risk level is significant for production environments utilizing default tracing configurations.",
  "technicalDetails": "The vulnerability resides within the W3C baggage extraction logic of the dd-trace-rb library. The root cause is a discrepancy in the implementation of resource constraints: while the library enforces DD_TRACE_BAGGAGE_MAX_ITEMS (default: 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default: 8192) during baggage injection, the extraction path fails to apply these same validations to incoming headers.\nWhen an HTTP service receives an incoming request with a W3C baggage header, the tracer attempts to parse the comma-separated key-value pairs. Because the extraction logic lacks bounds checking, the parser blindly allocates memory and processes entries based on the attacker's input, regardless of size or count. An attacker can supply a specially crafted header containing thousands of key-value pairs or a singular, extremely large string value.\nThe attack flow follows a straightforward progression: First, the attacker identifies an endpoint instrumented with dd-trace-rb where baggage propagation is enabled. Second, the attacker issues an HTTP request containing a malicious 'baggage' header. Third, the tracer's parsing routine initiates on the server side, attempting to deserialize the headers into memory. Because there are no limits, the application's memory usage spikes as the parser allocates objects for every parsed segment of the malicious header, and CPU cycles are exhausted while processing the disproportionately large payload.\nThis creates an unbounded resource consumption scenario that causes the host process to experience latency, thrashing, or termination due to memory exhaustion (OOM), resulting in a Denial of Service. The vulnerability does not require authentication or specific privileges, as the tracing component processes headers at the ingress layer of the HTTP request lifecycle. This exposure is magnified by the fact that baggage propagation is the default behavior in affected versions, meaning most deployments are vulnerable out-of-the-box without explicit configuration to disable the feature."
}