CVE-2026-29181 is a high-severity (CVSS 7.5) CWE-770 vulnerability in go.opentelemetry.io/otel. A fix is available for go.opentelemetry.io/otel — see the affected versions and patch details below.
OpenTelemetry-Go multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-29181.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-29181 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
go.opentelemetry.io/otelReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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
- repository: https://github.com/open-telemetry/opentelemetry-go
- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a 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=10315458andp95_ms=7 - control:
per_req_alloc_bytes=133429andp95_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:
cd poc
make 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | go.opentelemetry.io/otel | ≥ 1.36.0&&< 1.41.0 | 1.41.0go get go.opentelemetry.io/otel@v1.41.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.opentelemetry.io/otel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update go.opentelemetry.io/otel to 1.41.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-29181 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-29181 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-29181. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important denial of service vulnerability in OpenTelemetry-Go, affecting Red Hat Multicluster Engine for Kubernetes. A remote attacker can exploit this flaw by sending multiple crafted `baggage` HTTP header lines, leading to excessive CPU and memory consumption and potentially rendering services…
| Product | Fixed in | Advisory |
|---|---|---|
| Cert Manager support for Red Hat OpenShift release 1.19 | cert-manager/cert-manager-istio-csr-rhel9:1788348594 | RHSA-2026:63140 |
| Cluster Observability Operator 1.5.0 | cluster-observability-operator/cluster-observability-rhel9-operator:1787593637 | RHSA-2026:61314 |
| Logging Subsystem for Red Hat OpenShift 6.2 | openshift-logging/cluster-logging-rhel9-operator:1789050399 | RHSA-2026:68349 |
| Logging Subsystem for Red Hat OpenShift 6.6 | openshift-logging/cluster-logging-rhel9-operator:1788439505 | RHSA-2026:66521 |
| multicluster engine for Kubernetes 2.11 | multicluster-engine/hypershift-addon-rhel9-operator:1780917881 | RHSA-2026:25271 |
| multicluster engine for Kubernetes 2.8 | multicluster-engine/hypershift-addon-rhel9-operator:1784738758 | RHSA-2026:47735 |
Frequently Asked Questions
Is CVE-2026-29181 in your dependencies?
O3 Security finds CVE-2026-29181 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.