A subtle path normalization flaw in gRPC-Go — tracked as CVE-2026-33186 — lets remote, unauthenticated attackers completely bypass authorization rules on any Go service that uses path-based access control. The bug rates CVSS 9.1. If your Go microservices speak gRPC and you use the official grpc/authz package or custom interceptors based on info.FullMethod, you need to patch now.

What Happened

On March 20, 2026, the gRPC-Go team disclosed a critical authorization bypass (GHSA-p77j-4mvh-x3m3) affecting all versions of google.golang.org/grpc before v1.79.3.

The root cause: gRPC-Go’s server-side routing logic was too permissive about incoming HTTP/2 :path pseudo-headers. The HTTP/2 spec requires paths to start with a leading slash (e.g., /helloworld.Greeter/SayHello). gRPC-Go happily accepted requests where the slash was omitted (e.g., helloworld.Greeter/SayHello), routing them to the correct handler without complaint.

The problem is what happened after routing. Authorization interceptors — including Google’s own grpc/authz RBAC implementation — evaluated the raw, non-canonical path string that came in on the wire, not the normalized version used for routing. Any “deny” rule written in canonical slash-prefixed form failed to match the incoming malformed path, and if the policy had a fallback “allow” rule (which is common in “allow by default, deny specific routes” configurations), the request passed through unchallenged.

In short: one missing character breaks your entire deny list.

Technical Details

CVE: CVE-2026-33186 CVSS Base Score: 9.1 (Critical) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N CWEs: CWE-285 (Improper Authorization), CWE-20 (Improper Input Validation) Affected: google.golang.org/grpc < v1.79.3 Patched: v1.79.3 (or v1.71.1 if building from source with an older major version)

The attack vector is straightforward: an attacker sends raw HTTP/2 frames directly to the gRPC port with a crafted :path that drops the leading slash. No authentication, no prior access, no user interaction required. If the server’s ingress permits direct gRPC traffic (common in Kubernetes sidecar-free configurations, internal mesh environments, or services exposed via load balancer), this is exploitable from the network.

Two conditions must be met for a service to be vulnerable:

  1. The service uses path-based authorization interceptors — either grpc/authz or custom interceptors that read info.FullMethod or grpc.Method(ctx).
  2. The authorization policy has specific “deny” rules for canonical paths and a fallback “allow” rule for anything else.

The second condition describes a common pattern: lock down /admin/.* methods, allow everything else. That entire lockdown evaporates.

Traefik Also Affected

The same underlying flaw propagated to Traefik (the popular Kubernetes ingress controller) through its gRPC-Go dependency. Traefik’s own advisory (GHSA-46wh-3698-f2cx) rates the issue CVSS 7.8, affecting:

  • Traefik v2.x: all versions before v2.11.42
  • Traefik v3.x: all versions before v3.6.12
  • Traefik v3.7.0-ea: all versions before v3.7.0-ea.3

If you run Traefik as your ingress or reverse proxy and have gRPC-based deny rules, those rules are currently not being enforced for malformed requests.

Impact Assessment

Who’s affected: Any Go service or infrastructure component that:

  • Exposes gRPC endpoints
  • Uses google.golang.org/grpc prior to v1.79.3
  • Relies on path-based interceptors to restrict access to specific methods

This is a wide blast radius. gRPC is ubiquitous in Kubernetes-native architectures: service meshes, internal APIs, observability pipelines, CI/CD tooling, and storage backends all commonly use gRPC-Go with path-based auth. Traefik is the second most deployed ingress controller in the Kubernetes ecosystem.

What an attacker can do: Invoke any gRPC method that should be blocked — this could mean reading sensitive data from an admin API, triggering privileged operations, or escalating access within a multi-tenant cluster. The exact impact depends entirely on what the bypassed deny rules were protecting.

No active exploitation in the wild has been reported as of this writing, but the technique is trivially simple to implement. Expect proof-of-concept tools to surface quickly given the breadth of affected systems.

Mitigation

Primary fix: Upgrade google.golang.org/grpc to v1.79.3 or later. The patch adds explicit rejection of any :path value that doesn’t begin with /, returning codes.Unimplemented before the request reaches authorization logic.

For Traefik users:

  • Traefik v2: upgrade to v2.11.42 or later
  • Traefik v3: upgrade to v3.6.12 or later

If you can’t patch immediately:

  1. Add a validating interceptor that rejects requests where info.FullMethod doesn’t match the raw incoming path (i.e., pre-normalize and reject non-canonical paths yourself).
  2. Harden your authorization policy — eliminate fallback “allow” rules where possible. Flip to a deny-by-default posture where only explicitly-listed methods are permitted. This removes the bypass condition even on unpatched servers.
  3. Add infrastructure-level normalization at your load balancer or ingress layer to reject or rewrite malformed HTTP/2 :path headers before they reach your services.

Detection: Look for gRPC requests in your logs or service mesh telemetry where the method path doesn’t start with /. In most cases this traffic will be noise or probes; sustained attempts to reach specific service methods this way are a strong indicator of exploitation attempts.