GitHub Advisoryadvisory · NuGet

GHSA-mr8r-92fq-pj8p OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling

MEDIUM Published 2026-04-23 Modified 2026-04-23 Official page ↗
Aliases
CVE-2026-40891
Ecosystem
NuGet
Packages
OpenTelemetry.Exporter.OpenTelemetryProtocol
Severity
Moderate
CVSS vector
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Weaknesses
CWE-789
Reviewed
2026-04-23

Affected packages

• NuGet OpenTelemetry.Exporter.OpenTelemetryProtocol: >= 1.13.1, < 1.15.3 → fixed in 1.15.3

Description

Summary 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). Details 5980 introduced a retry path that parses `grpc-status-details-bin` to extract gRPC retry delay information for retryable responses. On that path: • `OtlpGrpcExportClient` captures `grpc-status-details-bin` from retryable status responses (`ResourceExhausted` / `Unavailable`). • `OtlpRetry` invokes `GrpcStatusDeserializer.TryGetGrpcRetryDelay` using this untrusted trailer value. • `GrpcStatusDeserializer.DecodeBytes` decoded a protobuf varint length and allocated `new byte[length]` without validating the bounds against the remaining payload size. A malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted `grpc-status-details-bin` payload that forces oversized allocation and memory exhaustion in the instrumented process. Impact If an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS). Mitigation The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs. Workarounds None known. Remediation #7064 updates `GrpcStatusDeserializer` to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload. This causes malformed or truncated `grpc-status-details-bin` payloads to fail safely instead of attempting unbounded allocation.

Related

Alias · CVE (1)

  • CVE-2026-40891 OpenTelemetry dotnet is a dotnet telemetry framework. vulnerability

Weakness · CWE (1)

  • CWE-789 Memory Allocation with Excessive Size Value weakness

References