The gRPC-Go Auth Bypass Hiding in Your Dependency Tree: CVE-2026-33186

Most authorization bugs are loud: a missing check, an admin route with no guard. CVE-2026-33186 is the quieter kind, the sort that passes code review because the check is right there in the code and looks correct. The flaw is not in your policy. It is in a single character that decides whether your policy is consulted at all.

It is rated CVSS 9.1 (critical), it lives in google.golang.org/grpc, and the reason it matters for you specifically is that gRPC-Go is rarely a dependency you chose on purpose. It rides in transitively under Kubernetes clients, observability agents, service meshes, cloud SDKs, and dozens of other Go modules. You can be exposed without a single line of gRPC in your own code. This post is what the bug is, who it actually affects, and the commands to check your own tree in a couple of minutes.

What the bug is

gRPC runs over HTTP/2, and every call carries a :path pseudo-header that names the method, canonically with a leading slash: /myapp.Orders/Cancel.

The vulnerable gRPC-Go server was too forgiving. It also accepted the same path without the leading slash, myapp.Orders/Cancel, and still routed it to the correct handler. On its own that is a harmless bit of leniency. It becomes a security hole the moment authorization runs as an interceptor that matches on the path string, which is exactly how the official grpc/authz package and most hand-rolled interceptors work.

Here is the sequence:

1. A request arrives with :path of myapp.Orders/Cancel (no leading slash).
2. The authorization interceptor evaluates its rules against that raw string. A deny rule written canonically as /myapp.Orders/Cancel does not match, because myapp.Orders/Cancel is a different string.
3. If the policy has a permissive fallback (a catch-all "allow" when nothing else matched, a common shape), the request is allowed.
4. The router, being lenient, sends it to the real Cancel handler anyway.

The deny rule was correct. It just never got a chance to fire, because the string it was asked about was not the string it was written for. This is a textbook canonicalization bug (CWE-285, improper authorization), and its blast radius is "authorization, silently skipped."

The CVSS vector tells the story: network attackable, no privileges, no user interaction, high confidentiality and integrity impact. The one piece of good news is no availability impact, this leaks and mutates, it does not crash.

Who is actually affected

Not every gRPC-Go server. You are exposed if all of these hold:

• You run a gRPC-Go server on a version before 1.79.3.
• You enforce authorization in an interceptor that keys on the method path, either google.golang.org/grpc/authz or a custom interceptor that reads info.FullMethod.
• Your policy relies on deny rules with a permissive fallback, rather than default-deny with explicit allows.

If your authorization is default-deny (nothing is allowed unless a rule explicitly permits it), the non-canonical path fails to match your allow rules too, so the request is rejected and you are not exploitable through this path. That is worth sitting with: the teams hit hardest here are the ones using blocklist-style policies, and the teams who modelled authorization as a strict allowlist mostly dodged it. Default-deny earns its keep again.

Find it in your own tree

The hard part is not fixing this, it is discovering that you ship it at all, since it is almost always transitive. Three checks, fastest first.

List every version of gRPC-Go anywhere in your module graph:

go list -m all | grep google.golang.org/grpc

If anything there is below 1.79.3, keep going. To see why it is in your build (which of your direct dependencies drags it in), ask:

go mod why -m google.golang.org/grpc

That prints the import chain, which tells you whether you can bump it directly or need to wait on (or prod) an upstream dependency to update.

Best of all, let the official vulnerability scanner connect the CVE to your actual code paths:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

govulncheck is the one to trust, because it does call-graph analysis: it reports the vulnerability as actually reachable only if your binary really calls the affected code, which cuts the noise of "it is in the tree but never executed." For a CI gate, it is a clean addition.

Fixing it

The direct fix is to move gRPC-Go to 1.79.3 or later:

go get google.golang.org/[email protected]
go mod tidy

The patch makes the server reject any :path without a leading slash, returning codes.Unimplemented instead of quietly routing it. If the vulnerable version is transitive and the dependency that pulls it in has not updated yet, a temporary replace directive or a Go module exclude can hold the line until upstream catches up, though a direct require bump is cleaner where the graph allows it.

There is also a defense-in-depth lesson worth banking regardless of this CVE: authorization that matches on a raw, externally-supplied string is fragile. Canonicalize the input before you evaluate policy against it, prefer default-deny over deny-with-fallback, and treat the path in an interceptor as untrusted until normalized. Those habits would have made this specific bug a non-event.

The bigger picture

The uncomfortable part of CVE-2026-33186 is not the bug, which is small and now fixed. It is how many teams will read the headline, think "we do not use gRPC," and move on, while a 9.1 sits three levels deep in their dependency graph under a Kubernetes client or a telemetry agent. Modern Go services pull in hundreds of modules; the ones that bite are rarely the ones you typed go get for.

So the takeaway is a habit, not a patch. Run govulncheck ./... in CI so a critical in a transitive dependency shows up as a failed build, not a blog post you skim eight months later. The leading slash is fixed. The next canonicalization bug in something you did not know you depended on is only a matter of time, and the audit that catches it takes about as long as reading this did.