One Character to Rule Them All: How a Missing Slash Bypasses gRPC-Go Security (CVE-2026-33186)
Ddos 
A significant security flaw has been identified in gRPC-Go, the high-performance Go implementation of the gRPC framework. The vulnerability, tracked as CVE-2026-33186, carries a critical CVSS score of 9.1 and allows attackers to bypass security policies by simply omitting a single character: the leading slash in a request path.
At its core, the issue is an Authorization Bypass (CWE-285) fueled by Improper Input Validation (CWE-20) of the HTTP/2 :path pseudo-header.
In standard gRPC communication, a request path should follow a canonical format, such as /Service/Method. However, researchers discovered that the gRPC-Go server was “too lenient” in its routing logic. It would successfully accept and route requests even if they lacked the mandatory leading slash (e.g., Service/Method).
The danger arises because while the server routes the request correctly, authorization interceptors—including the official grpc/authz package—evaluate the raw, non-canonical string.
If a security policy defines a “deny” rule starting with a slash (the canonical path), it fails to match the malformed incoming request. If the system then falls back to a “default allow” rule, the attacker is granted unauthorized access.
Your gRPC-Go server is vulnerable if it meets two specific conditions:
- Path-Based Auth: You use path-based authorization interceptors like the official RBAC implementation.
- Specific Deny Rules: Your security policy specifically denies certain paths but allows others by default.
An attacker capable of sending raw HTTP/2 frames with malformed :path headers can exploit this flaw directly.
The good news is that a patch is available. The fix ensures that any request with a path not starting with a leading slash is immediately rejected with an Unimplemented error, stopping it before it ever reaches your security logic.
Users should upgrade to v1.79.3 or the latest master branch immediately.
If an immediate upgrade isn’t possible, you can mitigate the risk using these methods:
- Validating Interceptor: Add a custom “outermost” interceptor to your server chain. This interceptor should check if the FullMethod starts with a / and reject it if it does not.
- Infrastructure Normalization: Configure your reverse proxy or load balancer (like Envoy or NGINX) to enforce strict HTTP/2 compliance and reject paths without leading slashes.
- Policy Hardening: Switch your authorization posture to “default deny”. By explicitly listing only allowed paths and denying everything else, you neutralize the bypass.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
