OpenTelemetry .NET CVE-2026-40891

The vulnerability requires the instrumented .NET application to use OpenTelemetry.Exporter.OpenTelemetryProtocol version 1.13.1 to 1.15.2 and to export telemetry via the OTLP/gRPC transport specifically - the OTLP/HTTP transport is unaffected. The vulnerable code path activates only when the gRPC server returns a retryable status code (ResourceExhausted or Unavailable), so the attacker must cause or simulate one of those states. The attacker must additionally control the configured gRPC collector endpoint or occupy a MitM position between the exporter and collector; this is satisfied by a compromised internal collector, a misconfigured endpoint pointing to an external host, or a network-level interception position. Exploitation is limited to the telemetry egress channel; no authentication bypass or application-layer access is needed from the attacker's perspective (PR:N in CVSS reflects that the attacker is responding, not authenticating). Deployments enforcing mutual TLS between exporter and collector significantly narrow the viable MitM window but do not protect against a legitimately compromised collector.

The NVD CVSS 5.3 (Medium) score with AV:A/AC:H reflects a constrained attack scenario requiring the adversary to control the OTLP/gRPC collector endpoint or successfully MitM the telemetry channel. EPSS at 0.01% (3rd percentile) is consistent with no observed mass exploitation, and SSVC independently confirms Exploitation: none and Automatable: no, since the attacker must first be positioned in the telemetry path before triggering the vulnerable code. Real-world priority is therefore low for organizations routing telemetry to trusted internal collectors over authenticated channels. However, the AV:A designation may under-represent risk in common cloud deployments where the collector is a remotely hosted service reachable over the internet - in such topologies the effective attack vector is closer to AV:N. No POC has been publicly identified at time of analysis. The SSVC Technical Impact of partial (only availability, no confidentiality or integrity) bounds blast radius to process availability of the instrumented application, not data exfiltration.

An attacker who has compromised the OTLP/gRPC collector endpoint (or who can intercept telemetry traffic in a deployment lacking mutual TLS) waits for the instrumented .NET application to encounter a retryable gRPC error. The attacker crafts a response with a grpc-status-details-bin trailer containing a protobuf varint field length of several gigabytes; the unpatched GrpcStatusDeserializer then issues new byte[~2GB] against the managed heap, triggering an OutOfMemoryException that crashes the instrumented service. No public POC exists, but the vulnerable code path is fully documented in the PR diffs referenced in the GHSA advisory.