GHSA-qc2q-p7wx-3px3: Go/google.golang.org/grpc vulnerability
Summary A vulnerability in the xDS RBAC HTTP filter implementation in grpc-go allows remote attackers to bypass authorization policies (specifically DENY rules) by using mixed-case or canonical-case header matchers (e.g., X-Role instead of x-role). Additionally, the safety guards introduced by gRFC A41 to block grpc- prefixed headers can be evaded via variations in casing (e.g., Grpc-Status).
Impact When an operator defines an RBAC policy referencing headers containing uppercase letters (e.g. X-Role), grpc-go fails to match incoming metadata keys because they are unconditionally lowercased. Because of this case-sensitivity mismatch, a policy designed to block requests containing specific header values fails open: the rule is evaluated as a non-match, and traffic that should have been rejected is served.
Furthermore, gRFC A41 requires rejecting configuration schemas specifying header matchers starting with grpc-. Because this check is executed case-sensitively in grpc-go, attackers can bypass the validation by specifying titles like Grpc-Status.
Patches The problem is fixed in master and in the 1.83.1 release.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/google.golang.org/grpcto a version that resolves this vulnerability.Fixed in 1.83.1 - Upgrade
Upgrade
grpc-goto a version that resolves this vulnerability.Fixed in master - Upgrade
Upgrade
grpc-goto a version that resolves this vulnerability.Fixed in 1.83.1 - Configuration
Update gRFC A41-compliant RBAC configuration schemas to reject header matcher entries starting with "grpc-" (the safety guards should not be configured to allow those header matchers).
gRPC xDS RBAC HTTP filter header matcher names = must not specify grpc- prefixed headers (including any casing variations) - Configuration
When defining RBAC policies, ensure referenced header matcher keys are lowercase because incoming metadata keys are unconditionally lowercased by grpc-go, causing DENY rules not to match if the policy uses uppercase letters (e.g., X-Role).
gRPC xDS RBAC HTTP filter header matcher names (case) = use lowercase header matcher names (e.g., x-role instead of X-Role)
Event History
Frequently Asked Questions
Which deployments are exposed to authorization bypass?
Deployments using grpc-go's xDS RBAC HTTP filter are exposed when an RBAC DENY policy references a header name containing uppercase letters, such as X-Role. Incoming metadata keys are lowercased, causing the DENY rule not to match and the request to be served.
What does an attacker need to do to bypass an affected DENY rule?
An attacker needs to send a request whose metadata would otherwise be blocked by a DENY rule that uses an uppercase or canonical-case header matcher. The case mismatch causes grpc-go to evaluate the rule as a non-match.
Can grpc-prefixed header restrictions be bypassed?
Yes. The configuration validation intended to reject header matchers beginning with grpc- is case-sensitive, so a differently cased name such as Grpc-Status can evade the guard.
What version contains the fix?
The issue is fixed in grpc-go 1.83.1 and in master.