CVE-2026-33186: gRPC-Go has an authorization bypass via missing leading slash in :path
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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-33186 lets certain vulnerable gRPC-Go servers route malformed requests to protected methods while path-based deny rules fail to match. The risk is highest for services that deny specific methods but allow everything else. The vendor fix is gRPC-Go 1.79.3.
Executive priority
Treat as urgent for internet-facing or partner-facing gRPC services with path-based authorization. Prioritize upgrade and policy review because the issue can bypass intended access controls without credentials.
Technical view
Before gRPC-Go 1.79.3, servers accepted HTTP/2 :path values missing the leading slash. Routing still reached the intended handler, but authorization interceptors evaluated the raw non-canonical path, so canonical deny rules could be bypassed when a fallback allow policy existed.
Likely exposure
Exposure is limited to grpc-go servers before 1.79.3 using path-based authorization with specific canonical deny rules and default-allow behavior.
Exploitation context
The bundle marks KEV false and provides no evidence of active exploitation. Exploitation requires sending raw HTTP/2 frames with malformed :path values directly to the gRPC server.
Researcher notes
Affected logic includes official grpc/authz RBAC and custom interceptors relying on info.FullMethod or grpc.Method(ctx). The 1.79.3 fix rejects paths without a leading slash with codes.Unimplemented before handlers or authorization logic receive them.
Mitigation direction
Upgrade grpc-go to version 1.79.3 or later.
Add a validating interceptor that rejects non-canonical method paths.
Use infrastructure-level normalization or rejection where appropriate.
Harden authorization policies to avoid unsafe fallback allow behavior.
Check vendor advisories for downstream Red Hat package fixes.
Validation and detection
Inventory Go services using google.golang.org/grpc.
Confirm grpc-go dependency versions are 1.79.3 or later.
Review authorization interceptors using path or method names.
Identify policies with canonical deny rules and default allow behavior.
Verify non-canonical paths are rejected before authorization handlers run.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-285: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.