CVE-2026-33186

CRITICALPre-NVD 9.19.1Elevated

Also known asEUVD-2026-13830 (ENISA EUVD) · GHSA-p77j-4mvh-x3m3 (GitHub Security Advisories) · GO-2026-4762 (OSV.dev)Source: ENISA EUVD

9.1EG

EchelonGraph verdictPlan a fixRemediate within your standard update timelines at low or medium mission impact and sooner than that at high (the SSVC decision on this page).

Public exploit or proof-of-concept code is available

CISA-KEV: Not listedEPSS PROB: 1.6%CVSS: 9.1Exploit: Public PoCExposed services: Not assessed

A fix is available — apply it.

gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have 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. This affects gRPC-Go servers that 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); AND that have a 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. The fix in version 1.79.3 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. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.

CVSS v3: 9.1
EG Score: 9.1CRITICALmedium confidence
EG Risk: 72
EPSS PROB: 1.6%
EPSS %ILE: 76th
KEV: Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

The EG score (9.1): severity, escalated by confirmed exploitation. This CVE's 9.1 is its impact severity (EG Severity), not escalated.

EG Severity: 9.1 CRITICALCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
EG Likelihood: 1.6% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-11-12). FIRST's exploitation probability, not an EchelonGraph model.
Confirmed exploitation: None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority: SSVC Track at medium mission impactTrack at low or medium mission impact; Attend at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; 60 days if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.

SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Attend at high (mission-essential systems).

A fix is available. Apply it within your standard update timelines at low or medium mission impact and sooner than that at high.

Exploitation none (CISA Vulnrichment) · Automatable yes (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). All three are CISA's SSVC values (Vulnrichment). EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; 60 days if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable yes (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

March 20, 2026

Last Modified

September 18, 2026

Advisory Details (10)

Auto-updated Sep 15, 2026

Patch available. Sources: github.

GitHub advisoryMentions a patch (unverified)