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.

NIST NVD CVE-2026-33186

Notice: This package is EXPERIMENTAL and may be changed or removed in a later release.

Documentation

Forward-thinking developers wish to write code that is flexible and easy to maintain. Separating logic into domains with pluggable interfaces helps us focus on a single aspect of the design, allows us to rearrange the parts, discard and add new ones, more easily test and assert their logic.

The middleware pattern is often a simple function chain, kind of like an onion of wrapped closure functions, each layer calling the next. A more naive approach is dropping the request directly into a large function responsible for auth, request tagging, logging, rate-limiting, transport logic, API logic, business logic, etc. Grasping the logic of such a function or altering one aspect could bring the whole house down.

So most developers have pushed auth to a middleware, which should bail before ever reaching a handler to fulfill the request. Perhaps a zealous adherence to this Separation of Concerns has convinced developers that it’s poor design for handlers to concern themselves with auth. There has been a litany of auth bypass vulnerabilities in these middlewares, probably most notably, Next.js CVE-2025-29927 via header “x-middleware-subrequest”, an actual feature of the framework.