CVE-2026-84445 — grpc
Fix: grpc/grpc-go@3822494CVE-2026-84445 is a CWE-129 vulnerability in google.golang.org/grpc. A fix is available for google.golang.org/grpc — see the affected versions and patch details below.
gRPC-Go: Denial of Service (DoS) via crash due to missing `:authority` and `Host` headers in the xDS servers
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- 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-84445.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
google.golang.org/grpc🐹google.golang.org/grpc🐹google.golang.org/grpc🐹google.golang.org/grpcReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).
Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.
This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.
- Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
- mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.
Impact
An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.
Patches
The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | google.golang.org/grpc | all versions | 1.82.2go get google.golang.org/grpc@v1.82.2 |
| 🐹Go | google.golang.org/grpc | ≥ 1.83.0&&< 1.83.2 | 1.83.2go get google.golang.org/grpc@v1.83.2 |
| 🐹Go | google.golang.org/grpc | ≥ 1.84.0-dev&&< 1.84.0-dev.0.20260825144003-d5a41119e0e3 | 1.84.0-dev.0.20260825144003-d5a41119e0e3go get google.golang.org/grpc@v1.84.0-dev.0.20260825144003-d5a41119e0e3 |
| 🐹Go | google.golang.org/grpc | ≥ 1.85.0-dev&&< 1.85.0-dev.0.20260825072537-93e31b48545e | 1.85.0-dev.0.20260825072537-93e31b48545ego get google.golang.org/grpc@v1.85.0-dev.0.20260825072537-93e31b48545e |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for google.golang.org/grpc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update google.golang.org/grpc to 1.82.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-84445 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 10 | opentelemetry-collector-0:0.158.0-1.el10_2 | RHSA-2026:76743 |
| Red Hat Enterprise Linux 10.0 Extended Update Support | opentelemetry-collector-0:0.158.0-1.el10_0 | RHSA-2026:82344 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | rhc-worker-script-0:0.12-1.el7_9 | RHSA-2026:75689 |
| Red Hat Enterprise Linux 8 | rhc-1:0.2.5-12.el8_10 | RHSA-2026:73915 |
| Red Hat Enterprise Linux 9 | rhc-1:0.2.7-13.el9_8 | RHSA-2026:72275 |
| Red Hat Enterprise Linux 9 | opentelemetry-collector-0:0.158.0-1.el9_8 | RHSA-2026:76744 |
| Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions | rhc-1:0.2.2-1.el9_2.6 | RHSA-2026:79012 |
| Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions | rhc-1:0.2.4-9.el9_4.2 | RHSA-2026:79011 |
Frequently Asked Questions
Is CVE-2026-84445 in your dependencies?
Find it across Go, including transitive dependencies.