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 speci
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
:pathpseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the:pathomitted the mandatory leading slash (e.g.,Service/Methodinstead of/Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the officialgrpc/authzpackage) 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 ingoogle.golang.org/grpc/authzor custom interceptors relying oninfo.FullMethodorgrpc.Method(ctx); AND that have a security policy contains speci