EUVD-2026-34288
GHSA-5wrp-cwcj-q835
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Primary rating from Vendor (https://github.com/open-telemetry/opentelemetry-go) · only source for this CVE.
CVSS VectorVendor: https://github.com/open-telemetry/opentelemetry-go
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Lifecycle Timeline
2DescriptionCVE.org
Summary
https://github.com/open-telemetry/opentelemetry-go/pull/7880 removed raw-length rejection and it causes Parse to process arbitrarily large/invalid baggage headers and log errors, enabling DoS via oversized inputs.
Details
The commit removes the upfront baggage-string length check and the per-member size guard in parsing. Parse now walks the entire input with strings.SplitSeq and skips invalid members while continuing to process the rest. For very large or malformed baggage headers, the parser still fully tokenizes and percent-decodes each member, and errors are forwarded to the global error handler (default logging). This lets a remote client send oversized/invalid headers to trigger excessive CPU/memory work and potentially large log output before any size limit is enforced, creating a denial-of-service risk in services that do not already enforce strict header size limits.
Summary:
- In
baggage/baggage.go,parseMemberperforms full parsing andPathUnescapeon the entire member without any size guard, amplifying work for large inputs.Parseno longer checks bStr length and continues processing invalid members, so oversized/invalid headers are fully parsed instead of being rejected early. - In
propagation/baggage.go, parsing errors from attacker-controlled headers are sent to the global error handler (default logging), which can amplify oversized-input impact.
PoC
Impact
The issue is reachable through standard propagation parsing (in-scope) and can be exploited remotely to cause CPU/log amplification, but the impact is availability-only and bounded by transport header limits and configurable error handling, supporting a medium severity rather than high/critical.
baggage.Parse iterates over all list members with strings.SplitSeq and skips invalid members while continuing, without a raw-length guard. parseMember performs full parsing and PathUnescape on each member, and propagation.Baggage forwards parsing errors to the global error handler, which logs by default. A remote client can therefore send oversized/invalid baggage headers that bypass the 8KB limit for valid members, causing extra CPU work and large log output, resulting in availability/log amplification in services that accept large headers and use the default handler.
Assumptions:
- An instrumented service uses the OpenTelemetry baggage propagator for inbound request parsing.
- Attackers can send oversized or malformed baggage headers that pass the hosting server/proxy header size limits.
- The default error handler is used or logs are otherwise emitted for parse errors.
- Inbound request parsing with propagation.Baggage
- Oversized/invalid baggage headers accepted by the HTTP/gRPC stack
- Error handler not suppressing parse errors
AnalysisAI
CPU and log amplification in opentelemetry-go's baggage parser allows remote unauthenticated attackers to trigger denial-of-service by submitting oversized or malformed W3C baggage headers to any instrumented Go service. PR #7880 inadvertently removed the upfront raw-length check and per-member size guard from baggage.Parse, meaning the parser now fully tokenizes and percent-decodes every member of an arbitrarily large input rather than rejecting it early. A publicly available proof-of-concept exists (GHSA-5wrp-cwcj-q835); the vulnerability is not yet listed in CISA KEV, and impact is bounded to availability with no confirmed confidentiality or integrity consequence.
Technical ContextAI
The affected packages are go.opentelemetry.io/otel/baggage and go.opentelemetry.io/otel/propagation, both part of the opentelemetry-go SDK (CPE: pkg:go/go.opentelemetry.io_otel_baggage and pkg:go/go.opentelemetry.io_otel_propagation). The root cause is CWE-789 (Uncontrolled Memory Allocation): the Parse function in baggage/baggage.go uses strings.SplitSeq to iterate over all comma-delimited baggage list-members without first enforcing a ceiling on the raw header string length. Each member is then passed to parseMember, which performs full tokenization and url.PathUnescape - a CPU-intensive operation - on potentially attacker-controlled data of unbounded size. Compounding this, propagation/baggage.go routes all parse errors from these attacker-controlled headers to the global error handler, which defaults to logging, creating a log-amplification vector alongside the CPU amplification. The W3C Baggage specification defines an 8 KB limit for valid member values, but the removed guard was the enforcement point for rejecting oversized raw strings before any work was done.
RemediationAI
Upgrade go.opentelemetry.io/otel/baggage and go.opentelemetry.io/otel/propagation to version 1.42.0 (if pinned near 1.41.0) or version 1.44.0 (if pinned near 1.43.0), as confirmed by GHSA-5wrp-cwcj-q835. Run go get go.opentelemetry.io/otel@v1.44.0 and update your go.sum accordingly. If an immediate upgrade is not feasible, enforce strict incoming header size limits at the HTTP server or reverse proxy layer (e.g., NGINX large_client_header_buffers, Envoy max_request_headers_kb, Go's http.Server.MaxHeaderBytes) - this is the most effective compensating control because it prevents oversized baggage strings from ever reaching the parser; note that setting this too low may break legitimate distributed tracing if real baggage headers are large. As a secondary mitigation, configure a custom OpenTelemetry error handler (otel.SetErrorHandler) that suppresses or rate-limits logging of parse errors, which eliminates the log-amplification vector while not addressing the CPU amplification. Advisory details are at https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-5wrp-cwcj-q835.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today