CVE-2026-40182: open-telemetry opentelemetry-dotnet · Excessive Memory Allocation
Affects open-telemetry opentelemetry-dotnetSource CVE Database V5
Not known to be exploited · CVSS 5.3 Medium : upgrade to 1.15.2 when convenient.
Data as of 30 Oct 2026, 11:52 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 23% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.15.2
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 23 Apr 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade opentelemetry-dotnet and opentelemetry/opentelemetry-dotnet to 1.15.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| open-telemetryopentelemetry-dotnet | Affected
| Fixed in
|
NuGetopentelemetry/opentelemetry-dotnetpkg:nuget/opentelemetry/opentelemetry-dotnetOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
This vulnerability is fixed in OpenTelemetry dotnet version 1.15.2. Users should upgrade to version 1.15.2 or later to remediate this issue. No other official remediation or temporary fix is documented. Until upgrading, avoid using untrusted or attacker-controlled backends or collectors for telemetry export.
Description
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.
References
- github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-q834-8qmm-v933 (opens in a new tab)
- github.com/open-telemetry/opentelemetry-dotnet/pull/6564 (opens in a new tab)
- github.com/open-telemetry/opentelemetry-dotnet/pull/7017 (opens in a new tab)
- github.com/open-telemetry/opentelemetry-proto/pull/781 (opens in a new tab)