CVE-2026-33186 (GCVE-0-2026-33186)

Vulnerability from cvelistv5 – Published: 2026-03-20 22:23 – Updated: 2026-03-24 18:09
VLAI?
Title
gRPC-Go has an authorization bypass via missing leading slash in :path
Summary
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.
CWE
Assigner
References
Impacted products
Vendor Product Version
grpc grpc-go Affected: < 1.79.3
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-33186",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-24T18:08:38.989284Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-24T18:09:13.422Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "grpc-go",
          "vendor": "grpc",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.79.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-285",
              "description": "CWE-285: Improper Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-20T22:23:32.147Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
        }
      ],
      "source": {
        "advisory": "GHSA-p77j-4mvh-x3m3",
        "discovery": "UNKNOWN"
      },
      "title": "gRPC-Go has an authorization bypass via missing leading slash in :path"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-33186",
    "datePublished": "2026-03-20T22:23:32.147Z",
    "dateReserved": "2026-03-17T22:16:36.720Z",
    "dateUpdated": "2026-03-24T18:09:13.422Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-33186\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-03-20T23:16:45.180\",\"lastModified\":\"2026-04-10T20:49:17.737\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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.\"},{\"lang\":\"es\",\"value\":\"gRPC-Go es la implementaci\u00f3n en lenguaje Go de gRPC. Las versiones anteriores a la 1.79.3 tienen un bypass de autorizaci\u00f3n resultante de una validaci\u00f3n de entrada incorrecta del pseudo-encabezado HTTP/2 \u0027:path\u0027. El servidor gRPC-Go era demasiado indulgente en su l\u00f3gica de enrutamiento, aceptando solicitudes donde el \u0027:path\u0027 omit\u00eda la barra inicial obligatoria (por ejemplo, \u0027Service/Method\u0027 en lugar de \u0027/Service/Method\u0027). Si bien el servidor enrut\u00f3 con \u00e9xito estas solicitudes al gestor correcto, los interceptores de autorizaci\u00f3n (incluido el paquete oficial \u0027grpc/authz\u0027) evaluaron la cadena de ruta cruda y no can\u00f3nica. En consecuencia, las reglas de \u0027denegaci\u00f3n\u0027 definidas usando rutas can\u00f3nicas (que comienzan con \u0027/\u0027) no lograron coincidir con la solicitud entrante, permitiendo que bypassara la pol\u00edtica si una regla de \u0027permiso\u0027 de respaldo estaba presente. Esto afecta a los servidores gRPC-Go que utilizan interceptores de autorizaci\u00f3n basados en rutas, como la implementaci\u00f3n oficial de RBAC en \u0027google.golang.org/grpc/authz\u0027 o interceptores personalizados que dependen de \u0027info.FullMethod\u0027 o \u0027grpc.Method(ctx)\u0027; Y que tienen una pol\u00edtica de seguridad que contiene reglas de \u0027denegaci\u00f3n\u0027 espec\u00edficas para rutas can\u00f3nicas pero permite otras solicitudes por defecto (una regla de \u0027permiso\u0027 de respaldo). La vulnerabilidad es explotable por un atacante que puede enviar tramas HTTP/2 crudas con encabezados \u0027:path\u0027 malformados directamente al servidor gRPC. La correcci\u00f3n en la versi\u00f3n 1.79.3 asegura que cualquier solicitud con un \u0027:path\u0027 que no comience con una barra inicial sea inmediatamente rechazada con un error \u0027codes.Unimplemented\u0027, impidiendo que llegue a los interceptores de autorizaci\u00f3n o gestores con una cadena de ruta no can\u00f3nica. Si bien la actualizaci\u00f3n es la ruta m\u00e1s segura y recomendada, los usuarios pueden mitigar la vulnerabilidad utilizando uno de los siguientes m\u00e9todos: Usar un interceptor de validaci\u00f3n (mitigaci\u00f3n recomendada); normalizaci\u00f3n a nivel de infraestructura; y/o endurecimiento de pol\u00edticas.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\",\"baseScore\":9.1,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.9,\"impactScore\":5.2}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-285\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:grpc:grpc:*:*:*:*:*:go:*:*\",\"versionEndExcluding\":\"1.79.3\",\"matchCriteriaId\":\"D5AB3ED0-D11B-461E-B2B1-627D5CCEA236\"}]}]}],\"references\":[{\"url\":\"https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Mitigation\",\"Vendor Advisory\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-33186\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-03-24T18:08:38.989284Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-03-24T18:09:03.096Z\"}}], \"cna\": {\"title\": \"gRPC-Go has an authorization bypass via missing leading slash in :path\", \"source\": {\"advisory\": \"GHSA-p77j-4mvh-x3m3\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 9.1, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"CRITICAL\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"grpc\", \"product\": \"grpc-go\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 1.79.3\"}]}], \"references\": [{\"url\": \"https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3\", \"name\": \"https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3\", \"tags\": [\"x_refsource_CONFIRM\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-285\", \"description\": \"CWE-285: Improper Authorization\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-03-20T22:23:32.147Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-33186\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-03-24T18:09:13.422Z\", \"dateReserved\": \"2026-03-17T22:16:36.720Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-03-20T22:23:32.147Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…