Listen to this Post
The OTLP HTTP exporters in OpenTelemetry-Go versions prior to 1.43.0 are vulnerable to a memory exhaustion attack because they read the full HTTP response body into an in-memory `bytes.Buffer` without imposing any size cap.
This vulnerability is triggered on both success and error HTTP paths, specifically in the otlptracehttp, otlpmetrichttp, and `otlploghttp` client implementations. The issue is located at callsites including `client.go:199` and `client.go:230` for traces, `client.go:170` and `client.go:201` for metrics, and `client.go:190` and `client.go:221` for logs.
The vulnerable code uses io.Copy(&respData, resp.Body), which reads the entire body from the response stream into a bytes.Buffer. This operation is performed irrespective of the size of the response body and lacks any upper bound checks.
To exploit this, an attacker must be able to control the collector endpoint configuration (e.g., setting OTEL_EXPORTER_OTLP_ENDPOINT) or be in a position to perform a Man-in-the-Middle (MitM) attack on the exporter’s network connection.
When the exporter sends telemetry data, the malicious endpoint replies with an HTTP response containing an excessively large body. The client code then blindly reads and stores this entire payload in memory.
The impact is a direct denial of service (DoS) due to memory exhaustion. The attacker can force large transient heap allocations that scale with the chosen response size, ultimately leading to an Out-Of-Memory (OOM) crash of the instrumented process.
While not a remote DoS against every default deployment (as it requires an untrusted endpoint), the severity is considered High under specific threat models where the collector is attacker-controlled or the network is untrusted.
Proof-of-concept (PoC) code is available to reproduce the issue locally. Using a provided poc.zip, the command `make canonical resp_bytes=33554432 chunk_delay_ms=0` triggers the vulnerability, resulting in a peak memory allocation of ~118MB compared to ~512KB in a patched environment.
The issue was addressed by implementing a size-limited reader that caps the maximum response body size, preventing unbounded memory allocation. The fix was merged in pull request open-telemetry/opentelemetry-go8108.
Platform: Go/OpenTelemetry
Version: < 1.43.0
Vulnerability: Unbounded allocation
Severity: Medium (5.3)
date: 2026-04-08
Prediction: 2026-04-08
What Undercode Say:
Check for vulnerable versions in go.mod grep "go.opentelemetry.io/otel/exporters/otlp" go.mod Verify patched version (1.43.0 or higher) go list -m all | grep go.opentelemetry.io/otel Download PoC to test locally (if available) wget [poc.zip] && unzip poc.zip && cd poc && make canonical resp_bytes=33554432
Exploit:
An attacker sets up a malicious OpenTelemetry Collector endpoint. When the vulnerable client sends a trace, metric, or log batch, the endpoint replies with an HTTP 200 OK and a massive, garbage-filled body (e.g., 100MB+). The client’s `io.Copy` reads this entire body into a bytes.Buffer, exhausting available heap memory and crashing the application. The attack requires the ability to control the endpoint URL or intercept the HTTP traffic.
Protection from this CVE
- Upgrade: Update to `go.opentelemetry.io/otel` version 1.43.0 or higher immediately.
- Workaround: If upgrading is not possible, avoid sending telemetry to untrusted collector endpoints. Ensure that the `OTEL_EXPORTER_OTLP_ENDPOINT` points to a trusted, internal service.
- Network Security: Operate the exporter connection over a trusted network segment or use mTLS to prevent Man-in-the-Middle (MitM) attacks.
Impact
- Memory Exhaustion: Unbounded heap allocation leads to container/host OOM.
- Denial of Service: Application crashes, losing telemetry and availability.
- Operational Cost: Unpredictable memory usage spikes in production environments.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
