CVE-2026-33186
CriticalCVSS 9.1Exploitation Probability (EPSS)
Elevated risk74th percentile - higher than 74% of all known CVEs
Summary
A vulnerability in gRPC-Go before version 1.79.3 allows authorization bypass due to improper validation of the HTTP/2 `:path` pseudo-header. The server accepted requests with a missing leading slash (e.g., `Service/Method` instead of `/Service/Method`), causing deny rules based on canonical paths to be ineffective. An attacker can exploit this to bypass security policies if a fallback allow rule exists.
Risk Assessment
The risk involves unauthorized access to protected gRPC methods, potentially leading to data confidentiality or integrity breaches. Organizations using gRPC-Go with path-based authorization interceptors (e.g., `grpc/authz`) are vulnerable if their policy includes deny rules for canonical paths and allows other requests by default.
Recommendation
Immediately upgrade to version 1.79.3 or later. If upgrading is not possible, use validating interceptors, infrastructure-level normalization, or policy hardening to reject requests with non-canonical paths.
Other vulnerabilities in gRPC-Go
See all- GHSA-hrxh-6v49-42gfHigh
Multiple security vulnerabilities have been identified in the grpc-go library affecting the xDS RBAC authorization engine and the HTTP/2 transport server implementation. These vulnerabilities could lead to authorization bypass (Fail-Open) during rule translation.
- CVE-2026-84445High
gRPC-Go prior to 1.82.2 and 1.83.2 allows servers created with xds.NewGRPCServer() to accept an RPC lacking both the :authority and Host headers. RouteAndProcess assumes an authority value exists and indexes an empty slice, causing an index-out-of-bounds panic that terminates the entire server process.
- CVE-2026-84304High
gRPC-Go prior to 1.83.1 stores each fragmented HTTP/2 DATA frame as a separate recvMsg, so millions of one-byte frames can consume disproportionate heap memory. An unauthenticated remote attacker can use concurrent multiplexed streams to exhaust process memory and cause a runtime panic or OOM termination. Receive-buffer compaction is enabled by default and can be controlled with GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION. Fixed in 1.83.1.
- CVE-2026-84303Medium
gRPC-Go prior to version 1.83.1 contains a vulnerability in the xDS RBAC HTTP filter where header matcher names are not lowercased even though incoming metadata keys are lowercase. A DENY policy using mixed-case names such as X-Role or User-Agent does not match and fails open, allowing requests that should be rejected. The same case mismatch permits :Scheme or Grpc-Status to evade gRFC A41 validation and prevents Host from being rewritten to :authority. This issue is fixed in version 1.83.1.
Original NVD description (English source)
gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS