The critical severity score here masks the real failure: the developers built authentication infrastructure, then made it meaningless by trusting client-supplied identity claims in a format that advertises its manipulability. The header name itself—Grpc-Metadata-USER—is a code smell. A human-readable, semantically meaningful header suggests developers intended it for debugging or testing, and that convenience made it through to production without security review.
The privilege escalation works because the system correctly authenticated the attacker, then immediately discarded that authenticated identity in favor of a client-supplied claim. Authorization verifies what the spoofed admin can do; authentication only verified what the actual user can do. These should be the same check, derived from a single authoritative identity source. Instead, you have a functioning authentication gate and a functioning permission model—but they're checking different things.
This almost certainly represents a security retrogression. The metadata trust pattern likely predates the authentication requirement—born in an era of implicit internal trust where header passing was a convenient debugging artifact. Authentication was then bolted on, but nobody audited whether downstream identity consumers were still reading from the same trusted source. The fix will likely look like 'stop reading from metadata' rather than 'migrate to proper session context,' which raises an uncomfortable question: what session context was authentication actually populating, if not the one authorization was checking?
The 'authenticated attacker' requirement in the CVSS calculation is largely theater. Credential compromise through phishing, stuffing, or reuse is common enough that requiring 'just' compromised credentials doesn't meaningfully constrain exploitation. The real severity is 'trivial horizontal privilege escalation for anyone with a foothold.'
Beyond the initial endpoint, gRPC metadata headers are designed to propagate through service calls. If the spoofed identity survives a hop to a downstream service, that downstream authorization check sees the same spoofed admin identity with no re-validation against the original authenticated session. You've turned one compromised credential into a skeleton key across every service consuming that metadata chain.
The Grpc-Metadata- prefix is a signature of this anti-pattern across your entire service mesh. The answer to 'what other endpoints are reading identity from gRPC metadata' is almost certainly 'more than the current audit will find,' because this pattern has been normalized. The surgical fix leaves the propagation vector intact—any new service inheriting the same pattern recreates the vulnerability. Determine whether this header convention is codified somewhere as a feature, and if so, deprecate it properly. This is not a gRPC problem—it is the gRPC-flavored edition of a flaw class the industry has been re-executing for forty years: trusting client-supplied identity claims over authoritative server session context.