CVE-2026-40891: OpenTelemetry dotnet DoS Vulnerability

CVE-2026-40891 Overview

OpenTelemetry .NET is a popular telemetry framework used for collecting and exporting observability data from .NET applications. A denial of service vulnerability exists in versions 1.13.1 to before 1.15.2 of the OpenTelemetry .NET SDK. When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter parses a server-provided grpc-status-details-bin trailer during retry handling. A malformed trailer could encode an extremely large length-delimited protobuf field, which was used directly for memory allocation without proper validation, allowing excessive memory allocation and potential denial of service (DoS).

Critical Impact

Attackers positioned on an adjacent network can exploit this vulnerability to cause memory exhaustion in applications using OpenTelemetry .NET OTLP gRPC exporters, leading to service unavailability and potential cascading failures in observability pipelines.

Affected Products

• OpenTelemetry .NET SDK versions 1.13.1 to 1.15.1
• Applications using OTLP gRPC exporter for telemetry export
• .NET services configured with OpenTelemetry instrumentation and gRPC transport

Discovery Timeline

• 2026-04-23 - CVE CVE-2026-40891 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-40891

Vulnerability Analysis

This vulnerability falls under CWE-789 (Memory Allocation with Excessive Size Value), a memory exhaustion condition that occurs when software allocates memory based on untrusted input without proper bounds checking. In the context of OpenTelemetry .NET, the flaw resides in the OTLP gRPC exporter's retry handling mechanism.

When the OTLP exporter encounters transport errors and attempts retries, it parses the grpc-status-details-bin trailer returned by the server to extract detailed status information. The protobuf parsing logic for this trailer did not properly validate length-delimited field sizes before allocating memory buffers. A malicious or compromised telemetry backend could craft a response containing an encoded length prefix specifying an extremely large allocation size, potentially gigabytes of memory, which the client would attempt to allocate.

The attack requires adjacent network access, meaning the attacker must be able to intercept or act as the telemetry backend receiving gRPC connections. While this raises the attack complexity, environments with compromised internal networks or man-in-the-middle positions are vulnerable. The impact is limited to availability; no data confidentiality or integrity compromise is possible through this vector.

Root Cause

The root cause is insufficient input validation in the protobuf parsing logic for the grpc-status-details-bin gRPC trailer. The length-delimited field's encoded size was trusted without verification against reasonable maximum bounds, leading to uncontrolled memory allocation. This is a classic instance of trusting untrusted data for resource allocation decisions. The fix introduces proper validation of length prefixes before memory allocation, rejecting malformed or excessively large values.

Attack Vector

The attack requires an adversary to position themselves as the telemetry collection endpoint or to intercept gRPC communications on the adjacent network. When the victim's application sends telemetry data via OTLP gRPC and receives a crafted response with a malformed grpc-status-details-bin trailer during a retry scenario, the exporter's parsing logic attempts to allocate memory based on the attacker-controlled length value.

The vulnerability manifests during retry handling in the OTLP gRPC exporter. When a server returns an error response with the malicious trailer, the client attempts to parse the protobuf-encoded status details. The length prefix in the protobuf wire format specifies how many bytes to read for the next field, and this value was used directly for buffer allocation without bounds checking. See the GitHub Security Advisory GHSA-mr8r-92fq-pj8p for complete technical details.

Detection Methods for CVE-2026-40891

Indicators of Compromise

• Sudden memory spikes in applications using OpenTelemetry .NET with OTLP gRPC export
• Out-of-memory exceptions or application crashes during telemetry export operations
• Abnormal gRPC response patterns from telemetry backends containing oversized trailers
• Application pool recycling or container restarts due to memory pressure

Detection Strategies

• Monitor process memory utilization for .NET applications with OpenTelemetry instrumentation
• Implement alerting on OutOfMemoryException occurrences in application logs
• Review gRPC traffic for anomalous grpc-status-details-bin trailer sizes
• Audit OpenTelemetry .NET package versions across the software inventory

Monitoring Recommendations

• Deploy APM monitoring to track memory allocation patterns in affected applications
• Configure resource limits (memory) for containers running vulnerable workloads
• Enable detailed logging for OTLP exporter retry operations
• Monitor network traffic between applications and telemetry collection endpoints for anomalies

How to Mitigate CVE-2026-40891

Immediate Actions Required

• Upgrade OpenTelemetry .NET SDK to version 1.15.2 or later immediately
• Review all .NET applications using OpenTelemetry with OTLP gRPC transport
• Audit NuGet package dependencies for affected OpenTelemetry versions
• Consider temporarily switching to HTTP/protobuf transport if immediate upgrade is not possible

Patch Information

The vulnerability is fixed in OpenTelemetry .NET version 1.15.2. The fix introduces proper validation of length-delimited field sizes before memory allocation in the OTLP gRPC exporter's retry handling logic. Organizations should update their NuGet package references to the patched version. Refer to GitHub Pull Request #7064 and GitHub Pull Request #5980 for implementation details of the security fix.

Workarounds

• Configure memory limits on application containers to prevent system-wide impact from memory exhaustion
• Use network segmentation to restrict which endpoints can act as telemetry backends
• If upgrading is not immediately possible, consider switching to OTLP HTTP/protobuf export instead of gRPC
• Implement network-level monitoring between applications and telemetry collectors

# Update OpenTelemetry .NET packages to patched version
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol --version 1.15.2

# Verify installed package version
dotnet list package | grep OpenTelemetry