CVE-2026-33186 in grpc-go
Summary
by MITRE • 03/21/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/20/2026
The vulnerability described in CVE-2026-33186 affects the gRPC-Go implementation, specifically exposing an authorization bypass issue stemming from inadequate validation of HTTP/2 pseudo-header `:path` values. This flaw exists in versions prior to 1.79.3 and allows malicious actors to circumvent access control policies by crafting requests with non-canonical path formats. The root cause lies in how gRPC-Go servers handle routing logic for incoming requests, where the system accepts paths without leading slashes such as `Service/Method` rather than the expected canonical format `/Service/Method`. Although the server correctly routes these malformed requests to their intended handlers, the authorization interceptors operate on the raw path string rather than a normalized version, creating a discrepancy that enables bypass attacks. This vulnerability aligns with CWE-284, which addresses improper access control, and represents a classic case of authorization logic flaw in network services.
The technical exploitation of this vulnerability occurs through direct manipulation of HTTP/2 frames, where attackers can send malformed `:path` headers to the gRPC server. When a request arrives with a path lacking the leading slash, the gRPC server processes it through its routing mechanism, which successfully identifies and directs the request to the appropriate handler function. However, during the authorization phase, interceptors such as those in `google.golang.org/grpc/authz` evaluate the request against security policies using the raw, unnormalized path string. Since most security policies define deny rules using canonical paths beginning with `/`, these rules fail to match the malformed input, allowing unauthorized access to proceed if a fallback allow rule exists in the policy configuration. This design flaw creates a window where authorization decisions can be circumvented purely through syntactic manipulation of the HTTP/2 protocol layer. The vulnerability is particularly concerning because it operates at the protocol level, bypassing higher-level security controls and relying on the fundamental trust in path validation within the server implementation.
The operational impact of this vulnerability extends beyond simple unauthorized access, potentially enabling attackers to exploit service misconfigurations or weak access control policies to gain elevated privileges within gRPC-based systems. Servers utilizing the official RBAC implementation or custom interceptors that depend on `info.FullMethod` or `grpc.Method(ctx)` are at risk, especially when these systems implement security policies with specific deny rules for canonical paths while maintaining a default allow behavior. The consequence is that attackers can craft requests that match their intended service methods but bypass authorization checks due to path normalization inconsistencies. This vulnerability affects systems where gRPC servers are deployed with path-based access controls, particularly in microservices architectures where fine-grained authorization is critical for maintaining security boundaries. The exploitation requires minimal network-level access and can be performed using standard HTTP/2 frame manipulation tools, making it a significant concern for organizations relying on gRPC-Go for service communication.
The fix implemented in gRPC-Go version 1.79.3 addresses this vulnerability by enforcing strict validation of the `:path` pseudo-header at the protocol level. Any request containing a `:path` that does not begin with a leading slash is now immediately rejected with a `codes.Unimplemented` error before reaching any authorization interceptors or service handlers. This defensive programming approach ensures that malformed requests are terminated early in the processing pipeline, preventing the authorization bypass from occurring. Organizations should prioritize upgrading to version 1.79.3 or later as the primary mitigation strategy, as this resolves the core issue at its source. Additional mitigations include implementing validating interceptors that normalize path formats before authorization checks, applying infrastructure-level normalization at load balancers or reverse proxies, and hardening security policies to account for potential path variations. From an ATT&CK perspective, this vulnerability relates to privilege escalation and defense evasion techniques, as it allows attackers to bypass authorization controls that would normally prevent access to restricted services. The vulnerability also demonstrates the importance of input validation and consistent security policy enforcement across protocol layers, reinforcing the principle that security controls must be robust against syntactic manipulation of protocol elements.