
PEACH
Un framework di isolamento del tenant
CVE-2026-84445 is a Denial of Service vulnerability in gRPC-Go (the Go language implementation of gRPC) affecting servers created with xds.NewGRPCServer(). A remote attacker can send a crafted HTTP/2 RPC request omitting both the :authority and Host headers, triggering an index-out-of-bounds panic in the xDS routing interceptor that terminates the entire server process. Affected versions are gRPC-Go prior to 1.82.2 and versions 1.83.0–1.83.1; the issue was disclosed on August 25, 2026 via GitHub Security Advisory GHSA-2v4p-qf9q-27wj and published to NVD on September 14, 2026. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Feedly).
The root cause is an improper validation of an array index (CWE-129) combined with an uncaught exception (CWE-248). In internal/transport/http2_server.go, the HTTP/2 server transport accepts incoming RPCs that carry neither the :authority pseudo-header nor the Host header — it only renames Host to :authority when Host is present, leaving :authority absent when both are missing. The xDS routing interceptor in internal/xds/server/routing.go (RouteAndProcess) then calls md.Get(":authority"), which returns an empty slice, and immediately indexes authority[0] under the assumption (documented in a code comment referencing gRPC proposal A41) that a valid authority is always present. Because the per-RPC goroutine has no recover() wrapping this code path, the resulting panic: runtime error: index out of range [0] with length 0 propagates and kills the entire server process. The vulnerability was originally discovered and reported to Google's OSS VRP by researcher winklemad before being filed publicly (GitHub Issue #9354, GitHub Advisory).
Successful exploitation causes a complete, immediate Denial of Service: the entire gRPC server process terminates rather than just the affected RPC goroutine. In insecure or standard TLS deployments, any unauthenticated remote attacker with network access can trigger this crash with a single malformed request, making the attack highly automatable. In strict mTLS or ALTS deployments, the attacker must first possess valid transport credentials, significantly reducing the attack surface. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue (GitHub Advisory, Feedly).
No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.685%, reflecting a low but non-negligible probability of exploitation in the near term. The attack is network-accessible, requires no privileges, no user interaction, and no special attack complexity in insecure/TLS deployments, making it highly automatable (NVD SSVC marks it as "Automatable: yes") (Feedly).
xds.NewGRPCServer() (xDS-enabled gRPC-Go servers). These are commonly found in Kubernetes/service-mesh environments using xDS control planes (e.g., Istio, Envoy-based setups). Check for gRPC-Go versions prior to 1.82.2 or between 1.83.0 and 1.83.1.:authority pseudo-header and the Host header. Standard HTTP/2 clients can be modified (e.g., using golang.org/x/net/http2 or h2c libraries) to send such a frame, bypassing the normal client-side enforcement of these headers.RouteAndProcess function in internal/xds/server/routing.go calls md.Get(":authority") (returning an empty slice) and then accesses authority[0], triggering a Go runtime panic. Since no recover() exists in the serving goroutine, the panic propagates and terminates the entire server process, achieving a complete Denial of Service (GitHub Issue #9354, GitHub Advisory).panic: runtime error: index out of range [0] with length 0 with a stack trace referencing internal/xds/server/routing.go (specifically RouteAndProcess) and xdsUnaryInterceptor or xdsStreamInterceptor.:authority and Host headers — detectable via packet capture or HTTP/2-aware network inspection tools.The fix is available in gRPC-Go versions 1.82.2 and 1.83.2; users on the 1.83.x branch should upgrade to 1.83.2, and users on the 1.82.x branch should upgrade to 1.82.2. The patch updates internal/transport/http2_server.go to reject requests missing both :authority and Host headers early (returning HTTP 400 / gRPC status Internal), and adds a defensive guard in internal/xds/server/routing.go. As a deployment-level workaround prior to patching, enforcing strict mTLS or ALTS at the transport layer significantly reduces the attack surface by requiring valid client credentials before the malformed RPC can reach the vulnerable interceptor. Downstream packages that embed gRPC-Go (e.g., CoreDNS, cert-manager, Vitess, InfluxDB, Telegraf, and various Azure Linux packages) should also be updated to versions that incorporate the patched gRPC-Go dependency (GitHub Advisory, GitHub PR #9365).
The vulnerability was originally reported to Google's OSS VRP (issue 551288012) by researcher winklemad, who noted it was classified as a product vulnerability not eligible for a reward under the project's tier, leading to a public GitHub issue filing. The gRPC-Go maintainers responded promptly, merging the fix and backporting it to the 1.82.x and 1.83.x branches on the same day (August 25, 2026). The issue attracted broad attention in the Go ecosystem, with numerous downstream projects (Kubernetes, Apache Pulsar, Forgejo, and others) rapidly opening dependency-bump PRs referencing the security fix (GitHub Issue #9354, GitHub PR #9365).
Correggi la disponibilità tra le principali distribuzioni Linux e le loro versioni.
bookworm
golang-google-grpc
sid
golang-google-grpc
trixie
golang-google-grpc
Fonte: Questo report è stato generato utilizzando l'intelligenza artificiale
Valutazione gratuita delle vulnerabilità
Valuta le tue pratiche di sicurezza cloud in 9 domini di sicurezza per confrontare il tuo livello di rischio e identificare le lacune nelle tue difese.
Richiedi una demo personalizzata
"La migliore esperienza utente che abbia mai visto offre piena visibilità ai carichi di lavoro cloud."
"Wiz fornisce un unico pannello di controllo per vedere cosa sta succedendo nei nostri ambienti cloud."
"Sappiamo che se Wiz identifica qualcosa come critico, in realtà lo è."