GHSA-qc2q-p7wx-3px3 CVE-2026-84303 GO-2026-6441

gRPC-Go: xDS RBAC HTTP Filter bypass via mixed-case Header Matching and gRFC A41 validation evasion

Medium Go

Severity: 6.3 / 10; Medium · CVSS 4.0
Exploit chance (EPSS): 0.31%; Chance of exploitation in the next 30 days. Higher than 24.00% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-178 Improper Handling of Case Sensitivity; CWE-863 Incorrect Authorization
Fix: 1.83.1; Upgrade google.golang.org/grpc to this version or later

Description

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 versions

Go

Package	Vulnerable	Fixed in
google.golang.org/grpc	`<= 1.83.0`	No fix yet
google.golang.org/grpc	`< 1.83.1`	`1.83.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

google.golang.org/grpc Go → `1.83.1`

go

go get google.golang.org/grpc@v1.83.1 && go mod tidy

Severity breakdown

CVSS 4.0 6.3

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Attack vector: Network
Attack complexity: Low
Attack requirements: Present
Privileges required: None
User interaction: None
Confidentiality (vulnerable system): Low
Integrity (vulnerable system): Low
Availability (vulnerable system): None
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None

Weakness

CWE-178: Improper Handling of Case Sensitivity

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

How to prevent it

Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Advisories

Fixes and patches

Packages

github.com/grpc/grpc-go

Timeline

Sep 1, 2026 Published
Sep 15, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-m425-mq94-257g gRPC-Go HTTP/2 Rapid Reset vulnerability	High Known exploited	Also affects google.golang.org/grpc
GHSA-2v4p-qf9q-27wj gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing `:authority` and `Host` headers	High	Also affects google.golang.org/grpc
GHSA-vp52-pcj8-j9qc gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation	High	Also affects google.golang.org/grpc
GHSA-hrxh-6v49-42gf gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities	High	Also affects google.golang.org/grpc
GHSA-p77j-4mvh-x3m3 gRPC-Go has an authorization bypass via missing leading slash in :path	Critical	Also affects google.golang.org/grpc
GHSA-xr7q-jx4m-x55m Private tokens could appear in logs if context containing gRPC metadata is logged in github.com/grpc/grpc-go	Low	Also affects google.golang.org/grpc
GHSA-vjh5-4x84-xrqp Nuxt: Server-side route rules (`redirect`, `headers`, `proxy`, `ssr`) are skipped for case-variant paths when routing is case-insensitive	Medium	Same weakness, CWE-178
GHSA-f72v-6w45-q472 undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens	High	Same weakness, CWE-178

Credits: alimony

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor