GHSA-vc24-j8c5-2vw4 is a medium-severity (CVSS 5.9) vulnerability in OpenTelemetry.Resources.Azure. O3 Security confirms whether GHSA-vc24-j8c5-2vw4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenTelemetry.Resources.Azure has an unbounded HTTP response body read
Real-World Exposure
OpenTelemetry.Resources.AzureReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | OpenTelemetry.Resources.Azure | all versions | 1.15.1-beta.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Resources.Azure. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update OpenTelemetry.Resources.Azure to 1.15.1-beta.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vc24-j8c5-2vw4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vc24-j8c5-2vw4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vc24-j8c5-2vw4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vc24-j8c5-2vw4 in your dependencies?
O3 detects GHSA-vc24-j8c5-2vw4 across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.