OpenTelemetry-Go’s OTLP HTTP exporters (traces, metrics, and logs) prior to version 1.43.0 can be forced to allocate unbounded memory by returning an excessively large HTTP response body. In plain terms: if an attacker controls (or can intercept) the configured OTLP collector endpoint, they can send back a huge response and cause the instrumented application to run out of memory (OOM) and potentially crash.
The affected components are the OTLP HTTP exporter clients for traces/metrics/logs:
- exporters/otlp/otlptrace/otlptracehttp/client.go
- exporters/otlp/otlpmetric/otlpmetrichttp/client.go
- exporters/otlp/otlplog/otlploghttp/client.go
Technical details — root cause, attack vector, exploitation mechanism
The root cause is an unbounded read of the HTTP response body into an in-memory buffer. The security advisory states that the exporters read the full resp.Body into a bytes.Buffer without any size cap.
Specifically, the pinned callsite shows the code pattern:
- io.Copy(&respData, resp.Body)
This occurs in the exporter HTTP client implementations on both success and error paths (as described in the advisory). Because respData is a bytes.Buffer (or buffer-backed variable) and io.Copy continues until EOF, a malicious collector (or a network attacker performing MITM) can return an attacker-chosen large response body. The exporter will then allocate memory proportional to the response size, creating a transient heap spike.
The attack vector is adjacent network (CVSS AV:A), with no user interaction or privileges required (PR:N, UI:N). Exploitation does not require authentication in the described scenario; it relies on the attacker being able to control the collector endpoint or intercept traffic between the exporter and collector.
Impact — what an attacker can achieve, blast radius, and real-world risk
An attacker can trigger memory exhaustion by forcing the OTLP HTTP exporter to buffer an arbitrarily large HTTP response body. The advisory notes that this can lead to:
- Large transient heap allocations during export (peak memory scales with attacker-chosen response size)
- Potential process crash via OOM
The CVSS score is 5.3 (Medium) with vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. Availability impact is high (A:H), while confidentiality and integrity are not impacted (C:N, I:N). The advisory also clarifies that it is not claiming a remote DoS against every default deployment; rather, it applies when the exporter sends data to an untrusted collector endpoint or where MITM is realistic.
Mitigation — patched versions, workarounds, detection guidance
Patch: Upgrade OpenTelemetry-Go to version 1.43.0 or later. The NVD description and the referenced GitHub security advisory both state that the issue is fixed in 1.43.0.
Workarounds / risk reduction (based on the advisory’s conditions):
- Ensure the OTLP HTTP collector endpoint is trusted and not attacker-controlled.
- Prevent or reduce the feasibility of network MITM between the exporter and collector (e.g., use appropriate network segmentation and transport security practices consistent with your deployment).
Detection guidance (practical):
- Monitor exporter/collector communications for unusually large HTTP responses from the collector endpoint, especially during export operations.
- Watch for memory spikes and OOM events in services using OpenTelemetry-Go OTLP HTTP exporters, correlating them with collector responses.
poc_available: The provided references describe the vulnerable code path and the conditions for exploitation (unbounded io.Copy into a buffer) but do not include a PoC/exploit write-up or weaponizable technique. Therefore, poc_available is set to false.
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-789