CVE-2026-33186

ADVISORY - github

Summary

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

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.

Who is impacted? This affects gRPC-Go servers that meet both of the following criteria:

They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer):

v1.79.3
The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)

2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

EPSS Score⁠: 0.01557 (0.730)

Common Weakness Enumeration (CWE)

ADVISORY - nist

CWE-285⁠

Improper Authorization

CWE-551⁠

Incorrect Behavior Order: Authorization Before Parsing and Canonicalization

ADVISORY - github

CWE-285⁠

Improper Authorization

Impacted images

Advisories

GitHub

CREATED

5 months ago

UPDATED

5 months ago

ADVISORY IDGHSA-p77j-4mvh-x3m3⁠

EXPLOITABILITY SCORE

3.9

EXPLOITS FOUND

COMMON WEAKNESS ENUMERATION (CWE)

CWE-285⁠

CVSS SCORE

9.1critical

Package	Type	OS Name	OS Version	Affected Ranges	Fix Versions
google.golang.org/grpc	golang	-	-	<1.79.3	1.79.3

CVSS:3 Severity and metrics

The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification⁠.

The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.

The vulnerable system can be exploited without interaction from any user.

An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.

There is a total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any or all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

There is no impact to availability within the impacted component.

Docker

CREATED

5 months ago

UPDATED

5 months ago

ADVISORY ID

CVE-2026-33186

EXPLOITABILITY SCORE

EXPLOITS FOUND

COMMON WEAKNESS ENUMERATION (CWE)-

RATING UNAVAILABLE FROM ADVISORY

NIST

CREATED

5 months ago

UPDATED

CREATED

5 months ago

UPDATED

5 months ago

ADVISORY IDCVE-2026-33186⁠

EXPLOITABILITY SCORE

EXPLOITS FOUND

COMMON WEAKNESS ENUMERATION (CWE)-

CVSS SCORE

N/Ahigh

GoLang

CREATED

5 months ago

UPDATED

5 months ago

ADVISORY IDGO-2026-4762⁠

EXPLOITABILITY SCORE

EXPLOITS FOUND

COMMON WEAKNESS ENUMERATION (CWE)-

COMMON WEAKNESS ENUMERATION (CWE)-

RATING UNAVAILABLE FROM ADVISORY

CVE-2026-33186

Summary

Impact

Patches

Workarounds

1. Use a Validating Interceptor (Recommended Mitigation)

2. Infrastructure-Level Normalization

3. Policy Hardening

Common Weakness Enumeration (CWE)

CWE-285⁠

CWE-551⁠

CWE-285⁠

Advisories

GitHub

CVSS SCORE

Attack Vector (AV)Network

Attack Complexity (AC)Low

Privileges Required (PR)None

User Interaction (UI)None

Scope (S)Unchanged

Confidentiality (C)High

Integrity (I)High

Availability (A)None

Docker

NIST

CVSS SCORE

Alpine

Debian

Ubuntu

CVSS SCORE

GoLang

Alma

CVSS SCORE

Alma

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Amazon

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Rocky

CVSS SCORE

Oracle

CVSS SCORE

Oracle

CVSS SCORE

Oracle

CVSS SCORE

Chainguard