Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DDTRACEBAGGAGEMAXITEMS (default 64) and DDTRACEBAGGAGEMAXBYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.
// patchesThis is resolved in version 3.43.0 and later of the dd-trace-dotnet library.
// workaroundsIf users cannot upgrade immediately:
- Disable baggage extraction by removing baggage from DDTRACEPROPAGATIONSTYLE (or DDTRACEPROPAGATIONSTYLEEXTRACT if set independently).
- Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx largeclientheaderbuffers, Envoy maxrequestheaderskb).
Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High