CVE-2026-39882: Memory Exhaustion Denial of Service in OpenTelemetry-Go OTLP HTTP Exporters

OpenTelemetry-Go provides instrumentation libraries to export traces, metrics, and logs via the OpenTelemetry Protocol (OTLP). The HTTP exporters within this library facilitate data transmission to telemetry collectors over HTTP. Prior to version 1.43.0, these exporters contained a memory allocation vulnerability tracked as CVE-2026-39882.

This vulnerability is classified as CWE-789, indicating memory allocation with an excessive size value. The core issue resides in the handling of HTTP responses received from the configured OTLP collector. The application blindly buffers the entire response body into memory without enforcing any size constraints.

An attacker positioned to control the collector endpoint or intercept the network traffic can exploit this behavior. By supplying an infinitely large or excessively large HTTP response body, the attacker forces the instrumented Go application to allocate memory until it crashes. This results in a Denial of Service (DoS) condition for the host application.

The root cause of CVE-2026-39882 lies in the unbounded read operations implemented within the OTLP HTTP client code. The exporters utilize Go's standard library functions to process HTTP responses received from the collector. Specifically, the vulnerable implementations relied on functions like io.Copy or similar methods to transfer data from resp.Body into a bytes.Buffer.

In Go, the bytes.Buffer dynamically grows its underlying byte slice to accommodate incoming data. When fed an unbounded stream via io.Copy, the buffer will continually request larger memory allocations from the Go runtime. This process persists until the memory limits of the host environment or container are exceeded.

The affected callsites exist identically across the three main telemetry signal exporters. Vulnerable code patterns were identified in exporters/otlp/otlptrace/otlptracehttp/client.go at lines 199 and 230, as well as the corresponding files for metrics (otlpmetrichttp/client.go) and logs (otlploghttp/client.go). These common implementations shared the exact same flawed response parsing logic.

The vulnerable implementation reads the response body directly into a buffer structure without any validation of the Content-Length header or limits on the input stream. The runtime automatically allocates heap memory to match the size of the incoming HTTP response body, creating a direct path to memory exhaustion.

// Vulnerable Implementation Pattern
var respData bytes.Buffer
_, err := io.Copy(&respData, resp.Body)
if err != nil {
    return err
}

The primary fix introduced in Pull Request #8108 implements the io.LimitReader function from the Go standard library. This wrapper intercepts the Read calls and enforces a hard upper bound on the number of bytes that can be consumed from the underlying io.Reader. The OpenTelemetry maintainers implemented a response cap, typically 1MB, preventing uncontrolled memory growth.

// Patched Implementation Pattern
var respData bytes.Buffer
// Limit response body reading to prevent OOM
limitReader := io.LimitReader(resp.Body, 1024*1024)
_, err := io.Copy(&respData, limitReader)
if err != nil {
    return err
}

A secondary defense-in-depth mitigation was implemented in commit 248da958375e4dfb4a1105645107be3ef04b1c59. This commit introduced explicit Enabled(ctx) checks within internal instrumentation routines. By verifying the instrumentation state before executing computationally heavy work or secondary allocations, the library further hardens the execution path against resource exhaustion during high-load scenarios.

Exploitation of this vulnerability requires the attacker to manipulate the HTTP response returning from the OTLP collector to the instrumented application. The attacker achieves this either by compromising the configured collector endpoint or by performing a Man-in-the-Middle (MITM) attack. The MITM scenario typically requires adjacent network access, such as ARP spoofing or DNS poisoning within the same subnet.

Once the attacker intercepts the telemetry export request, they hold the HTTP connection open and stream an infinite sequence of bytes back to the client. The attacker does not need to send valid OTLP protocol data. The OpenTelemetry HTTP client attempts to buffer the entire payload before parsing, triggering the out-of-memory condition strictly during the io.Copy operation.

Proof-of-Concept testing documented in the OSV database demonstrates the efficiency of this attack. Using a test payload of 33,554,432 bytes via the reproduction command make canonical resp_bytes=33554432 chunk_delay_ms=0, unpatched clients experienced peak allocations of 118,050,512 bytes. Patched clients executing the same test registered a peak allocation of only 512,232 bytes.

The primary impact of this vulnerability is a high-availability loss for the instrumented application. Because OpenTelemetry is embedded directly into the target service, an out-of-memory condition crashes the entire application process, not just the telemetry exporter. In microservice architectures, this can lead to cascading failures if the affected service is a critical dependency.

The vulnerability carries a CVSS v3.1 score of 5.3 (Medium), characterized by the vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. The Attack Vector (AV) is classified as Adjacent Network because intercepting the traffic often requires local network presence. The Attack Complexity (AC) is High due to the requirement of MITM positioning or compromising the downstream telemetry infrastructure.

Despite the high impact on availability, the real-world likelihood of exploitation remains extremely low. The EPSS score is calculated at 0.00016, placing it in the 3.42nd percentile. There is no evidence of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

The definitive remediation for CVE-2026-39882 is upgrading the go.opentelemetry.io/otel libraries to version 1.43.0 or later. This release contains the io.LimitReader implementation that enforces strict boundaries on memory allocation during HTTP response processing. Developers must ensure all OTLP HTTP exporter modules (traces, metrics, and logs) are updated concurrently.

If immediate patching is not feasible, organizations must secure the network path between the instrumented application and the collector. Implementing Mutual TLS (mTLS) with strict certificate validation prevents MITM attacks by ensuring the application only accepts responses from an authenticated and authorized collector endpoint. This configuration effectively neutralizes the adjacent network attack vector.

Administrators should also enforce strict memory limits at the container or process level using cgroups or Kubernetes memory constraints. While setting a hard memory limit will not prevent the instrumented process from crashing when the limit is reached, it protects the underlying host node from complete resource exhaustion, thereby containing the blast radius of the attack.