Older versions of the Go gRPC library accept HTTP/2 requests whose :path pseudo‑header lacks the required leading slash. The server routes the non‑canonical path to the intended handler, but authorization interceptors evaluate the raw path. Because deny rules are defined with canonical paths starting with \/, these rules do not match, allowing the request to slip through when the policy falls back to a generic allow. The result is a direct bypass of application‑level access controls, enabling an attacker to invoke privileged methods and leak or alter data. This issue maps to authorization weaknesses (CWE‑285) and path manipulation (CWE‑551).

Any service built with gRPC-Go prior to release 1.79.3 is affected, especially servers that employ path‑based authorization through the official \/google.golang.org/grpc/authz package or custom interceptors that rely on the raw \/info.FullMethod values. The vulnerability exists in the server routing component, so it applies to all deployments of the Go gRPC server that do not validate the :path header before policy enforcement.

The CVSS score of 9.1 indicates critical severity; EPSS is below 1% and the vulnerability is not listed in the CISA KEV catalog, suggesting a modest public exploitation probability. Exploitation requires the attacker to be able to send raw HTTP/2 frames directly to the gRPC endpoint, meaning the service must be reachable at the transport level. Once the request reaches the server, the missing slash bypass can be triggered automatically, and the policy rules cannot block the call. Attackers with network access to the service can therefore exploit the flaw to compromise confidentiality or integrity of the data handled by the over‑privileged methods. The risk is elevated for services without a stricter access control policy or protecting the gRPC port behind a firewall.