Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. clerkMiddleware continues to authenticate requests correctly, auth() reflects the real authentication state, and token verification is unaffected. Who is affected All apps that combine more than one authorization dimension in a single has() or auth.protect() call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the…
Recommended action: Upgrade to 3.1.16 or 2.6.31 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The clerkFrontendApiProxy function in @clerk/backend is vulnerable to Server-Side Request Forgery (SSRF). An unauthenticated attacker can craft a request path that causes the proxy to send the application's Clerk-Secret-Key to an attacker-controlled server. Affected packages Only applications that have opted into the frontendApiProxy feature are affected. This feature is not enabled by default. Users of @clerk/nextjs are not affected due to how the framework handles repeated / in request paths. | Package | Affected versions | Fixed version | |---|---|---| | @clerk/backend | = 3.0.0, <= 3.2.2 | 3.2.3 | | @clerk/express | = 2.0.0, <= 2.0.6 | 2.0.7 | | @clerk/hono | = 0.1.0, <= 0.1.4 | 0.1.5 | | @clerk/fastify | = 3.1.0, <= 3.1.4 | 3.1.5 | Search your codebase for the frontendApiProxy option. If none of the patterns below appear in your code, you are not affected. @clerk/express @clerk/hono @clerk/fastify @clerk/backend A quick way to check across your entire project: If there…
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Applications that use the verifyWebhook() helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. Patches @clerk/backend: the helper has been patched as of 2.4.0 @clerk/astro: the helper has been patched as of 2.10.2 @clerk/express: the helper has been patched as of 1.7.4 @clerk/fastify: the helper has been patched as of 2.4.4 @clerk/nextjs: the helper has been patched as of 6.23.3 @clerk/nuxt: the helper has been patched as of 1.7.5 @clerk/react-router: the helper has been patched as of 1.6.4 @clerk/remix: the helper has been patched as of 4.8.5 @clerk/tanstack-react-start: the helper has been patched as of 0.18.3 Resolution The issue was resolved in @clerk/backend 2.4.0 by: Properly parsing the webhook request's signatures and comparing them against the signature generated from the received event Workarounds If unable to upgrade, developers can workaround this issue by verifying webhooks manually, per this documentation.
Recommended action: Upgrade to 2.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.