GHSA-4625-4j76-fww9

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 *.blob files 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 *.blob files 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

1. OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY is set to disk.
2. OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH is not set, causing the exporter to resolve the blob storage root using the System.IO.Path.GetTempPath() API.
3. A local attacker has read or write access to the process' temporary directory (e.g., /tmp on Linux, or %TEMP% on a multi-user Windows installation).

Exploit path

1. A target application starts with OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk and no explicit blob directory. The exporter resolves the storage root to Path.GetTempPath(), producing paths such as %TEMP%\traces, %TEMP%\metrics, and %TEMP%\logs (or /tmp/traces etc. on Linux).
2. Injection scenario: before or during the application's retry window, an attacker writes crafted...