OpenTelemetry.Resources.Azure CVE-2026-41483
MEDIUM
GHSA-vc24-j8c5-2vw4
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
AV:A better reflects the link-local IMDS endpoint (169.254.169.254); AC:H for required MitM position; A:H for process-terminating OOM crash.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
OpenTelemetry.Resources.Azure reads unbounded HTTP response bodies from the Azure VM remote instance metadata service endpoint into memory.
This would allow an attacker-controlled endpoint or one acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)).
Details
The AzureVmMetaDataRequestor class makes HTTP requests to the relevant Azure VM instance metadata service (http://169.254.169.254) to obtain metadata about the running process and its infrastructure.
An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process.
Impact
Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the Azure VM instance metadata HTTP response paths.
Mitigating Factors
The application's reachable Azure VM metadata endpoint needs to behave maliciously or be subject to MitM. In normal usage response bodies should not be excessively large.
Patches
Fixed in OpenTelemetry.Resources.Azure version 1.15.0-beta.2.
The fix (#4121) introduce changes that introduce limits to HttpClient requests so that the response body is streamed rather than buffered entirely in memory. Responses greater than 4 MiB are ignored.
Workarounds
- Disable the Azure VM resource detector.
- Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the Azure VM instance metadata endpoint.
References
AnalysisAI
Unbounded HTTP response buffering in OpenTelemetry.Resources.Azure (NuGet, versions ≤ 1.15.0-beta.1) allows an attacker who controls or can MitM the Azure VM Instance Metadata Service endpoint at http://169.254.169.254 to cause heap exhaustion and crash the consuming .NET process via OutOfMemoryException. The AzureVmMetaDataRequestor class calls HttpClient.GetStringAsync() with no response-size limit, meaning an adversarial IMDS response of arbitrary size is fully buffered into managed memory before deserialization. No public exploit exists and EPSS is 0.04%, but the DoS impact is process-terminating if the MitM prerequisite can be satisfied.
Technical ContextAI
The vulnerability resides in the AzureVmMetaDataRequestor class within the OpenTelemetry.Resources.Azure NuGet package (CPE: pkg:nuget/opentelemetry.resources.azure), part of the opentelemetry-dotnet-contrib project. The class uses HttpClient.GetStringAsync() to fetch JSON from the Azure IMDS link-local address (http://169.254.169.254/metadata/instance/compute?api-version=2021-12-13), buffering the entire HTTP response body into a .NET managed string before passing it to JsonSerializer. CWE-770 (Allocation of Resources Without Limits or Throttling) is the root cause: no maximum response size is enforced, so a manipulated response of arbitrary byte length is fully allocated on the .NET managed heap, triggering GC pressure, stalls, or an OutOfMemoryException that terminates the process. The fix in PR #4121 replaces GetStringAsync with a streaming pattern using HttpCompletionOption.ResponseHeadersRead and introduces a shared HttpClientHelpers utility that enforces a 4 MiB hard cap, silently discarding oversized responses rather than throwing.
RemediationAI
Upgrade to OpenTelemetry.Resources.Azure version 1.15.0-beta.2 or later; verify the exact published NuGet version against NuGet.org due to a minor discrepancy between the GHSA advisory (which states 1.15.0-beta.2) and the source code evidence (which references 1.15.1-beta.1 as the fixed version). The patch (commit 9d8a364, PR #4121 at https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4121) enforces a 4 MiB response cap and streams rather than buffers IMDS responses. If immediate upgrade is not possible, two vendor-documented workarounds exist: first, disable the Azure VM resource detector entirely - this eliminates all IMDS queries at the cost of losing Azure VM infrastructure metadata in telemetry exports; second, apply network-level controls such as host-based firewall rules or service mesh policy to ensure only the legitimate Azure IMDS endpoint can respond on 169.254.169.254, preventing MitM injection - note that the IMDS endpoint uses plain HTTP so mTLS cannot be applied directly to it, making host firewall or eBPF-based enforcement the practical option. Full advisory: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-vc24-j8c5-2vw4.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today