CVE-2026-41173: AWS X-Ray Remote Sampler DoS Vulnerability

CVE-2026-41173 Overview

CVE-2026-41173 is a Resource Exhaustion vulnerability affecting the AWS X-Ray Remote Sampler package for OpenTelemetry .NET. The vulnerability exists in the AWSXRaySamplerClient.DoRequestAsync method, which reads HTTP response bodies from the AWS X-Ray remote sampling endpoint without enforcing any size limits. An attacker who can control or intercept traffic to the configured sampling endpoint can send arbitrarily large responses, causing unbounded heap allocation that leads to memory exhaustion, garbage-collection stalls, or process termination via OutOfMemoryException.

Critical Impact

Attackers with network position to intercept or control the sampling endpoint can cause denial of service through memory exhaustion, potentially crashing applications that rely on OpenTelemetry AWS X-Ray integration.

Affected Products

• OpenTelemetry.Sampler.AWS versions prior to 0.1.0-alpha.8
• Applications using AWSXRayRemoteSamplerBuilder with configurable endpoints
• Systems with default configuration targeting http://localhost:2000

Discovery Timeline

• 2026-04-23 - CVE CVE-2026-41173 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-41173

Vulnerability Analysis

This vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from how the AWS X-Ray Remote Sampler handles HTTP responses when fetching sampling configurations. The AWSXRaySamplerClient.DoRequestAsync method chains HttpClient.SendAsync with ReadAsStringAsync(), which materializes the entire HTTP response body into a single in-memory string without any bounds checking.

The attack requires network-level access to either control the configured sampling endpoint or perform a Man-in-the-Middle (MitM) attack against traffic destined to that endpoint. While the default endpoint is http://localhost:2000, organizations may configure external endpoints, expanding the attack surface.

Root Cause

The root cause is the absence of input validation on the HTTP response body size in the AWSXRaySamplerClient.DoRequestAsync implementation. When calling ReadAsStringAsync(), the method trusts that the remote endpoint will return reasonably-sized responses. This violates the principle of never trusting external input, regardless of the source.

The AWSXRayRemoteSamplerBuilder.SetEndpoint() method allows configuration of custom endpoints, meaning the attack surface extends beyond localhost to any network-accessible endpoint configured by the application.

Attack Vector

The vulnerability can be exploited via network-based attacks. An attacker must either compromise the configured sampling endpoint or position themselves to intercept traffic through techniques such as ARP spoofing, DNS poisoning, or BGP hijacking.

Once positioned, the attacker responds to sampling configuration requests with an arbitrarily large payload. Since the consuming application has no size limits, it attempts to allocate memory for the entire response, leading to heap exhaustion.

The attack is particularly effective because:

• Sampling requests occur periodically as part of normal operation
• The endpoint uses HTTP by default, making MitM attacks feasible
• Memory allocation occurs synchronously, blocking application threads during the attack

For technical details on the vulnerability mechanism, refer to the GitHub Security Advisory GHSA-28xm-prxc-5866.

Detection Methods for CVE-2026-41173

Indicators of Compromise

• Unusually large HTTP responses from the X-Ray sampling endpoint exceeding typical configuration payload sizes
• Memory usage spikes in applications using OpenTelemetry AWS X-Ray integration
• OutOfMemoryException errors in application logs coinciding with sampling requests
• Garbage collection pressure indicators such as increased GC pause times or frequent Gen 2 collections

Detection Strategies

• Monitor network traffic to the configured X-Ray sampling endpoint for anomalous response sizes
• Implement application performance monitoring (APM) to detect memory consumption anomalies
• Configure alerts for OutOfMemoryException events in .NET applications using AWS X-Ray
• Review HTTP response sizes in network logs for the sampling endpoint (default port 2000)

Monitoring Recommendations

• Establish baseline metrics for typical sampling response sizes and alert on deviations
• Deploy SentinelOne Singularity to detect and respond to memory exhaustion attacks targeting application processes
• Implement network segmentation to restrict access to internal sampling endpoints
• Enable verbose logging on the sampling client to capture response metadata for forensic analysis

How to Mitigate CVE-2026-41173

Immediate Actions Required

• Upgrade to OpenTelemetry.Sampler.AWS version 0.1.0-alpha.8 or later immediately
• Review all applications using the AWS X-Ray Remote Sampler for vulnerable versions
• If upgrade is not immediately possible, consider disabling remote sampling temporarily
• Ensure sampling endpoints use HTTPS to prevent MitM attacks

Patch Information

The vulnerability has been addressed in version 0.1.0-alpha.8 of the OpenTelemetry.Sampler.AWS package. The fix introduces bounds checking on HTTP response body sizes before memory allocation. For details on the implementation, see the GitHub Pull Request #4100.

Organizations should update their NuGet package references to specify the minimum version:

<PackageReference Include="OpenTelemetry.Sampler.AWS" Version="0.1.0-alpha.8" />

Workarounds

• Restrict network access to the sampling endpoint using firewall rules to prevent unauthorized connections
• Deploy a reverse proxy in front of the sampling endpoint that enforces maximum response body sizes
• Use HTTPS with certificate pinning for the sampling endpoint to prevent MitM attacks
• Consider implementing a local sampling configuration cache to reduce dependency on remote endpoints

# Example: Configure firewall to restrict access to X-Ray sampling endpoint
# Allow only trusted application servers to reach the sampling endpoint
iptables -A INPUT -p tcp --dport 2000 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 2000 -j DROP