multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit.
severity
HIGH (availability / remote request amplification)
relevant links
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a41
as-of: 2026-02-04
policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (extractMultiBaggage)
attacker control: inbound HTTP request headers (many baggage field-values) → propagation.HeaderCarrier.Values("baggage") → repeated baggage.Parse + member aggregation
root cause
extractMultiBaggage iterates over all baggage header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).
impact
in a default net/http configuration (max header bytes 1mb), a single request with many baggage: header field-values can cause large per-request allocations and increased latency.
example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
- canonical:
per_req_alloc_bytes=10315458 and p95_ms=7
- control:
per_req_alloc_bytes=133429 and p95_ms=0
proof of concept
canonical:
mkdir -p poc
unzip poc.zip -d poc
cd poc
make test
output (excerpt):
[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage
[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165
control:
control output (excerpt):
[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480
expected: multiple baggage header field-values should be semantically equivalent to a single comma-joined baggage value and should not multiply parsing/alloc work within the effective header byte budget.
actual: multiple baggage header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.
fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for per_req_alloc_bytes and per_req_allocs, and p95_ms stays below 2ms.
poc.zip
PR_DESCRIPTION.md
References
multi-value
baggage:header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending manybaggage:header lines, even when each individual value is within the 8192-byte per-value parse limit.severity
HIGH (availability / remote request amplification)
relevant links
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a41
as-of: 2026-02-04
policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (
extractMultiBaggage)attacker control: inbound HTTP request headers (many
baggagefield-values) →propagation.HeaderCarrier.Values("baggage")→ repeatedbaggage.Parse+ member aggregationroot cause
extractMultiBaggageiterates over allbaggageheader field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).impact
in a default
net/httpconfiguration (max header bytes 1mb), a single request with manybaggage:header field-values can cause large per-request allocations and increased latency.example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
per_req_alloc_bytes=10315458andp95_ms=7per_req_alloc_bytes=133429andp95_ms=0proof of concept
canonical:
output (excerpt):
control:
cd poc make controlcontrol output (excerpt):
expected: multiple
baggageheader field-values should be semantically equivalent to a single comma-joinedbaggagevalue and should not multiply parsing/alloc work within the effective header byte budget.actual: multiple
baggageheader field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for
per_req_alloc_bytesandper_req_allocs, andp95_msstays below 2ms.poc.zip
PR_DESCRIPTION.md
References