CVE-2026-33186

What it actually does

CVE-2026-33186 is an authorization bypass in gRPC-Go servers before version 1.79.3. The server accepted malformed HTTP/2 requests whose `:path` pseudo-header omitted the required leading slash, such as `Service/Method` instead of `/Service/Method`. Routing still resolved the request to the intended gRPC handler, but authorization logic that evaluated the raw method path could compare the malformed value against policy rules written for canonical paths. In deployments using path-based deny rules with a default or fallback allow rule, the deny rule could fail to match and the protected RPC method could be invoked without the intended authorization decision. This primarily affects servers using `google.golang.org/grpc/authz` or custom interceptors that rely on `info.FullMethod` or `grpc.Method(ctx)` for method-based access control.

Why it matters to the business

An unauthenticated network attacker may be able to access gRPC methods that an organization explicitly intended to block, potentially exposing sensitive data or enabling unauthorized changes through internal service APIs. The CVSS score is critical at 9.1 because exploitation requires network access only, no credentials, and no user interaction, although exploitation depends on a specific authorization-policy pattern: canonical deny rules combined with a permissive fallback allow. EPSS is currently low and flat, and the vulnerability is not listed in CISA KEV or known ransomware use, but gRPC-Go is widely used in service-to-service architectures, so affected software may be embedded in many downstream products and internal services.

How an attack unfolds

An attacker first identifies a reachable gRPC-Go endpoint and determines or guesses the fully qualified service and method names. Instead of using a normal gRPC client request with a canonical `:path` such as `/package.Service/Method`, the attacker sends raw HTTP/2 frames directly to the service with a malformed `:path` value such as `package.Service/Method`. In vulnerable versions, gRPC-Go still routes the request to the correct RPC handler, but the authorization interceptor evaluates the malformed path string. If the policy contains a deny rule for the canonical method path and then allows unmatched requests by default, the malformed path does not match the deny rule and the fallback allow rule permits the request. The protected handler then processes the call as though authorization succeeded. In fixed versions, requests whose `:path` does not start with `/` are rejected before reaching authorization interceptors or application handlers.

How to fix it

Upgrade all affected gRPC-Go dependencies to `google.golang.org/grpc` version 1.79.3 or later. The fixed version rejects requests whose HTTP/2 `:path` pseudo-header does not begin with `/`, returning `codes.Unimplemented` before authorization interceptors or handlers are reached. If immediate upgrade is not possible, add a high-priority validating interceptor that rejects any request method/path not beginning with `/` before RBAC or custom authorization logic executes. Also harden authorization policy by avoiding permissive fallback allow behavior for sensitive services; prefer default deny with explicit allow rules. Where feasible, configure edge proxies, service meshes, or HTTP/2 gateways to reject or normalize non-canonical gRPC paths, but do not rely on infrastructure normalization as the only fix because direct backend access may still exist. Review custom interceptors using `info.FullMethod`, `grpc.Method(ctx)`, or raw path-derived values to ensure they canonicalize and validate paths before policy evaluation.

How to confirm the fix worked

Confirm that builds use `google.golang.org/grpc` version 1.79.3 or later through dependency manifests, lockfiles, SBOMs, and compiled binary dependency inspection where available. For Go modules, run dependency checks such as `go list -m all | grep google.golang.org/grpc` and verify no vulnerable version is selected through indirect dependencies or vendored code. Functionally test a non-production instance by sending an HTTP/2 gRPC request with a `:path` value that omits the leading slash; a fixed or properly mitigated server should reject the request before handler execution, typically with `codes.Unimplemented` or an equivalent rejection, and the protected handler should not run. Review authorization configurations for deny rules written as canonical paths such as `/package.Service/Method` combined with fallback allow behavior. Validate that logs or telemetry capture malformed method paths, rejected non-canonical paths, and authorization decisions so future attempts can be detected.

Typical attack path

1. Discover or gain network reachability to a gRPC-Go server endpoint.
2. Enumerate or infer available gRPC service and method names from reflection, client artifacts, documentation, traffic observation, or guessable naming.
3. Identify or assume that access control is implemented with path-based authorization rules that deny specific canonical method paths and allow other requests by default.
4. Craft a raw HTTP/2 gRPC request where the `:path` pseudo-header omits the leading slash, for example `package.Service/Method` instead of `/package.Service/Method`.
5. Send the malformed request directly to the gRPC-Go server, bypassing clients or proxies that would normally generate canonical paths.
6. Rely on vulnerable routing behavior to dispatch the request to the intended handler while causing the authorization rule comparison to miss the canonical deny rule.
7. Invoke the protected RPC method and retrieve data or perform unauthorized operations within the method’s existing application privileges.

How to detect it

Look for evidence of raw HTTP/2 gRPC requests whose `:path` pseudo-header or logged method value does not start with `/` but still resembles a gRPC method name, such as `package.Service/Method`. Useful sources include gRPC server access logs, interceptor logs, authz/RBAC decision logs, reverse proxy and service mesh logs, HTTP/2 gateway telemetry, application audit logs for sensitive RPC method execution, packet captures, and endpoint telemetry around custom test or exploitation tools. Focus on authorization allow decisions for non-canonical paths, successful handler execution following malformed method names, and requests that did not pass through expected gateways. Because many gRPC deployments do not log HTTP/2 pseudo-headers by default, absence of evidence is not proof of no exploitation; enable temporary verbose interceptor logging if needed. For forensic review, correlate unexpected successful calls to sensitive RPC methods with unusual clients, direct-to-backend connections, HTTP/2 traffic not generated by approved clients, and method/path values missing the leading slash. There are no named threat actors or known exploitation campaigns reported in the provided data, and the vulnerability is not currently in CISA KEV.

• `:path: Service/Method`
• `:path=Service/Method`
• `path=Service/Method`
• `grpc.method=Service/Method`
• `method=Service/Method`
• `full_method=Service/Method`
• `FullMethod=Service/Method`
• `grpc.Method(ctx)=Service/Method`
• `authorization allowed` AND `Service/Method`
• `authz allow` AND `Service/Method`
• `rbac allow` AND `Service/Method`
• `non-canonical path`
• `malformed :path`
• `path does not start with /`
• `missing leading slash`
• `codes.Unimplemented` AND `:path`
• `/package.Service/Method`
• `package.Service/Method`

What your security team should do

• Prioritize upgrading gRPC-Go to version 1.79.3 or later for any internet-facing, partner-facing, or cross-trust-boundary gRPC services.
• Inventory services and products using `google.golang.org/grpc`, including indirect and vendored dependencies in Go applications.
• Identify services using `google.golang.org/grpc/authz` or custom path-based authorization interceptors that reference `info.FullMethod` or `grpc.Method(ctx)`.
• Review RBAC policies for canonical deny rules with fallback allow behavior; convert sensitive authorization models to default deny with explicit allow rules.
• Add temporary path validation interceptors to reject method paths that do not begin with `/` where upgrades cannot be completed immediately.
• Restrict direct network access to gRPC backends so attackers cannot bypass proxies, gateways, or service mesh controls that may normalize malformed paths.
• Add detections for malformed gRPC method paths without a leading slash and for authorization allow decisions on non-canonical paths.
• Perform targeted log review for the period since exposure began, especially on high-value services with sensitive RPC methods.
• Monitor upstream advisories and downstream vendor releases for products embedding vulnerable gRPC-Go versions.