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 *.blob files into one of those signal subdirectories. On the next retry interval (by default every 60 seconds), OtlpExporterPersistentStorageTransmissionHandler scans the directory, loads the attacker-supplied blobs, and forwards them to the configured OTLP endpoint using the application's identity and transport credentials.
3. Disclosure scenario: the attacker reads *.blob files 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).
4. 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:

1. Avoid enabling disk retry in shared environments.
2. Configure a dedicated directory with strict ACL/ownership and least privilege.
3. Ensure the directory is not shared across tenants/users.
4. Monitor for unexpected *.blob files or abnormal retry backlog growth.

References

• #7106