gRPC-Go Authorization Bypass via Non-Canonical :path Header Validation

Vulnerability Description

This is an Authorization Bypass vulnerability caused by Improper Input Validation in gRPC-Go's request routing and authorization interception pipeline. The root cause is a logic gap where the gRPC server accepts and routes malformed HTTP/2 requests with non-canonical :path pseudo-headers (e.g., Service/Method instead of /Service/Method), but authorization interceptors evaluate the raw, unvalidated path string rather than the canonical form. This mismatch between routing normalization and security policy evaluation allows deny rules to fail pattern matching.

Proof-of-Concept Significance

This PoC demonstrates that an attacker capable of crafting raw HTTP/2 frames can directly violate security policies by sending requests with structurally invalid but processable :path headers. The vulnerability is reliable because it exploits a fundamental logic error in path handling rather than a race condition or timing issue. The precondition is straightforward: gRPC-Go servers using the official grpc/authz RBAC module or custom interceptors that depend on info.FullMethod or grpc.Method(ctx), combined with security policies that deny specific canonical paths but allow others by default. This is a common defensive pattern.

Detection Guidance

Log Indicators:

• Monitor HTTP/2 :path headers in grpc.dev/grpc-go request logs for paths lacking leading slashes
• Alert on authorization interceptor logs showing mismatches between raw FullMethod strings and canonical paths
• Look for requests matching patterns like ^[A-Za-z]/ (no leading slash) in gRPC server access logs
• Track failed authorization checks immediately preceding successful request processing

Signatures:

• HTTP/2 frame inspection: Identify HEADERS frames with :path pseudo-header regex ^[^/] (non-slash start)
• YARA: { strings: { $path = /:path:\s+[^/]/ } condition: $path }

Mitigation Steps

Immediate Actions:

1. Upgrade gRPC-Go: Update to patched versions (announced in the advisory) that enforce leading-slash validation before routing
2. Validate Paths in Interceptors: Implement custom validation in authorization interceptors to canonicalize paths before policy evaluation: if !strings.HasPrefix(path, "/") { path = "/" + path }
3. Reject Malformed Requests: Configure gRPC servers to reject HTTP/2 requests with non-canonical :path headers at the transport layer
4. Policy Review: Audit existing RBAC policies to ensure they include explicit deny-all fallback rules rather than implicit allows

Risk Assessment

Exploitation Likelihood: High in environments where (a) gRPC services enforce fine-grained path-based access control and (b) attackers have network access to send crafted HTTP/2 frames. Exploitation does not require authentication bypass; it is purely a logic error in policy evaluation.

Threat Actor Interest: This is attractive to attackers targeting microservices architectures, internal gRPC APIs, and zero-trust deployments. The attack surface includes any gRPC-Go service exposed to untrusted networks or compromised internal clients.