GHSA-2v4p-qf9q-27wj: gRPC-Go: Denial of Service (DoS) via crash due to missing `:authority` and `Host` headers in the xDS servers

Published Sep 8, 2026
·
Updated

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.

— OSV

Affected Software

3 affected componentsFixes available
go/google.golang.org/grpc>=1.84.0-dev<1.85.0-dev.0.20260825072537-93e31b48545e
1.85.0-dev.0.20260825072537-93e31b48545e
go/google.golang.org/grpc>=1.83.0<1.83.2
1.83.2
go/google.golang.org/grpc<1.82.2
1.82.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/google.golang.org/grpc to a version that resolves this vulnerability.

    Fixed in 1.85.0-dev.0.20260825072537-93e31b48545e
  2. Upgrade

    Upgrade go/google.golang.org/grpc to a version that resolves this vulnerability.

    Fixed in 1.83.2
  3. Upgrade

    Upgrade go/google.golang.org/grpc to a version that resolves this vulnerability.

    Fixed in 1.82.2
  4. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 1.83.2
  5. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 1.82.2
  6. Compensating control

    Ensure strict transport-level authentication at the network edge or transport layer (e.g., require valid client certificates via mTLS, or otherwise enforce that transport credentials are required) so an unauthenticated attacker cannot successfully establish the transport connection needed to reach the xDS interceptor panic.

  7. Compensating control

    If applicable to your deployment, prevent insecure/plaintext connections and standard credentials scenarios where client certs are not checked, since unauthenticated remote attackers can trigger the crash when they can establish a transport connection.

Event History

Sep 8, 2026
Advisory Published
via GitHub·09:21 PM
Data Sourced
via GitHub·09:21 PM
DescriptionWeaknessAffected Software
Sep 14, 2026
CVE Published
via OSV·04:11 PM
Data Sourced
via OSV·04:11 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which gRPC-Go deployments are exposed to this crash?

The affected configuration is a server created with xds.NewGRPCServer(). These servers install the xDS routing interceptor for every RPC, where the missing-authority condition is processed.

2

Can an unauthenticated remote attacker trigger the denial of service?

Yes, if the server permits plaintext connections or uses standard TLS credentials that do not check client certificates. In those configurations, an unauthenticated remote attacker can complete the connection setup and send the crafted request.

3

How do mTLS or ALTS affect exploitability?

The malformed request reaches the vulnerable interceptor only after the transport-credentials handshake and HTTP/2 connection establishment succeed. Therefore, mTLS or ALTS requirements must be satisfied before an attacker can reach the crash condition.

4

What request condition causes the server to terminate?

A request that contains neither an HTTP/2 :authority header nor a Host header can cause the xDS routing interceptor to index an empty authority list. The resulting panic is not recovered in the per-RPC goroutine, so it terminates the server process.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203