External risk intelligence

gRPC-Go Authorization Bypass via Malformed Path Header

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-33186

gRPC-Go is widely used for networked services, including public-facing APIs and microservices. These deployments often expose gRPC endpoints directly to network traffic to facilitate communication between distributed systems, making internet or wide-network reachability a common pattern for this library.

Grpc

before 1.79.3

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical security vulnerability has been identified in gRPC-Go, a widely used implementation for remote procedure calls. This issue could allow unauthorized access by bypassing authorization policies, potentially exposing sensitive operations. The main concern is confirming whether our systems utilize this technology and if the specific vulnerable configuration is present.

Bypasses security checks on some network calls.
Affects systems that allow unverified access.
Confirm relevance and exposure for your services.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by sending specially crafted HTTP/2 frames directly to a gRPC-Go server. This would involve manipulating the `:path` pseudo-header to bypass initial routing checks and then circumventing authorization policies. If the server has specific deny rules for certain paths but a general allow rule, the malformed path could grant unauthorized access to methods.

Network access to the gRPC server.
Sending malformed HTTP/2 frames.
Unauthorized access to restricted methods.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow unauthenticated access to gRPC services when specific authorization configurations are in place. It affects servers using path-based authorization that have deny rules for canonical paths but an allow-all fallback. An attacker could send specially crafted HTTP/2 frames to bypass these authorization checks.

gRPC service authorization rules.
Malformed HTTP/2 `:path` header.
Unauthorized access to gRPC methods.

Operational Fix

Recommended remediation, mitigation, and detection steps

The gRPC-Go implementation is likely managed by platform or application teams, with oversight from security teams for authorization logic. The immediate priority is to identify all gRPC-Go deployments, assess their exposure and criticality, and locate the responsible ownership for planning remediation.

Application or Platform teams own the issue.
Verify affected gRPC-Go deployment reachability.
Plan risk-based remediation or mitigation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is gRPC-Go and how is it used?

gRPC-Go is the official Go language library for implementing gRPC, a high-performance framework used to build networked microservices. Developers use it to enable communication between distributed systems, allowing one service to call methods on another as if they were local. It is a fundamental building block for many modern cloud-native applications and public-facing APIs.

How does CVE-2026-33186 create an authorization bypass?

This vulnerability, classified as Improper Authorization (CWE-285) and Incorrect Default Permissions (CWE-551), stems from overly permissive input handling. The server accepts HTTP/2 path headers that lack a required leading slash. Because authorization tools look for canonical paths starting with a slash, they fail to match these malformed requests against defined 'deny' rules, inadvertently allowing the request to proceed under a default 'allow' policy.

When can an attacker trigger this vulnerability?

An attacker triggers this by sending specially crafted HTTP/2 frames with a non-canonical path header directly to a gRPC-Go server. It is important to note that the issue does not occur if the server lacks path-based authorization interceptors, or if the security policy is configured to explicitly deny all traffic by default rather than relying on a fallback 'allow' rule.

Do I need to worry about this if my service is internal?

Halo Surface Signal notes that gRPC-Go is frequently deployed for networked services with broad reachability, often spanning public-facing APIs or wide internal networks. While internet-facing servers have the highest risk, any gRPC-Go service using path-based authorization that is reachable by untrusted network segments should be considered relevant for risk assessment.

How should I respond to this vulnerability?

The most effective resolution is to upgrade your gRPC-Go dependency to version 1.79.3 or later, which includes a fix that rejects malformed paths before they reach authorization logic. If an immediate upgrade is not feasible, you can implement a validating interceptor to drop invalid requests, apply infrastructure-level path normalization, or harden your security policies to eliminate reliance on default-allow configurations.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.