MEDIUM 6.5 NuGet
OpenTelemetry's disk retry default temp path enables local blob injection via OTLP Exporter
GHSA-4625-4j76-fww9 · CVE-2026-42191
Published · Modified
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
References
- WEB https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-4625-4j76-fww9
- ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-42191
- WEB https://github.com/open-telemetry/opentelemetry-dotnet/pull/7106
- WEB https://github.com/open-telemetry/opentelemetry-dotnet/commit/78dffdc5ebdf3dc090fdb94e3f1a32d3d1e26dfd
- PACKAGE https://github.com/open-telemetry/opentelemetry-dotnet
Ready to move
Start Securing
Free, no credit card | First findings in minutes