Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain network adjacency to application host
-
DeliveryIntercept or impersonate OTLP collector endpoint
-
ExploitTrigger telemetry export failure (force 4xx/5xx)
-
ExecutionReturn HTTP error response with oversized body
-
PersistApplication reads unbounded response body into memory
-
ImpactProcess memory exhausted, denial-of-service achieved
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Exploitation requires both of the following specific conditions: (1) the attacker must either control the OTLP collector/backend endpoint defined in the application's telemetry configuration, or be capable of performing a man-in-the-middle attack on the network path between the application and its collector; and (2) the application must use OpenTelemetry.Exporter.OpenTelemetryProtocol at a version between 1.13.1 and 1.15.1 inclusive with OTLP export actively configured over HTTP or gRPC. The adjacent-network attack vector (AV:A) limits exploitation to attackers with physical or logical adjacency to the export network path - remote internet-based attackers without network adjacency cannot exploit this directly. Applications exporting telemetry exclusively to internal, authenticated collectors over private networks are not realistically at risk. The SSVC Automatable:no rating confirms the attack cannot be trivially replicated at scale. |
| Impact | The provided CVSS 5.3 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately captures the constrained threat model: the attacker must occupy a network-adjacent position and either control the OTLP collector endpoint or execute a man-in-the-middle attack, both of which constitute high complexity prerequisites. EPSS at 0.01% (3rd percentile) and SSVC Exploitation:none independently confirm no observed exploitation activity, making this a low-urgency finding despite the High availability impact rating. SSVC Automatable:no aligns with AC:H - the attack cannot be scripted for mass exploitation. Technical Impact:partial reflects that only the exporting application's availability is affected, with no confidentiality or integrity consequence. Real-world risk is concentrated in deployments where the OTLP export path traverses untrusted network segments or uses third-party collector endpoints; applications exporting to internal, trusted collectors over authenticated channels face negligible realistic risk. The 'Information Disclosure' tag present in the input data appears to be a metadata error - the GHSA advisory, CWE-789, and CVSS vector all confirm the sole impact is availability (DoS), not information disclosure. |
| Exploit ScenarioDerived | An attacker positioned on the same network segment as a .NET application (e.g., via ARP spoofing on a shared LAN or cloud VPC) intercepts the OTLP telemetry export connection and responds to export requests with HTTP 503 responses containing a multi-gigabyte response body. The application's OTLP exporter reads the entire body into memory without bound, exhausting the process heap and crashing the application. No public exploit code has been identified for this vulnerability. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 24, 2026
Memory exhaustion in the OpenTelemetry dotnet OTLP exporter (versions 1.13.1 through 1.15.1) enables a denial-of-service condition when an attacker controls the configured telemetry backend or can MitM the export connection. Both the gRPC and HTTP/protobuf transport paths in OtlpGrpcExportClient and OtlpHttpExportClient read the full HTTP error response body into memory without any size cap, allowing an adversary to return an arbitrarily large body and exhaust the process heap. No active exploitation is confirmed (absent from CISA KEV, EPSS 0.01%), and vendor-released patch 1.15.2 is available.
RemediationAI
Upgrade the OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package to version 1.15.2, which applies the fix from PR #7017 (https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) adding an explicit byte-read limit to both the gRPC and HTTP/protobuf export clients. The GHSA advisory confirms no workarounds are known. As a compensating control where immediate upgrade is not possible, restrict the OTLP export endpoint to a trusted internal network segment and enforce mutual TLS (mTLS) between the application and collector, which eliminates the MitM vector; note that mTLS requires collector reconfiguration and does not protect against a compromised collector endpoint itself. Ensuring the collector is a well-behaved, vendor-maintained implementation (e.g., OpenTelemetry Collector) that does not return excessively large error bodies also reduces practical exposure, but this is a defense-in-depth measure rather than a fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in nuget, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability resides in the NuGet package OpenTelemetry.Exporter.OpenTelemetryProtocol (CPE: cpe:2.3:a:open-telemetry:opentelemetry-dotnet:*:*:*:*:*:*:*:*), specifically in OtlpExportClient.cs. CWE-789 (Uncontrolled Memory Allocation) is the root cause: PR #6564 introduced a TryGetResponseBody helper that reads the HTTP response body via ReadAsStream or ReadAsStringAsync with no byte ceiling whenever a non-200 status code is received, so that operators could see error responses in exporter logs. Both the gRPC export path (OtlpGrpcExportClient) and the HTTP/protobuf path (OtlpHttpExportClient) call this helper on failure. The upstream OpenTelemetry Protocol specification was also updated (opentelemetry-proto PR #781) to mandate that all OTLP clients enforce a 4 MiB default response size limit, codifying the fix as a protocol-level requirement.
Know when Opentelemetry Dotnet gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Adjacent vector and high complexity because exploitation requires network adjacency plus endpoint control or MitM; no confidentiality or integrity impact applies.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
OpenTelemetry dotnet is a dotnet telemetry framework. From 1.13.1 to before 1.15.2, When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response. This vulnerability is fixed in 1.15.2.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Opentelemetry Dotnet
View allUncontrolled memory allocation in OpenTelemetry dotnet's propagation header parsing exposes .NET applications to denial
Memory exhaustion via unbounded protobuf allocation in OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet) affects vers
EUVD-2026-25266
GHSA-q834-8qmm-v933
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB