CVE-2026-40182: Unbounded Memory Exhaustion Denial of Service in OpenTelemetry .NET OTLP Exporter

The opentelemetry-dotnet framework provides standard mechanisms for generating, collecting, and exporting telemetry data from .NET applications. The OpenTelemetry.Exporter.OpenTelemetryProtocol library specifically handles the transmission of metrics, traces, and logs to a centralized backend using the OpenTelemetry Protocol (OTLP). This component operates continuously within the host application process, executing periodic background tasks to transmit buffered telemetry data over gRPC or HTTP transport layers.

In framework versions 1.13.1 through 1.15.1, the OTLP exporter contains an uncontrolled resource consumption vulnerability documented as CVE-2026-40182. The flaw resides in the error-handling routines triggered when the telemetry collector rejects an export request. Instead of bounding the read operation or securely discarding the failure response, the application attempts to read the entire payload into memory to generate internal diagnostic logs.

This behavior exposes the instrumented application to a Denial of Service (DoS) attack. An attacker with control over the backend endpoint, or the ability to intercept adjacent network traffic, can supply anomalous HTTP responses engineered to exploit this unconstrained memory allocation. The resulting memory exhaustion compromises the host application's stability and leads to an unrecoverable process termination.

The vulnerability originates from a diagnostic enhancement introduced in pull request #6564. The modification aimed to capture detailed error messages from backend services when telemetry exports fail, improving visibility into configuration and connectivity issues. When the OTLP exporter receives an HTTP 4xx or 5xx status code, the internal event source listener attempts to read the response stream to extract and emit these diagnostic details.

The core technical defect is the use of unbounded stream reading operations. The implementations within the OtlpExportClient and its transport variants rely on standard library methods such as StreamReader.ReadToEnd() and HttpContent.ReadAsStringAsync(). These methods are fundamentally unsafe for processing untrusted external inputs because they do not enforce a maximum byte threshold during stream consumption.

When a network peer continuously transmits data, the .NET runtime dynamically resizes its internal managed buffers to accommodate the incoming stream. In the context of the .NET memory model, strings or byte arrays exceeding 85,000 bytes are allocated directly on the Large Object Heap (LOH). Continuous allocation on the LOH quickly fragments memory and exhausts the application's committed virtual memory limits. The runtime eventually fails to allocate the requested contiguous block, throwing a fatal System.OutOfMemoryException.

An analysis of the vulnerable implementation confirms a direct pipeline from the network socket to an unconstrained managed string allocation. The exporter logic does not validate the Content-Length header against a maximum permitted value, nor does it implement a byte counter during active stream ingestion. The entire response body is processed synchronously or asynchronously as a single, contiguous allocation operation.

The remediation implemented in pull request #7017 permanently alters this data ingestion pattern. The developers introduced a strict 4-mebibyte (4MiB) hard limit via the MessageSizeLimit constant. Furthermore, the payload extraction logic is now conditionally gated behind a boolean check verifying that internal SDK logging is actively listening via OpenTelemetryProtocolExporterEventSource.Log.IsEnabled.

The patched implementation replaces the unbounded stream methods with a controlled, segmented read loop. The revised code allocates a temporary buffer utilizing ArrayPool<byte>.Shared.Rent(length), ensuring memory is handled efficiently without unnecessary heap allocations. If the incoming stream exceeds the 4MiB threshold, the read loop terminates early, formats the truncated buffer, and appends a [TRUNCATED] suffix to the diagnostic output.

// Patched implementation excerpt
const int MessageSizeLimit = 4 * 1024 * 1024; // 4MiB
var length = GetBufferLength(stream, MessageSizeLimit);
 
#if NET
var buffer = ArrayPool<byte>.Shared.Rent(length);
#else
var buffer = new byte[length];
#endif
 
// The read loop enforces the MessageSizeLimit boundary
result = encoding.GetString(buffer, 0, count);
if (result.Length == MessageSizeLimit) { result += "[TRUNCATED]"; }

Exploitation of CVE-2026-40182 requires an attacker to control the network communication between the vulnerable application and its configured telemetry collector. This control is typically achieved by compromising the backend collector infrastructure or by establishing a Man-in-the-Middle (MitM) position on the adjacent network. The exploit execution does not require prior authentication or elevated privileges within the target application itself.

The attack sequence begins when the target application attempts a routine telemetry export over the OTLP protocol. The malicious or intercepted backend receives the valid request but intentionally replies with an HTTP failure code, such as 500 Internal Server Error. The vulnerable .NET client recognizes the non-success status code and triggers the diagnostic logging mechanism to inspect the response body.

At this stage, the attacker's server initiates an unbounded data stream. The server utilizes chunked transfer encoding or simply omits the Content-Length header, streaming an infinite sequence of null bytes or arbitrary character data. The vulnerable client invokes ReadToEnd(), blocking the execution thread while the runtime continuously allocates memory. The application rapidly consumes all available system RAM until the process is forcefully terminated by the operating system or the .NET garbage collector.

The concrete security impact of this vulnerability is a high-severity disruption of service availability. The unhandled OutOfMemoryException propagates through the application, causing the entire .NET process to terminate abruptly. Because the telemetry exporter operates as an integrated background service within the primary host application, a failure in the exporter directly results in a complete outage of the core business logic.

The Common Vulnerability Scoring System (CVSS) v3.1 calculation yields a vector of 5.3 (Medium). This score accounts for the localized Attack Vector (Adjacent Network) and the High Attack Complexity associated with intercepting network traffic or compromising backend infrastructure. While the overall score is constrained by these prerequisites, the Availability metric is evaluated as High, confirming that successful exploitation reliably causes total process termination.

This vulnerability poses an acute risk in modern microservice and containerized environments. Container orchestration platforms like Kubernetes typically respond to OOM terminations by automatically restarting the failed pod. A persistent attacker can repeatedly serve malicious payloads to these restarting instances, trapping the deployment in a continuous crash loop. This condition entirely prevents the application from servicing legitimate traffic and degrades the operational capacity of the broader system.

The primary remediation strategy requires engineering teams to update the OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package to version 1.15.2 or later. This release integrates the memory-safe buffering mechanism and enforces the strict 4MiB constraint on all diagnostic payload ingestion. Security personnel should audit dependency manifests across all .NET projects to identify and upgrade any instances of the vulnerable version range.

In operational environments where immediate dependency updates are restricted, a reliable configuration workaround is available. The vulnerable code execution path only activates when the internal OpenTelemetry SDK logging mechanism attempts to emit a diagnostic event. Administrators can prevent the application from reading the malicious response body by verifying that OpenTelemetryProtocolExporterEventSource.Log.IsEnabled evaluates to false.

Development teams must ensure that no internal diagnostic listeners or EventSource subscribers are attached to the OpenTelemetry provider in production deployments. Disabling these internal SDK logs thoroughly neutralizes the attack vector. When the logs are inactive, the application correctly discards the HTTP failure payload without attempting to buffer the stream into managed memory.