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.
The gRPC-Go server accepted requests where the HTTP/2 pseudo-header `:path` did not contain the required leading slash (e.g., `Service/Method` instead of `/Service/Method`). The server correctly routed such requests to the appropriate handler; however, authorization interceptors (including the official `grpc/authz` package) compared the raw, unnormalized path against rules defined for canonical paths (starting with `/`). As a result, "deny" rules did not match the incoming request, and if the policy contained a default "allow" rule, the request was allowed, bypassing access control. The attack is possible through direct transmission of raw HTTP/2 frames with an intentionally malformed `:path` header to the gRPC server.
An attacker without any permissions can bypass path-based authorization rules (including RBAC), gaining unauthorized access to protected gRPC methods and potentially modifying data or reading sensitive information (high impact on confidentiality and integrity).
gRPC-Go should be updated to version 1.79.3 or later — the fix rejects all requests with a `:path` header not starting with a slash by returning an `codes.Unimplemented` error. As temporary workarounds (until updating), the following can be applied: a validating interceptor verifying path format, path normalization at the infrastructure level (e.g., proxy/load balancer), or strengthening the authorization policy by removing the default "allow" rule.
The gRPC-Go library (google.golang.org/grpc) in versions earlier than 1.79.3. The vulnerability affects servers using path-based authorization interceptors (e.g., the official `google.golang.org/grpc/authz` package or custom interceptors using `info.FullMethod` / `grpc.Method(ctx)`), which have a policy with "deny" rules for canonical paths and a default "allow" rule.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NGrpc
APPGrpc< 1.79.3
Related vulnerabilities
Heap-based buffer overflow w Google gRPC — zapis poza granicami pamięci
Google gRPC — zapis poza granicami pamięci przez use-after-free w grpc_call_destroy
Przepełnienie bufora sterty (heap buffer overflow) w Google gRPC — zapis poza granicami
Zapis poza granicami bufora w Google gRPC (gpr_free)
Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms ...