# gRPC-Go has an authorization bypass via missing leading slash in :path

gRPC-Go routed requests whose HTTP/2 :path lacked a leading slash, so authz deny rules on canonical paths failed to match, bypassing authorization.

- Payout: Research
- Severity: critical
- Program: gRPC-Go
- Found by: MariuszMaik
- Disclosed: 2026-03-18
- CVE: CVE-2026-33186
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-p77j-4mvh-x3m3
- Library page: http://bugbountylibrary.com/r/ghsa%3AGHSA-p77j-4mvh-x3m3
- Tags: area:web domain:api impact:privesc kind:research platform:ghsa sev:critical tech:go tech:grpc technique:parser-differential vuln:access-control vuln:auth-bypass

**Target:** gRPC server HTTP/2 :path pseudo-header and path-based authz interceptors
**Root cause:** Server routing accepted non-canonical :path values without a leading slash and dispatched them to handlers, while authorization interceptors matched deny rules against the raw unnormalized path string.
**Steps:**
1. Configure a gRPC-Go server (<1.79.3) with grpc/authz policy containing a deny rule for `/Service/Method` and a fallback allow.
2. Send a raw HTTP/2 request with `:path: Service/Method` (no leading slash).
3. Server routes to the correct handler; authz interceptor sees `Service/Method`, deny rule fails to match, fallback allow grants access.
**How found:** Reporter noticed routing logic was lenient about the mandatory leading slash and that authz interceptors evaluate the raw info.FullMethod string, creating a mismatch between routing and policy evaluation.
**Exploitation:** Attacker with raw HTTP/2 frame control sends requests with slashless :path to reach handlers protected by deny rules, gaining access to methods the policy intended to block.
**Insight:** When a framework routes on one representation of a path but authorizes on another, look for normalization gaps: try omitting the leading slash, adding duplicate slashes, or percent-encoding to make the authz matcher and router disagree.