Public mode

No access to your tenant or devices. Every item links to its source. What this means

Sources need attention Customize Public modeDiscuss ChangeIntel on Discord

opentelemetry-go · Vulnerability

CVSS 3.1 7.5 HIGHEUVD CVSS 3.1 7.5 CVSS 3.1 · [email protected] · Secondary 7.5 HIGHCVSS 3.1 · 0b0ca135-0b70-47e7-9f44-1890c2a1c46c · Secondary 7.5 HIGHCVSS_V3 Publisher rating HIGHFixed by go.opentelemetry.io/otel 1.41.0osv · severity unknownFixed by go.opentelemetry.io/otel 1.41.0KEV status unknown

cve-program · CVE-2026-29181

Published

OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, 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. This vulnerability is fixed in 1.41.0.

Read the publisher's advisory

euvd · EUVD-2026-19938

Published

OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, 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. This vulnerability is fixed in 1.41.0.

Read the publisher's advisory

nvd · CVE-2026-29181

Published

OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, 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. This vulnerability is fixed in 1.41.0.

Read the publisher's advisory

osv · GHSA-mh2q-q3fh-2475

Published

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=10315458` and `p95_ms=7` - control: `per_req_alloc_bytes=133429` and `p95_ms=0` ## proof of concept canonical: ```bash 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: ```bash 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. [poc.zip](https://github.com/user-attachments/files/25079945/poc.zip) [PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079946/PR_DESCRIPTION.md)

Read the publisher's advisory

osv · GO-2026-5506

Published

OpenTelemetry-Go: Multi-value baggage header extraction causes excessive allocations in go.opentelemetry.io/otel

Read the publisher's advisory

Affected versions, risk and source history

Related advisories and sources

Publishers link these advisories through the identifiers shown below. A shared identifier or date alone does not tell you whether your software is affected or whether the advisories describe the same cause.

CVE-2026-29181 · CVE overview and exploitation status

EUVD-2026-19938

GHSA-mh2q-q3fh-2475

GO-2026-5506

cve-program · CVE-2026-29181

euvd · EUVD-2026-19938

nvd · CVE-2026-29181

osv · GHSA-mh2q-q3fh-2475

osv · GO-2026-5506

Related changes

Linked by CVE identifier

No related changes are available here.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 13 Nov 09:00 UTC · 274 of 275 readable · 272 fully read · documentation 469/469 current