CVE-2026-39882
Awaiting Analysis Awaiting Analysis - Queue
Unbounded Memory Consumption in OpenTelemetry-Go OTLP HTTP Exporters

Publication date: 2026-04-08

Last updated on: 2026-04-09

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-08
Last Modified
2026-04-09
Generated
2026-05-07
AI Q&A
2026-04-09
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
opentelemetry opentelemetry to 1.43.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-789 The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

This vulnerability exists in OpenTelemetry-Go versions prior to 1.43.0, specifically in the otlp HTTP exporters for traces, metrics, and logs. These exporters read the entire HTTP response body into an in-memory buffer without limiting its size. If an attacker controls the collector endpoint or can intercept the connection, they can exploit this behavior to cause memory exhaustion on the system running the exporter.


How can this vulnerability impact me? :

The vulnerability can lead to memory exhaustion on the affected system, potentially causing the application or system to crash or become unresponsive. This can result in denial of service, disrupting the normal operation of services relying on OpenTelemetry-Go for telemetry data export.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, upgrade OpenTelemetry-Go to version 1.43.0 or later, where the issue has been fixed.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by identifying if your system is running vulnerable versions of the OpenTelemetry Go OTLP HTTP exporters (otlptracehttp, otlpmetrichttp, otlploghttp) prior to versions v1.43.0 (for otlptracehttp and otlpmetrichttp) and v0.19.0 (for otlploghttp).

To detect the presence of vulnerable OpenTelemetry Go SDK versions on your system, you can check the version of the OpenTelemetry Go packages used in your application or binaries.

  • If you have access to the source code or dependencies, run commands like `go list -m all | grep opentelemetry` to identify the version of OpenTelemetry Go modules.
  • If you have the binary or container image, inspect the included OpenTelemetry Go SDK version via build metadata or by checking the vendor directory or module files.

Network detection of exploitation attempts could involve monitoring for unusually large HTTP response bodies from the configured OTLP collector endpoints, especially responses exceeding 4 MiB, which is the limit introduced in the patched versions.

  • Use network monitoring tools (e.g., tcpdump, Wireshark) to capture HTTP traffic to the OTLP collector endpoints and analyze response sizes.
  • Example tcpdump command to capture HTTP traffic on port 4318 (default OTLP HTTP port): `tcpdump -i any port 4318 -w otlp_traffic.pcap`
  • Analyze the captured traffic with Wireshark or similar tools to identify HTTP responses with large Content-Length headers or chunked transfer encoding with large total size.

Currently, there are no specific built-in commands or tools mentioned in the provided resources that directly detect this vulnerability automatically.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart