OpenTelemetry .NET CVE-2026-42191

Exploitation requires all of: (1) the application sets OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk; (2) OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH is NOT set, forcing the exporter to resolve storage to Path.GetTempPath() and create fixed traces/metrics/logs subdirectories; and (3) the attacker holds a separate local account with read/write access to that shared temp root (/tmp on Linux, %TEMP% on a multi-user Windows install). Limiting factors that reduce realistic risk: the feature is experimental and off by default, the insecure path only occurs when the directory variable is omitted, the attacker must already have local access on the same host, and the temp directory must actually be shared/accessible across users - single-tenant hosts or properly ACL'd temp directories are not exposed. The only complete fix per the vendor is upgrading to 1.15.3, which removes the fallback and throws if the directory variable is unset; interim mitigations are avoiding disk retry in shared environments, configuring a dedicated least-privilege directory, not sharing it across tenants, and monitoring for unexpected *.blob files or retry backlog growth.

Signals are consistent and point to a real-but-conditional local issue rather than an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N, C:H/I:H/A:H, score 7.8 HIGH) describes a local, low-privilege attack with high impact across confidentiality, integrity and availability - matching CWE-379 (temp file in a directory with insecure permissions). EPSS is 0.01% (2nd percentile), which is expected for a local-only flaw gated behind a non-default experimental configuration, and there is no CISA KEV listing, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_week', indicating prompt but non-emergency patching. These signals do not conflict: a high CVSS driven by full CIA impact coexists with very low real-world exploitation probability because the attack requires an attacker-controlled local account on a multi-user host AND a victim that enabled the experimental disk-retry feature without setting a dedicated directory. The main uncertainty is the real-world footprint of that specific misconfiguration; the vulnerability class and impact are confirmed, but how many deployments actually run the experimental disk retry with the default temp path is unknown from the provided data. Treat as a priority for the narrow set of multi-tenant/shared .NET hosts using this feature; lower priority elsewhere.

On a shared multi-user host, a target .NET application runs with OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk but no explicit retry directory, so the exporter falls back to the world-accessible temp root and creates predictable subdirectories (/tmp/traces, /tmp/metrics, /tmp/logs or the %TEMP% equivalents). A separate local user drops crafted *.blob files into one of those directories, and on the next ~60-second retry cycle the exporter loads and forwards them to the configured OTLP endpoint under the application's identity (integrity); the same user can also read blobs the app wrote after transient failures to recover serialized telemetry (confidentiality), or flood the directory with oversized blobs to exhaust CPU/IO/disk (availability). No public exploit identified at time of analysis; the only referenced code is the vendor patch (PR #7106).