CVE-2026-39882: 
cAdvisor vulnerability analysis and mitigation

CVE-2026-39882 is a memory exhaustion vulnerability in OpenTelemetry-Go's OTLP HTTP exporters, where the traces, metrics, and logs exporters read the full HTTP response body into an in-memory bytes.Buffer without any size cap. This flaw is exploitable when the configured collector endpoint is attacker-controlled or when a network attacker can perform a man-in-the-middle (MitM) attack on the exporter connection. Affected packages include go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp and otlpmetrichttp prior to v1.43.0, and otlploghttp prior to v0.19.0. The vulnerability was disclosed on April 8, 2026, and carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value): each OTLP HTTP exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error code paths, with no upper bound on the amount of data read (GitHub Advisory). The vulnerable call sites are in otlptracehttp/client.go (lines 199, 230), otlpmetrichttp/client.go (lines 170, 201), and otlploghttp/client.go (lines 190, 221). Exploitation requires either control of the collector endpoint or the ability to intercept the network path between the exporter and the collector (adjacent network, high attack complexity). A proof-of-concept was included in the original security report, demonstrating that a 32 MiB response body causes peak heap allocations exceeding 118 MB, compared to ~512 KB with the patched version (GitHub PR #8108).

Successful exploitation causes memory exhaustion (out-of-memory conditions) in any Go application using the affected OTLP HTTP exporters for traces, metrics, or logs, potentially crashing the instrumented process. There is no confidentiality or integrity impact — the vulnerability is purely an availability (denial of service) issue. The scope is limited to the affected application process; lateral movement is not a direct consequence, but crashing an observability-instrumented service could impair incident detection and response capabilities (GitHub Advisory).

There is no public proof-of-concept exploit code available beyond the private PoC submitted with the original vulnerability report, and there is no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.016% (0.000160), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires network adjacency and high attack complexity, limiting the practical attacker pool to those who can control or intercept the collector endpoint.

1. Identify target: Locate a Go application using OpenTelemetry-Go OTLP HTTP exporters (versions prior to v1.43.0 for traces/metrics, v0.19.0 for logs) that sends telemetry to a collector endpoint accessible from an adjacent network segment.
2. Gain network position: Either compromise or impersonate the configured OTLP collector endpoint (e.g., via ARP spoofing, DNS poisoning, or BGP hijacking on the adjacent network), or deploy a rogue collector at the configured address.
3. Serve oversized HTTP response: When the vulnerable exporter sends an HTTP POST request (e.g., to /v1/traces, /v1/metrics, or /v1/logs), respond with an HTTP 200 or error response containing an arbitrarily large body (e.g., hundreds of megabytes or gigabytes of data).
4. Trigger memory exhaustion: The exporter's io.Copy(&respData, resp.Body) call reads the entire response into memory without limit, causing the instrumented process's heap to grow until the OS kills it with an out-of-memory error, achieving denial of service (GitHub Advisory, GitHub PR #8108).

• Process: Sudden spike in memory consumption of Go application processes using OpenTelemetry exporters, potentially followed by OOM kills (visible in system logs as Out of memory: Kill process).
• Logs: Application crash logs or Go runtime panic messages related to memory allocation failures; repeated export errors or non-retryable error responses from the collector endpoint.
• Network: Unusually large HTTP responses (megabytes to gigabytes) from the OTLP collector endpoint on ports 4318 (default OTLP HTTP) in network traffic captures; unexpected source IPs responding to OTLP export requests.
• System: Kernel OOM killer events in /var/log/syslog or dmesg targeting the instrumented Go process; abnormal memory usage trends visible in monitoring dashboards for services using OpenTelemetry.

Upgrade to OpenTelemetry-Go v1.43.0 (for otlptracehttp and otlpmetrichttp) or v0.19.0 (for otlploghttp), which limits HTTP response body reads to 4 MiB; responses exceeding this limit are treated as non-retryable errors (GitHub Release v1.43.0, GitHub PR #8108). As a workaround prior to patching, ensure OTLP collector endpoints are only reachable from trusted network segments and implement network segmentation to prevent untrusted parties from intercepting or impersonating the collector. IBM has also released patches for affected products including watsonx.data and IBM Verify Identity Access OIDC Provider (IBM watsonx Advisory, IBM Verify Advisory).

The vulnerability was reported by security researcher "1seal" and remediated by OpenTelemetry-Go maintainer pellared, with the fix reviewed and approved by core maintainers dmathieu and XSAM (GitHub PR #8108). The reporter confirmed the fix was correct, noting that "response-body reads for diagnostics are now bounded instead of copied unbounded into memory." The issue has been picked up by downstream consumers including Portainer, CircleCI, Grafana Mimir, and AWS Amazon Linux, all of which have released updates incorporating the patched OpenTelemetry-Go version.