How severe is CVE-2026-40891?

CVE-2026-40891 has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by CVE-2026-40891?

CVE-2026-40891 affects the following packages: OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet). Ecosystems affected: NuGet.

How do I fix CVE-2026-40891?

Update OpenTelemetry.Exporter.OpenTelemetryProtocol to 1.15.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40891 is resolved across your whole dependency graph.

How do I detect CVE-2026-40891 in my NuGet dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Exporter.OpenTelemetryProtocol, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-40891 if there is no patch (or I can't update yet)?

Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Is CVE-2026-40891 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-40891 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-40891?

CVE-2026-40891 has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 9th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-40891?

CVE-2026-40891 is classified as CWE-789 (CWE-789). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-40891 published, and has it been updated?

CVE-2026-40891 was published on April 23, 2026 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

.NET

.NET NuGet

Not in CISA KEV

MEDIUM severity

CVE-2026-40891 — OpenTelemetry.Exporter.Op…

MEDIUMFix: open-telemetry/opentelemetry-dotnet#5980

CVE-2026-40891 is a medium-severity (CVSS 5.3) CWE-789 vulnerability in OpenTelemetry.Exporter.OpenTelemetryProtocol. A fix is available for OpenTelemetry.Exporter.OpenTelemetryProtocol — see the affected versions and patch details below.

OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling

Also known asGHSA-mr8r-92fq-pj8p

Published

Apr 23, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40891.

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs9th percentile — riskier than 9% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

.NETOpenTelemetry.Exporter.OpenTelemetryProtocol

Real-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:

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
.NETNuGet	`OpenTelemetry.Exporter.OpenTelemetryProtocol`	≥ 1.13.1&&< 1.15.3	1.15.3`dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol --version 1.15.3`

Affected Products

1 product · 1 configurations

Application

opentelemetryopentelemetry

≥ 1.13.1 && < 1.15.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for OpenTelemetry.Exporter.OpenTelemetryProtocol, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 CVE-2026-40891 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Frequently Asked Questions

### 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` capture