8.8

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-hrxh-6v49-42gf

GHSA-hrxh-6v49-42gf: gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.

Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via `Metadata` & `RequestedServerName` matchers

Affected Component: xDS RBAC
Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
- If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

Affected Component: HTTP/2 transport
Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as ACKs or server-initiated s.

Miggo Vulnerability Database

→

GHSA-hrxh-6v49-42gf

GHSA-hrxh-6v49-42gf:

8.8

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
google.golang.org/grpc	go	< 1.82.1	1.82.1

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The analysis of the provided commit patches reveals three distinct vulnerabilities in the grpc-go library. Two vulnerabilities are within the xDS RBAC implementation, and one is in the HTTP/2 transport layer.

xDS RBAC Authorization Bypass and Panic (Fail-Open and DoS): The root cause was improper handling of unsupported or specific fields within RBAC policies in internal/xds/rbac/matchers.go. The functions matchersFromPermissions and matchersFromPrincipals would silently ignore rules like Metadata and RequestedServerName, effectively disabling authorization checks that relied on them. This created a fail-open authorization bypass. Additionally, when an unsupported field was wrapped in a NOT rule, the recursive parsing would produce an empty matcher list, leading to a nil pointer dereference and a server panic (Denial of Service). The patch corrects this by explicitly handling these rules, returning errors for unsupported fields, and adding checks to ensure NOT rules do not process empty lists.
HTTP/2 Rapid Reset Mitigation Bypass (DoS): The vulnerability existed in the HTTP/2 server's control buffer management in internal/transport/controlbuf.go. The throttling mechanism, intended to prevent resource exhaustion from too many control frames, was incomplete. It only tracked a narrow subset of frames deemed "transport response frames." An attacker could send a rapid sequence of HEADERS and RST_STREAM frames. The resulting cleanupStream items were queued in the control buffer but not counted towards the throttle limit. This allowed an attacker to bypass the mitigation, causing the server to spend excessive CPU cycles processing the queue, resulting in a Denial of Service. The patch addresses this by introducing a more comprehensive isThrottled() check that applies to a wider variety of control buffer items, ensuring that such floods are correctly throttled.

The identified vulnerable functions are the points in the code where the flawed logic existed. For the RBAC issues, matchersFromPermissions and matchersFromPrincipals are where the vulnerable policy translation occurred. For the HTTP/2 DoS, (*controlBuffer).executeAndPut is the function responsible for adding items to the buffer and contained the faulty throttling logic.

Vulnerable functions

google.golang.org/grpc/internal/xds/rbac.matchersFromPermissions

internal/xds/rbac/matchers.go

The function translates xDS RBAC permission policies into internal matchers. It previously ignored unsupported rules like `Metadata` and `RequestedServerName`, causing policies that relied on them to fail open (authorization bypass). It also failed to handle the case where a `NotRule` contained an unsupported field, which would result in an empty list of matchers, leading to a panic during authorization checks.

google.golang.org/grpc/internal/xds/rbac.matchersFromPrincipals

internal/xds/rbac/matchers.go

Similar to the permissions function, this function translates principal identifiers. It incorrectly treated `Metadata` and `SourceIp` as no-ops, leading to authorization bypass. It was also vulnerable to a panic when a `NotId` rule contained an unsupported identifier for the same reason as above.

google.golang.org/grpc/internal/transport.(*controlBuffer).executeAndPut

internal/transport/controlbuf.go

This function adds items to the transport's control buffer. The original throttling logic only counted a small subset of control frames. An attacker could exploit this by flooding the server with frames (like `RST_STREAM` from a rapid reset attack) that would queue up and consume CPU but would not be counted by the `isTransportResponseFrame` check. This bypassed the intended DoS mitigation.