GHSA-4625-4j76-fww9 is a medium-severity (CVSS 6.5) vulnerability in OpenTelemetry.Exporter.OpenTelemetryProtocol. O3 Security confirms whether GHSA-4625-4j76-fww9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenTelemetry's disk retry default temp path enables local blob injection via OTLP Exporter
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.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Exporter.OpenTelemetryProtocol. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-4625-4j76-fww9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4625-4j76-fww9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4625-4j76-fww9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4625-4j76-fww9 in your dependencies?
O3 detects GHSA-4625-4j76-fww9 across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.