CVE-2026-84445: gRPC-Go: Denial of Service (DoS) via crash due to missing `:authority` and `Host` headers in the xDS servers
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.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.
Other sources
gRPC-Go is the Go language implementation of gRPC. Prior to 1.82.2 and 1.83.2, servers created with xds.NewGRPCServer() allow internal/transport/http2server.go to accept an RPC containing neither the :authority header nor the Host header, while RouteAndProcess in internal/xds/server/routing.go assumes that an authority value exists and indexes the empty slice. A remote client that can complete transport connection establishment can trigger an index-out-of-bounds panic that is not recovered by the per-RPC goroutine and terminates the entire server process. In insecure or ordinary TLS deployments the request can be unauthenticated, while strict mTLS or ALTS deployments require valid transport credentials before the malformed RPC can reach the interceptor. This issue is fixed in versions 1.82.2 and 1.83.2.
— NVD
gRPC-Go: Denial of Service (DoS) via crash due to missing :authority and Host headers in the xDS servers
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/google.golang.org/grpcto a version that resolves this vulnerability.Fixed in 1.85.0-dev.0.20260825072537-93e31b48545e - Upgrade
Upgrade
go/google.golang.org/grpcto a version that resolves this vulnerability.Fixed in 1.83.2 - Upgrade
Upgrade
go/google.golang.org/grpcto a version that resolves this vulnerability.Fixed in 1.82.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.101.0-1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.5.1-9 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.31.0-33 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.0.10-10 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.12.15-14 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.11.4-21 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.15.0.aks0-21 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 19.0.4-14 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 10.25.1-9 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.62.0-8 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.7.5-21 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.14.4-13 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.32.0.kata0-6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.7.0-8 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.6.0-3 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.5.34-1 - Upgrade
Upgrade
azurelinux/kubevirtto a version that resolves this vulnerability.Fixed in 1.8.4-3 - Upgrade
Upgrade
azurelinux/kedato a version that resolves this vulnerability.Fixed in 2.14.1-21 - Upgrade
Upgrade
azurelinux/kubernetesto a version that resolves this vulnerability.Fixed in 1.30.10-31 - Upgrade
Upgrade
azurelinux/prometheus-adapterto a version that resolves this vulnerability.Fixed in 0.12.0-11 - Upgrade
Upgrade
azurelinux/flannelto a version that resolves this vulnerability.Fixed in 0.24.2-33 - Upgrade
Upgrade
azurelinux/docker-composeto a version that resolves this vulnerability.Fixed in 2.27.0-15 - Upgrade
Upgrade
azurelinux/vitessto a version that resolves this vulnerability.Fixed in 19.0.4-14 - Upgrade
Upgrade
azurelinux/kata-containers-ccto a version that resolves this vulnerability.Fixed in 3.15.0.aks0-21 - Upgrade
Upgrade
azurelinux/kata-containersto a version that resolves this vulnerability.Fixed in 3.32.0.kata0-6 - Upgrade
Upgrade
azurelinux/sriov-network-device-pluginto a version that resolves this vulnerability.Fixed in 3.7.0-8 - Upgrade
Upgrade
azurelinux/influxdbto a version that resolves this vulnerability.Fixed in 2.7.5-21 - Upgrade
Upgrade
azurelinux/moby-engineto a version that resolves this vulnerability.Fixed in 25.0.3-21 - Upgrade
Upgrade
azurelinux/skopeoto a version that resolves this vulnerability.Fixed in 1.14.4-13 - Upgrade
Upgrade
azurelinux/corednsto a version that resolves this vulnerability.Fixed in 1.11.4-21 - Upgrade
Upgrade
azurelinux/ghto a version that resolves this vulnerability.Fixed in 2.101.0-1 - Upgrade
Upgrade
azurelinux/etcdto a version that resolves this vulnerability.Fixed in 3.5.34-1 - Upgrade
Upgrade
azurelinux/azurelinux-image-toolsto a version that resolves this vulnerability.Fixed in 1.6.0-3 - Upgrade
Upgrade
azurelinux/containerized-data-importerto a version that resolves this vulnerability.Fixed in 1.62.0-8 - Upgrade
Upgrade
azurelinux/azcopyto a version that resolves this vulnerability.Fixed in 10.25.1-9 - Upgrade
Upgrade
azurelinux/cert-managerto a version that resolves this vulnerability.Fixed in 1.12.15-14 - Upgrade
Upgrade
azurelinux/kube-vip-cloud-providerto a version that resolves this vulnerability.Fixed in 0.0.10-10 - Upgrade
Upgrade
azurelinux/cloud-provider-kubevirtto a version that resolves this vulnerability.Fixed in 0.5.1-9 - Upgrade
Upgrade
azurelinux/telegrafto a version that resolves this vulnerability.Fixed in 1.31.0-33 - Upgrade
Upgrade
azurelinux/containerd2to a version that resolves this vulnerability.Fixed in 2.3.7-1 - Upgrade
Upgrade
gRPC-Go (xds.NewGRPCServer)to a version that resolves this vulnerability.Fixed in 1.82.2 - Upgrade
Upgrade
gRPC-Go (xds.NewGRPCServer)to a version that resolves this vulnerability.Fixed in 1.83.2
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated remote denial-of-service attempts?
Servers created with xds.NewGRPCServer() are exposed if they permit plaintext connections or use standard TLS credentials that do not validate client certificates. In those configurations, an unauthenticated remote attacker can complete the connection setup and send the malformed request.
Does enabling TLS by itself prevent exploitation?
No. Standard TLS prevents neither the required HTTP/2 connection establishment nor the malformed request from reaching the xDS routing interceptor when client certificates are not checked. The request must only complete the configured transport-credentials handshake before it can trigger the panic.
What request condition triggers the failure?
The request must omit both the HTTP/2 :authority header and the Host header. This leaves the interceptor with no authority values and causes an out-of-bounds access while selecting an xDS virtual host.