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: perreqallocbytes=10315458 and p95ms=7 - control: perreqallocbytes=133429 and p95ms=0

proof of concept

canonical:

bash mkdir -p poc unzip poc.zip -d poc cd poc make test

output (excerpt):

[CALLSITEHIT]: propagation/baggage.go:58 extractMultiBaggage [PROOFMARKER]: baggagemultivalueamplification p95ms=7 perreqallocbytes=10315458 perreqallocs=16165

control:

bash cd poc make control

control output (excerpt):

[NCMARKER]: baggagesinglevaluebaseline p95ms=0 perreqallocbytes=133429 perreqallocs=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 perreqallocbytes and perreqallocs, and p95ms stays below 2ms.

poc.zip PRDESCRIPTION.md

Summary

This handler wrapper https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65 out of the box adds labels

- http.useragent - http.method

that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it.

Details

HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses httpconv.ServerRequest that records every value for HTTP method and User-Agent.

PoC

Send many requests with long randomly generated HTTP methods or/and User agents (e.g. a million) and observe how memory consumption increases during it.

Impact

In order to be affected, the program has to configure a metrics pipeline, use otelhttp.NewHandler wrapper, and does not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc.

Others

It is similar to already reported vulnerabilities - https://github.com/open-telemetry/opentelemetry-go-contrib/security/advisories/GHSA-5r5m-65gx-7vrh (open-telemetry/opentelemetry-go-contrib) - https://github.com/advisories/GHSA-cg3q-j54f-5p7p (prometheus/clientgolang)

Workaround for affected versions

As a workaround to stop being affected otelhttp.WithFilter() can be used, but it requires manual careful configuration to not log certain requests entirely.

For convenience and safe usage of this library, it should by default mark with the label unknown non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.

The other possibility is to disable HTTP metrics instrumentation by passing otelhttp.WithMeterProvider option with noop.NewMeterProvider.

Solution provided by upgrading

In PR https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277, released with package version 0.44.0, the values collected for attribute http.request.method were changed to be restricted to a set of well-known values and other high cardinality attributes were removed.

References

- https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277 - https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v1.19.0

Summary

The grpc Unary Server Interceptor opentelemetry-go-contrib/instrumentation/google.golang.org/grpc/otelgrpc/interceptor.go

// UnaryServerInterceptor returns a grpc.UnaryServerInterceptor suitable // for use in a grpc.NewServer call. func UnaryServerInterceptor(opts ...Option) grpc.UnaryServerInterceptor { out of the box adds labels

- net.peer.sock.addr - net.peer.sock.port

that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent.

Details

An attacker can easily flood the peer address and port for requests.

PoC

Apply the attached patch to the example and run the client multiple times. Observe how each request will create a unique histogram and how the memory consumption increases during it. Impact

In order to be affected, the program has to configure a metrics pipeline, use UnaryServerInterceptor, and does not filter any client IP address and ports via middleware or proxies, etc.

Others

It is similar to already reported vulnerabilities.

GHSA-rcjv-mgp8-qvmr (open-telemetry/opentelemetry-go-contrib) - GHSA-5r5m-65gx-7vrh (open-telemetry/opentelemetry-go-contrib) - GHSA-cg3q-j54f-5p7p (prometheus/clientgolang)

Workaround for affected versions

As a workaround to stop being affected, a view removing the attributes can be used.

The other possibility is to disable grpc metrics instrumentation by passing otelgrpc.WithMeterProvider option with noop.NewMeterProvider.

Solution provided by upgrading

In PR #4322, to be released with v0.46.0, the attributes were removed.

References

- #4322

Summary

The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/hostid.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/hostidexec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.

Affected platforms (per build tag in hostidbsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.

The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack

1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk 2. Attacker places a malicious kenv binary earlier in $PATH 3. Application initializes OpenTelemetry resource detection at startup 4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary 5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.

Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/hostid.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application.

Patches This has been patched in d45961b, which was released with v1.40.0.

References - CWE-426: Untrusted Search Path

OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to 1.43.0, the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap. This is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection). This vulnerability is fixed in 1.43.0.

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, parseMember performs full parsing and PathUnescape on the entire member without any size guard, amplifying work for large inputs. Parse no 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

baggagedospoc.tar.gz

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