CVE-2026-84445

What it actually does

gRPC-Go xDS servers created with xds.NewGRPCServer() accept an HTTP/2 RPC that has neither the :authority pseudo-header nor the Host header. RouteAndProcess then indexes an empty authority slice, causing an unrecovered index-out-of-bounds panic in the per-RPC goroutine that aborts the entire server process. Confidentiality and integrity are unaffected; the impact is process-wide denial of service. In insecure or ordinary TLS deployments the malformed RPC can be unauthenticated; strict mTLS or ALTS still require valid transport credentials before the panic path is reached.

Why it matters to the business

A remote caller can take down gRPC-Go xDS listeners used by cluster-security, certificate-management, observability, Helm, multi-cluster, and OpenShift AI operator workloads, causing abrupt outages until the process is restarted and remaining crash-loops if the attacker repeats the request. Because the vulnerable library is embedded across a wide Red Hat product set, a single availability failure can interrupt certificate issuance, cluster add-ons, network observability, and model-serving control planes. The flaw is not in CISA KEV and has no reported ransomware use, and public exploit maturity is none, but it is remotely triggerable with low complexity and has been public for about 20 days, so unpatched internet- or cluster-facing xDS gRPC servers remain an operational availability risk.

How an attack unfolds

An attacker who can complete a gRPC/HTTP/2 transport handshake against a server built with xds.NewGRPCServer() issues an RPC that omits both :authority and Host. The HTTP/2 server layer accepts the call; xDS routing assumes an authority value exists and indexes an empty slice. The panic is not recovered, so the whole process exits rather than rejecting only that RPC. On plaintext or standard TLS listeners this can be done without application credentials; on strict mTLS or ALTS the attacker must first present valid transport credentials. No named threat actors, ransomware campaigns, or public exploit code are associated with this issue; abuse would appear as a sudden process crash after a well-formed transport setup rather than as a distinct malware implant.

How to fix it

Upgrade the gRPC-Go library to 1.82.2, 1.83.2, or later so xDS routing no longer panics on a missing authority. For Red Hat-packaged products apply RHSA-2026:72884, including: advanced-cluster-security/rhacs rhel8-operator:1790620930; rhacs-scanner v4-rhel8:1790620930; cert-manager operator-rhel9:1790589855; cert-manager-istio csr-rhel9:1790223719; jetstack-cert manager-rhel9:1790589912; cluster-observability operator/perses-rhel9:1790854501; helm cli-4.3.0; multicluster engine/hive-rhel9:1790286311; multicluster-engine/cloudevents conductor-rhel9:1790143420; hypershift-addon rhel9-operator:1790132736; network-observability cli-rhel9:1789986279; rhacm2/multicluster-role assignment-rhel9:1790197542; rhc 0.2.5-12.el8_10 (el8) and 0.2.7-13.el9_8 (el9); rh-lightspeed-runtimes rhel9-operator:1790194122; rhoai/odh-kserve controller-rhel9:1789570408; rhoai/odh-model controller-rhel9:1790134001. Until patched, restrict who can complete a gRPC transport to xDS servers (network policy, mesh authorization, and prefer strict mTLS/ALTS so unauthenticated clients cannot reach the routing path). Rebuild and redeploy any in-house binaries that vendor google.golang.org/grpc below 1.82.2 / 1.83.2.

How to confirm the fix worked

Inventory running images and go.mod/go.sum (or RPM/NVR) for google.golang.org/grpc and confirm 1.82.2, 1.83.2, or the RHSA-2026:72884 package builds listed above. Confirm services that call xds.NewGRPCServer() were rebuilt and rolled out, not merely restarted on old binaries. After upgrade, process-level crash loops and unrecovered panics in xDS routing should stop; remaining listeners should reject or handle RPCs with a missing authority without process exit. Verify operator and addon pods no longer run the pre-fix NVRs and that deployment configs pin the patched channels.

Typical attack path

1. Identify a network-reachable gRPC-Go service constructed with xds.NewGRPCServer() (control-plane, operator, or mesh-facing listeners).
2. Complete HTTP/2 transport establishment; on insecure or ordinary TLS this needs no application identity, while mTLS/ALTS require valid client certificates or ALTS credentials.
3. Send an RPC that includes neither the :authority pseudo-header nor the Host header.
4. Trigger the unrecovered index-out-of-bounds panic in xDS RouteAndProcess, terminating the server process.
5. Repeat against restarted instances or remaining replicas to sustain the outage.

How to detect it

Hunt for already-occurred exploitation as sudden, unrecovered Go process deaths of xDS gRPC servers rather than as a malware implant. Review container, systemd, and platform logs for panic stack traces that mention xDS routing immediately after an inbound HTTP/2 or gRPC connection; correlate with replica restarts, CrashLoopBackOff, and OOM-unrelated exit codes on operator, cert-manager, observability, ACM, ACS, and model-serving control-plane pods. Packet or mesh access logs showing HTTP/2 HEADERS without :authority and without Host, followed within milliseconds by process termination, are the strongest behavioral signal. There are no named threat-actor tools or ransomware IOCs for this CVE; treat repeated crash-after-handshake patterns from the same source as likely probing. Exploit maturity is none, so absence of public PoC artifacts does not rule out simple custom clients.

• panic: runtime error: index out of range [0] with length 0
• internal/xds/server/routing.go
• google.golang.org/grpc/internal/xds/server/routing.go
• google.golang.org/grpc/internal/transport/http2_server.go
• internal/transport/http2_server.go
• xds.NewGRPCServer
• fatal error: fault
• SIGABRT: aborted

What your security team should do

• Patch first: upgrade gRPC-Go to 1.82.2 or 1.83.2 and apply RHSA-2026:72884 across Advanced Cluster Security, cert-manager, observability, multi-cluster, Helm, rhc, Lightspeed, and OpenShift AI images.
• Inventory every service that constructs servers with xds.NewGRPCServer() or vendors google.golang.org/grpc older than 1.82.2/1.83.2, including operators and sidecars not in the named product list.
• Reduce exposure of xDS gRPC ports with network policy, service mesh authorization, and private control-plane listeners so untrusted clients cannot complete transport setup.
• Prefer strict mTLS or ALTS on remaining listeners so only credentialed peers can reach routing; this does not fix the panic but removes unauthenticated crash paths.
• Watch for sudden gRPC-Go process exits and unrecovered panics during the 20-day window since publication, and treat repeat crashes after HTTP/2 handshake as suspected abuse until patches are confirmed.
• Rebuild custom binaries and CI caches that pin grpc-go, then re-scan images so downstream dependents cannot reintroduce the vulnerable module.