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.
Metrics
Affected Vendors & Products
Advisories
| Source | ID | Title |
|---|---|---|
 Github GHSA |
GHSA-p77j-4mvh-x3m3 | gRPC-Go has an authorization bypass via missing leading slash in :path |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Wed, 12 Aug 2026 12:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Fri, 10 Apr 2026 21:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Grpc grpc
|
|
| CPEs | cpe:2.3:a:grpc:grpc:*:*:*:*:*:go:*:* | |
| Vendors & Products |
Grpc grpc
|
Tue, 24 Mar 2026 18:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Mon, 23 Mar 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-551 | |
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
Mon, 23 Mar 2026 10:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Grpc
Grpc grpc-go |
|
| Vendors & Products |
Grpc
Grpc grpc-go |
Fri, 20 Mar 2026 22:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | gRPC-Go has an authorization bypass via missing leading slash in :path | |
| Weaknesses | CWE-285 | |
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-08-12T12:04:46.409Z
Reserved: 2026-03-17T22:16:36.720Z
Link: CVE-2026-33186
Vulnrichment
Updated: 2026-08-12T12:04:46.409Z
NVD
Status : Modified
Published: 2026-03-20T23:16:45.180
Modified: 2026-08-12T12:18:38.920
Link: CVE-2026-33186
Redhat
OpenCVE Enrichment
Updated: 2026-07-31T18:15:04Z