ddtrace@4.7.0rc1

ddtrace is a Datadog APM client library

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the _BaggageHeader._extract parser in ddtrace/propagation/http.py. An attacker can force unbounded CPU and memory use by sending a request with a baggage header containing an arbitrarily large number of comma-separated key-value pairs or a single oversized value. The extraction path for W3C baggage parses every incoming pair into a dictionary without enforcing DD_TRACE_BAGGAGE_MAX_ITEMS or DD_TRACE_BAGGAGE_MAX_BYTES, so internet-facing services with baggage propagation enabled can be driven into excessive per-request allocation and processing, degrading or crashing the application.

Notes

• The default baggage propagation style is enabled in most affected tracers, so exposure is tied to deployments that have not explicitly narrowed DD_TRACE_PROPAGATION_STYLE or DD_TRACE_PROPAGATION_STYLE_EXTRACT to exclude baggage.
• The published patch notes and tests show the extract-side limits track the same defaults as injection: DD_TRACE_BAGGAGE_MAX_ITEMS defaults to 64 and DD_TRACE_BAGGAGE_MAX_BYTES defaults to 8192, which means the vulnerable path could exceed those limits even when applications relied on the documented defaults.

Workarounds

• Remove baggage from DD_TRACE_PROPAGATION_STYLE or from DD_TRACE_PROPAGATION_STYLE_EXTRACT if you set extraction styles separately; this disables baggage extraction and blocks the attacker-controlled baggage header from being parsed on incoming requests.
• Cap the maximum HTTP request header size at an upstream proxy or web server, such as Apache LimitRequestFieldSize, Nginx large_client_header_buffers, or Envoy max_request_headers_kb; this limits the size of incoming baggage headers and reduces the DoS blast radius.

Upgrade ddtrace to version 4.8.2 or higher.