GHSA-mr8r-92fq-pj8p
MEDIUMGHSA-mr8r-92fq-pj8p is a medium-severity (CVSS 5.3) CWE-789 vulnerability in OpenTelemetry.Exporter.OpenTelemetryProtocol. O3 Security confirms whether GHSA-mr8r-92fq-pj8p is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling
Blast Radius
OpenTelemetry.Exporter.OpenTelemetryProtocolReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
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:
OtlpGrpcExportClientcapturesgrpc-status-details-binfrom retryable status responses (ResourceExhausted/Unavailable).OtlpRetryinvokesGrpcStatusDeserializer.TryGetGrpcRetryDelayusing this untrusted trailer value.GrpcStatusDeserializer.DecodeBytesdecoded a protobuf varint length and allocatednew 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | OpenTelemetry.Exporter.OpenTelemetryProtocol | ≥ 1.13.1&&< 1.15.3 | 1.15.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Exporter.OpenTelemetryProtocol. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update OpenTelemetry.Exporter.OpenTelemetryProtocol to 1.15.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mr8r-92fq-pj8p is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mr8r-92fq-pj8p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mr8r-92fq-pj8p. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mr8r-92fq-pj8p in your dependencies?
O3 detects GHSA-mr8r-92fq-pj8p across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.