CVE-2026-42191 is a medium-severity (CVSS 6.5) CWE-379 vulnerability in OpenTelemetry.Exporter.OpenTelemetryProtocol. A fix is available for OpenTelemetry.Exporter.OpenTelemetryProtocol — see the affected versions and patch details below.
OpenTelemetry.Exporter.OpenTelemetryProtocol: Disk retry default temp path enables local blob injection for OTLP Exporter
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42191.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
OpenTelemetry.Exporter.OpenTelemetryProtocolReal-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
The OTLP disk retry feature in OpenTelemetry.Exporter.OpenTelemetryProtocol silently fell back to Path.GetTempPath() when OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk was set but OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH was not configured.
The exporter stored and loaded *.blob files under fixed, signal-named subdirectories (traces, metrics, logs) beneath that shared temporary root path.
On multi-user systems where the temporary directory is accessible to other local accounts, this exposed three attack surfaces:
- Blob injection (integrity): an attacker could write crafted
*.blobfiles into the predictable path; the exporter picks them up on the next retry cycle and forwards them to the configured OTLP endpoint under the application's identity. - Telemetry disclosure (confidentiality): an attacker reads
*.blobfiles written by the application between export failures, recovering encoded telemetry payloads (spans, metric data points, log records). - Resource exhaustion (availability): an attacker deposits numerous or oversized blob files, degrading retry-loop performance or consuming disk space.
Details
Preconditions
OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRYis set todisk.OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATHis not set, causing the exporter to resolve the blob storage root using theSystem.IO.Path.GetTempPath()API.- A local attacker has read or write access to the process' temporary directory (e.g.,
/tmpon Linux, or%TEMP%on a multi-user Windows installation).
Exploit path
- A target application starts with
OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskand no explicit blob directory. The exporter resolves the storage root toPath.GetTempPath(), producing paths such as%TEMP%\traces,%TEMP%\metrics, and%TEMP%\logs(or/tmp/tracesetc. on Linux). - Injection scenario: before or during the application's retry window, an attacker writes crafted
*.blobfiles into one of those signal subdirectories. On the next retry interval (by default every 60 seconds),OtlpExporterPersistentStorageTransmissionHandlerscans the directory, loads the attacker-supplied blobs, and forwards them to the configured OTLP endpoint using the application's identity and transport credentials. - Disclosure scenario: the attacker reads
*.blobfiles that the application wrote after a transient export failure, recovering the full serialized telemetry payloads (spans, metric data points, or log records in Protobuf encoding). - DoS scenario: the attacker deposits a large number of oversized blob files in the temporary subdirectories, causing the retry loop to consume excess CPU/IO processing them, potentially exhausting available disk space.
Mitigations
If an immediate upgrade to a patched version is not possible:
- Avoid enabling disk retry in shared environments.
- Configure a dedicated directory with strict ACL/ownership and least privilege.
- Ensure the directory is not shared across tenants/users.
- Monitor for unexpected
*.blobfiles or abnormal retry backlog growth.
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | OpenTelemetry.Exporter.OpenTelemetryProtocol | ≥ 1.8.0&&< 1.15.3 | 1.15.3dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol --version 1.15.3 |
Affected Products
opentelemetry.exporter.opentelemetryprotocolopentelemetryDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Exporter.OpenTelemetryProtocol, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update OpenTelemetry.Exporter.OpenTelemetryProtocol to 1.15.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42191 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2026-42191 in your dependencies?
Find it across NuGet, including transitive dependencies.