CVE-2026-41173: Denial of Service in OpenTelemetry .NET SDK via Unbounded HTTP Allocation

OpenTelemetry is a widespread observability framework used for telemetry data collection and export. The .NET SDK provides specific instrumentation packages for AWS environments, including X-Ray distributed tracing and metadata collection for EC2, ECS, and EKS. These components periodically query external HTTP endpoints to fetch sampling rules and instance metadata.

CVE-2026-41173 identifies a critical Denial of Service (DoS) flaw within these fetching mechanisms. The vulnerability is formally classified under CWE-770: Allocation of Resources Without Limits or Throttling. It specifically affects the OpenTelemetry.Sampler.AWS and OpenTelemetry.Resources.AWS dependency packages.

The core issue resides in the unconstrained reading of HTTP responses into managed memory. Applications utilizing these packages are susceptible to application crashes resulting in total process termination. The security impact is strictly limited to availability, as no sensitive data is exposed or modified.

The vulnerability originates in the data ingestion logic of the AWS X-Ray Sampler and the various AWS Resource Detectors. These components utilize the standard .NET HttpClient to communicate with underlying AWS services. The flaw specifically involves the insecure invocation of HttpClient.ReadAsStringAsync() and HttpClient.GetStringAsync() methods to process HTTP responses.

By default, the .NET HttpClient implementation buffers the entire HTTP response body in memory before returning control to the caller. The affected OpenTelemetry components invoked these methods without validating the Content-Length header or enforcing a maximum payload size limit. Consequently, the SDK attempts to materialize the complete response into a single contiguous managed string.

When processing an exceptionally large response, the .NET runtime must allocate corresponding memory on the managed heap. Strings exceeding 85,000 bytes are placed on the Large Object Heap (LOH). The LOH is generally not compacted during standard Garbage Collection (GC) cycles, leading to rapid heap fragmentation and aggressive memory pressure.

An attacker supplying a multi-gigabyte payload forces the application to consume all available physical memory. The .NET runtime subsequently triggers continuous Garbage Collection attempts in a failing effort to reclaim space. This GC thrashing halts execution threads, ultimately culminating in an OutOfMemoryException and an immediate process crash.

The vulnerable implementation relied entirely on the default buffering behavior of the .NET HttpClient. The code issued a request and blindly awaited the full string materialization. This approach delegates all memory management to the underlying framework without defining strict boundary conditions.

// Vulnerable implementation concept
var response = await httpClient.GetAsync(endpointUrl);
response.EnsureSuccessStatusCode();
 
// VULNERABILITY: Buffers entire payload into memory regardless of size
var responseBody = await response.Content.ReadAsStringAsync();
var rules = JsonSerializer.Deserialize<SamplingRules>(responseBody);

The patched implementation introduces a bounded reading mechanism and alters the HttpClient execution model. The HttpCompletionOption.ResponseHeadersRead parameter is utilized to instruct the client to return immediately after receiving the HTTP response headers. This explicitly prevents the framework from automatically buffering the response body.

// Patched implementation concept
using var response = await httpClient.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, cancellationToken);
response.EnsureSuccessStatusCode();
 
using var stream = await response.Content.ReadAsStreamAsync();
 
// Bounded reader enforces a strict 1MB maximum allocation limit
var responseBody = await ReadStreamWithLimitAsync(stream, 1024 * 1024);
var rules = JsonSerializer.Deserialize<SamplingRules>(responseBody);

The ReadStreamWithLimitAsync logic reads the incoming stream in smaller chunks. If the cumulative byte count exceeds the predefined 1MB threshold, the process aborts the read operation and closes the TCP connection. This bounded stream reader ensures deterministic memory consumption regardless of the server's response size.

Exploitation requires the attacker to manipulate the HTTP response received by the OpenTelemetry SDK. The attacker must possess either the ability to intercept network traffic via a Man-in-the-Middle attack or the authorization to reconfigure the endpoint URLs utilized by the SDK.

In a network interception scenario, the attacker targets the unencrypted HTTP traffic between the host application and the local AWS X-Ray daemon (typically accessible at http://localhost:2000) or the AWS Instance Metadata Service (IMDS at http://169.254.169.254). The attacker intercepts the outbound request and supplies a crafted response.

Alternatively, an attacker with access to the host environment configuration can manipulate environment variables such as ECS_CONTAINER_METADATA_URI. By redirecting the SDK to an attacker-controlled external server, the attacker establishes a direct channel to deliver the malicious payload without requiring network interception capabilities.

Upon receiving the SDK request, the malicious server responds with a continuous stream of arbitrary data. The server intentionally keeps the TCP connection open and omits the Content-Length header. The vulnerable application consumes the stream synchronously until the host system memory is entirely exhausted.

The primary security impact is a complete Denial of Service affecting the process utilizing the OpenTelemetry SDK. A successful exploit unconditionally triggers an OutOfMemoryException, which crashes the host .NET application and terminates all current operations.

The CVSS v3.1 score is calculated as 5.9 (Medium). The base vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflects the network-based attack vector and the high severity of the availability loss. Confidentiality and integrity metrics are scored as None, as the vulnerability does not expose sensitive memory or permit arbitrary code execution.

The Attack Complexity is evaluated as High. Exploitation is not trivial, requiring specific network positioning or local environment control to spoof the AWS service endpoints. The vulnerability cannot be triggered simply by sending an external unauthenticated packet to a public-facing application port.

The operational impact depends heavily on the deployment architecture. In orchestrated environments like Kubernetes, the crashed container will be restarted automatically. However, continuous exploitation by an attacker will result in an ongoing crash-loop, severely degrading or entirely halting the service's availability over time.

The definitive remediation is to apply the software updates provided by the OpenTelemetry maintainers. Organizations must upgrade OpenTelemetry.Sampler.AWS to version 0.1.0-alpha.8 or later, and OpenTelemetry.Resources.AWS to version 1.15.1 or later.

These updates introduce the bounded stream reading mechanism, completely neutralizing the vulnerability. The patch ensures that rogue endpoints cannot force the SDK to allocate more than 1MB of memory during metadata or sampling rule fetching operations. This strict limit isolates the SDK from malicious response structures.

In environments where immediate patching is not feasible, administrators should enforce strict process-level memory limits. Utilizing cgroups or container orchestration constraints (e.g., Kubernetes resources.limits.memory) caps the maximum memory the application can consume. While the process will still crash upon exploitation, the memory limit prevents the DoS attack from starving and destabilizing the underlying host operating system.

Administrators should additionally secure network channels to local agents. Ensuring that communications with the X-Ray daemon utilize HTTPS, or implementing strict local firewall rules, removes the local Man-in-the-Middle attack vector. Securing runtime environment configurations prevents unauthorized redirection of the SDK endpoints to external servers.