{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-30836",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-25T14:15:50.363882Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-25T14:16:09.012Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "certificates",
          "vendor": "smallstep",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.30.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Step CA is an online certificate authority for secure, automated certificate management for DevOps. Versions 0.30.0-rc6 and below do not safeguard against unauthenticated certificate issuance through the SCEP UpdateReq. This issue has been fixed in version 0.30.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 10,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-295",
              "description": "CWE-295: Improper Certificate Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-19T20:37:05.757Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/smallstep/certificates/security/advisories/GHSA-q4r8-xm5f-56gw",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/smallstep/certificates/security/advisories/GHSA-q4r8-xm5f-56gw"
        },
        {
          "name": "https://github.com/smallstep/certificates/commit/e6da031d5125cfd99fe9a26f74bb41e4dacca4ef",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/smallstep/certificates/commit/e6da031d5125cfd99fe9a26f74bb41e4dacca4ef"
        },
        {
          "name": "https://github.com/smallstep/certificates/releases/tag/v0.30.0-rc7",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/smallstep/certificates/releases/tag/v0.30.0-rc7"
        }
      ],
      "source": {
        "advisory": "GHSA-q4r8-xm5f-56gw",
        "discovery": "UNKNOWN"
      },
      "title": "Step CA: Unauthenticated Certificate Issuance via SCEP UpdateReq (MessageType=18)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-30836",
    "datePublished": "2026-03-19T20:37:05.757Z",
    "dateReserved": "2026-03-05T21:06:44.606Z",
    "dateUpdated": "2026-03-25T14:16:09.012Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "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"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.79.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:10:29Z",
    "nvd_published_at": "2026-03-20T23:16:45Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIt is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.\n\nThe 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.\n\n**Who is impacted?**\nThis affects gRPC-Go servers that meet both of the following criteria:\n1. 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)`.\n2. Their security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule).\n\nThe vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, 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.\n\nUsers should upgrade to the following versions (or newer):\n* **v1.79.3**\n* The latest **master** branch.\n\nIt is recommended that all users employing path-based authorization (especially `grpc/authz`) upgrade as soon as the patch is available in a tagged release.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nWhile upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:\n\n#### 1. Use a Validating Interceptor (Recommended Mitigation)\nAdd an \"outermost\" interceptor to your server that validates the path before any other authorization logic runs:\n\n```go\nfunc pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {\n    if info.FullMethod == \"\" || info.FullMethod[0] != \u0027/\u0027 {\n        return nil, status.Errorf(codes.Unimplemented, \"malformed method name\")\n    }   \n    return handler(ctx, req)\n}\n\n// Ensure this is the FIRST interceptor in your chain\ns := grpc.NewServer(\n    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),\n)\n```\n\n#### 2. Infrastructure-Level Normalization\nIf 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.\n\n#### 3. Policy Hardening\nSwitch 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.",
  "id": "GHSA-p77j-4mvh-x3m3",
  "modified": "2026-03-25T18:12:09Z",
  "published": "2026-03-18T20:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/smallstep/certificates"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T16:27:53Z",
    "nvd_published_at": "2026-03-19T21:17:09Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nAn attacker can force a Step CA SCEP provisioner to create certificates without completing certain protocol authorization checks.\n\n## Details\n\nSCEP requests carry a message type. On receipt of a SCEP request, Step CA starts processing it by parsing its contents. Message types that were considered valid, but not explicitly supported in Step CA, would result in getting parsed successfully. While processing the parsed SCEP message, authorization logic would be skipped for the non-supported message types.\n\nAs a result, the request would be treated as authorized, bypassing the authorization checks normally enforced as part of the SCEP protocol and its implementation in Step CA.\n\nAuthorization webhooks and regular CA policies, such as allowed names and restrictions on certificate validity periods, remain in place.\n\n## Mitigations\n\nIf you are unable to upgrade to v0.30.0 or newer, the attack can be mitigated by (temporarily) disabling or removing SCEP provisioners, or restricting access to SCEP provisioners to trusted clients only.\n\n## Fix\n\nIn v0.30.0, additional validation was added to SCEP provisioners, so that they reject unsupported message types.\n\n## Acknowledgements\n\nThis issue was identified and reported by Prasanth Sundararajan.\n\n## Embargo List\n\nIf your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.\n\nStay safe, and thank you for helping us keep the ecosystem secure.\n\nIf you have urgent questions, please contact [security@smallstep.com](mailto:security@smallstep.com).",
  "id": "GHSA-q4r8-xm5f-56gw",
  "modified": "2026-04-08T11:57:49Z",
  "published": "2026-03-19T16:27:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/smallstep/certificates/security/advisories/GHSA-q4r8-xm5f-56gw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30836"
    },
    {
      "type": "WEB",
      "url": "https://github.com/smallstep/certificates/commit/e6da031d5125cfd99fe9a26f74bb41e4dacca4ef"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/smallstep/certificates"
    },
    {
      "type": "WEB",
      "url": "https://github.com/smallstep/certificates/releases/tag/v0.30.0-rc7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "step-ca has Unauthenticated Certificate Issuance via SCEP UpdateReq (MessageType=18)"
}