CVE-2026-33186
Authorization Bypass in gRPC-Go Due to HTTP/2 Path Validation Flaw
Publication date: 2026-03-20
Last updated on: 2026-04-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| grpc | grpc | to 1.79.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-285 | The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects gRPC-Go versions prior to 1.79.3 and is an authorization bypass caused by improper input validation of the HTTP/2 ':path' pseudo-header.
The gRPC-Go server was too lenient in routing requests where the ':path' header omitted the mandatory leading slash (for example, 'Service/Method' instead of '/Service/Method'). Although the server routed these requests correctly, authorization interceptors evaluated the raw, non-canonical path string without the leading slash.
As a result, 'deny' rules defined using canonical paths (which start with '/') failed to match these requests, allowing them to bypass authorization policies if a fallback 'allow' rule was present.
An attacker who can send raw HTTP/2 frames with malformed ':path' headers can exploit this to bypass authorization checks.
The issue was fixed in version 1.79.3 by rejecting any request with a ':path' that does not start with a leading slash, preventing such requests from reaching authorization interceptors or handlers.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to bypass authorization controls on a gRPC-Go server that uses path-based authorization interceptors with specific 'deny' rules for canonical paths.
If your security policy includes 'deny' rules for certain paths but has a fallback 'allow' rule, an attacker could send specially crafted requests with malformed ':path' headers to access resources or perform actions that should be denied.
This could lead to unauthorized access to sensitive services or methods, potentially exposing confidential data or allowing unauthorized operations.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
I don't know
What immediate steps should I take to mitigate this vulnerability?
The most secure and recommended mitigation is to upgrade gRPC-Go to version 1.79.3 or later, where the vulnerability is fixed by rejecting any request with a :path header that does not start with a leading slash.
If upgrading immediately is not possible, you can mitigate the vulnerability by:
- Using a validating interceptor that enforces the presence of a leading slash in the :path header.
- Applying infrastructure-level normalization to ensure that incoming requests have canonical :path headers starting with a slash.
- Hardening your authorization policies to avoid relying on fallback "allow" rules and to explicitly deny non-canonical paths.