CVE-2026-50274: Datadog dd-trace-go DoS Vulnerability

CVE-2026-50274 Overview

CVE-2026-50274 is a denial of service vulnerability in Datadog dd-trace-go, the Go client library for Datadog application performance monitoring, profiling, and security monitoring. Versions prior to 2.8.1 implement W3C baggage propagation without enforcing the DD_TRACE_BAGGAGE_MAX_ITEMS or DD_TRACE_BAGGAGE_MAX_BYTES limits on the extract path. A remote, unauthenticated attacker can send an HTTP request with a baggage header containing an arbitrarily large number of comma-separated key-value pairs or a single oversized value. This triggers unbounded CPU and memory consumption in any Go HTTP service that has baggage propagation enabled. Datadog fixed the issue in version 2.8.1.

Critical Impact
Remote, unauthenticated attackers can exhaust CPU and memory on any HTTP service using dd-trace-go with baggage propagation enabled, causing service outage.

Affected Products

Datadog dd-trace-go versions prior to 2.8.1
Go HTTP services that instrument requests with dd-trace-go and have W3C baggage propagation enabled
Downstream applications relying on the vulnerable tracer for distributed tracing context propagation

Discovery Timeline

2026-07-17 - CVE-2026-50274 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-50274

Vulnerability Analysis

The vulnerability sits in the tracer's HTTP header extraction path in ddtrace/tracer/textmap.go. When a request arrives, the tracer parses the baggage header by splitting the value on commas and iterating every entry. The pre-patch implementation did not consult the configured baggageMaxItems or baggageMaxBytes limits during extraction, even though those limits exist for the injection path. An attacker sending a header with millions of comma-separated pairs forces the tracer to allocate slices, trim strings, and perform key/value parsing for each entry. A single very large value produces the same effect through excessive string operations. This is a classic uncontrolled resource consumption weakness [CWE-770].

Root Cause

The extract routine trusted the size of attacker-controlled input. strings.Split(baggageHeader, ",") materializes the entire slice before any validation, and the subsequent loop applies strings.Cut and strings.TrimSpace to every element. No counter tracked item count or byte totals, so processing continued until the goroutine ran out of CPU time or the process ran out of memory.

Attack Vector

An unauthenticated attacker sends a single HTTP request to any endpoint served by an instrumented Go application. The baggage header contains either a very high number of k=v pairs separated by commas or a single pair with an extremely large value. The tracer processes the header before application logic runs, so authentication and routing do not mitigate the impact. Repeated requests amplify the effect and can take services offline.

 		return &ctx, nil
 	}
 
-	parts := strings.Split(baggageHeader, ",")
-
-	// 1) validation & single-trim pass
-	for i, kv := range parts {
+	// Single pass: enforce baggageMaxItems and baggageMaxBytes, validate, and apply.
+	ctr := 0
+	byteCount := 0
+	for kv := range strings.SplitSeq(baggageHeader, ",") {
+		itemBytes := len(kv)
+		if ctr > 0 {
+			itemBytes++ // comma separator
+		}
+		if ctr >= baggageMaxItems {
+			log.Warn("baggage item count exceeded limit (%d), dropping remaining items", baggageMaxItems)
+			break
+		}
+		if byteCount+itemBytes > baggageMaxBytes {
+			log.Warn("baggage byte limit exceeded (%d), dropping remaining items", baggageMaxBytes)
+			break
+		}
 		k, v, ok := strings.Cut(kv, "=")
 		trimmedK := strings.TrimSpace(k)
 		trimmedV := strings.TrimSpace(v)
 		if !ok || trimmedK == "" || trimmedV == "" {
 			log.Warn("invalid baggage item: %q, dropping entire header", kv)
-			return &ctx, nil
+			return &SpanContext{}, nil

Source: DataDog/dd-trace-go commit 192712b. The patch replaces the eager strings.Split with a streaming strings.SplitSeq and enforces both item and byte limits inside the loop, breaking out early once thresholds are exceeded.

Detection Methods for CVE-2026-50274

Indicators of Compromise

HTTP requests containing an unusually large baggage header, especially payloads exceeding several kilobytes or containing thousands of comma-separated pairs
Sudden spikes in CPU utilization and Go runtime heap growth on services instrumented with dd-trace-go
runtime.gcController pressure and increased garbage collection cycles correlating with inbound traffic patterns
HTTP 5xx error rates or request timeouts coinciding with elevated tracer function activity in profiles

Detection Strategies

Inspect web application firewall and reverse proxy logs for baggage header values above a reasonable threshold (for example, 8 KB or more than 64 items)
Compare running dd-trace-go module versions across the fleet against 2.8.1 using software composition analysis or Go build info
Enable Go pprof CPU and heap profiling on suspect services and look for hot paths inside ddtrace/tracer header extraction

Monitoring Recommendations

Alert on process-level CPU saturation combined with elevated inbound request rates to services that terminate distributed tracing headers
Track request latency percentiles per route and correlate regressions with the presence of baggage headers
Instrument reverse proxies to log and cap baggage header size before requests reach application backends

How to Mitigate CVE-2026-50274

Immediate Actions Required

Upgrade dd-trace-go to version 2.8.1 or later in all Go services and rebuild affected binaries
Audit dependency trees for transitive pulls of dd-trace-go using go list -m all and pin the fixed version
If immediate patching is not possible, disable W3C baggage propagation in the tracer configuration
Add ingress filtering to strip or size-limit the baggage header at the edge

Patch Information

The fix is released in dd-trace-go v2.8.1 and documented in GHSA-74j5-xf3v-crq8. The change was merged via pull request #4720 and enforces baggageMaxItems and baggageMaxBytes during extraction.

Workarounds

Remove or truncate the baggage header at load balancers, API gateways, or ingress controllers before requests reach vulnerable services
Configure the tracer to disable baggage propagation until the upgrade is deployed
Apply rate limiting on requests carrying baggage headers to reduce amplification potential

bash

# Update the dd-trace-go dependency to the patched release
go get github.com/DataDog/dd-trace-go/v2@v2.8.1
go mod tidy

# Example NGINX ingress rule to cap baggage header size
# large_client_header_buffers 4 8k;
# if ($http_baggage ~* ".{8192,}") { return 431; }