EUVD-2026-25268
GHSA-mr8r-92fq-pj8p
Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
AV:N because the collector can be any remote endpoint the app is configured to export to, not necessarily adjacent; AC:H because controlling the response requires compromising the collector or performing MitM.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6DescriptionGitHub Advisory
OpenTelemetry dotnet is a dotnet telemetry framework. From 1.13.1 to before 1.15.2, When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided grpc-status-details-bin trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS). This vulnerability is fixed in 1.15.2.
AnalysisAI
Memory exhaustion via unbounded protobuf allocation in OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet) affects versions 1.13.1 through 1.15.2 when exporting telemetry over OTLP/gRPC. An attacker controlling the gRPC collector endpoint or intercepting telemetry traffic can return a malformed grpc-status-details-bin trailer on a retryable response, causing the instrumented .NET process to attempt an arbitrarily large byte array allocation and exhaust available memory. No public exploit exists and SSVC confirms no active exploitation; a vendor patch is available in 1.15.3.
Technical ContextAI
The vulnerability resides in GrpcStatusDeserializer.cs within the OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package (CPE: cpe:2.3:a:open-telemetry:opentelemetry.exporter.opentelemetryprotocol). The retry path introduced in PR #5980 reads the grpc-status-details-bin HTTP/2 trailer from retryable gRPC responses (status codes ResourceExhausted and Unavailable) to extract backoff delay information. The DecodeBytes method decoded a protobuf varint field length and directly invoked new byte[length] without validating that the declared length was consistent with remaining bytes in the payload - a textbook CWE-789 (Uncontrolled Memory Allocation) pattern. A crafted protobuf message can encode a varint of up to approximately 2 GB as a single length-delimited field, causing that allocation from the .NET managed heap in a single call and triggering an OutOfMemoryException that crashes the instrumented process.
RemediationAI
Upgrade OpenTelemetry.Exporter.OpenTelemetryProtocol to version 1.15.3 or later, which validates decoded protobuf length-delimited field sizes against remaining payload size before allocation (fix implemented in PR #7064). The full advisory is at https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-mr8r-92fq-pj8p. The GHSA advisory confirms no workarounds are known. As a compensating control while upgrading, enforce mutual TLS between the instrumented application and its OTLP/gRPC collector - this closes the MitM attack surface but does not protect against a compromised collector endpoint itself. Additionally, restrict network egress for telemetry traffic to allowlisted, internally managed collector IPs via firewall rules, reducing exposure to attacker-controlled endpoints. Neither compensating control eliminates the vulnerability; patching to 1.15.3 remains the only complete remediation.
More in Opentelemetry Dotnet
View allUncontrolled memory allocation in OpenTelemetry dotnet's propagation header parsing exposes .NET applications to denial
Memory exhaustion in the OpenTelemetry dotnet OTLP exporter (versions 1.13.1 through 1.15.1) enables a denial-of-service
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today