CVE-2026-33186

Google · gRPC-Go

gRPC-Go versions prior to 1.79.3 are vulnerable to an authorization bypass due to improper input validation of HTTP/2 :path pseudo-headers, allowing attackers to circumvent path-based security rules.

Executive summary

An unauthenticated attacker can bypass authorization interceptors in gRPC-Go servers by sending malformed HTTP/2 frames, potentially gaining unauthorized access to sensitive service methods.

Vulnerability

This is an authorization bypass vulnerability caused by improper input validation of the HTTP/2 :path pseudo-header. An unauthenticated attacker can send raw HTTP/2 frames with non-canonical paths (omitting the leading slash) to bypass "deny" rules in authorization interceptors like grpc/authz that expect canonical path strings.

Business impact

A successful exploit allows an attacker to bypass security policies intended to restrict access to specific gRPC methods. This could lead to unauthorized data access, execution of restricted functions, and a total compromise of the application's security model. Given the CVSS score of 9.1, this vulnerability poses a critical risk to any infrastructure relying on gRPC-Go for secure communication and RBAC enforcement.

Remediation

Immediate Action: Upgrade gRPC-Go to version 1.79.3 or later immediately to ensure the server rejects malformed :path headers with a codes.Unimplemented error.

Proactive Monitoring: Review gRPC server logs for codes.Unimplemented errors or anomalous traffic patterns involving malformed HTTP/2 headers.

Compensating Controls: Implement infrastructure-level normalization at the reverse proxy or load balancer level to ensure all incoming :path headers conform to canonical formats before reaching the gRPC server.

Exploitation status

Public Exploit Available: false

Analyst recommendation

The severity of this authorization bypass cannot be overstated for organizations utilizing gRPC-Go with path-based authorization. It is highly recommended to prioritize the update to version 1.79.3. If immediate patching is not feasible, hardening security policies to avoid "allow by default" fallbacks is a necessary interim step.