Clerk — CraftedSignal Threat Feed

Clerk Authorization Bypass Vulnerability

hello@craftedsignal.io — Thu, 30 Apr 2026 18:20:02 +0000

A critical authorization bypass vulnerability has been identified in Clerk’s authorization predicates (has() and auth.protect()) across multiple SDKs, including @clerk/shared, @clerk/nextjs, and @clerk/backend. This flaw, reported on April 18, 2026, and patched on April 22, 2026, can lead to incorrect authorization decisions when combining multiple authorization dimensions (e.g., reverification with role). Specifically, the predicates may return true even if the user does not satisfy all required conditions, potentially allowing unauthorized access to gated actions. A secondary bypass exists in @clerk/nextjs, where auth.protect() silently discards authorization parameters under certain conditions. The vulnerability affects applications using specific combinations of authorization checks, emphasizing the need for immediate patching.

Attack Chain

An attacker identifies an application utilizing affected Clerk packages and vulnerable authorization checks.
The attacker targets an endpoint protected by a combined authorization check (e.g., requiring a specific role and reverification).
The attacker crafts a request that satisfies one, but not all, of the authorization conditions.
Due to the bypass vulnerability, the has() or auth.protect() predicate incorrectly returns true.
The application grants the attacker access to the protected resource or functionality.
In the case of the @clerk/nextjs bypass, the attacker might exploit the silent discarding of authorization parameters when unauthenticatedUrl, unauthorizedUrl, or token are also present in the auth.protect() call, effectively bypassing authorization.
The attacker performs unauthorized actions, such as modifying data or accessing restricted areas of the application.

Impact

Successful exploitation of this vulnerability could lead to unauthorized access to sensitive resources and functionalities within applications using Clerk for authentication and authorization. This could result in data breaches, privilege escalation, and other security incidents. The vulnerability affects a wide range of Clerk packages, potentially impacting a significant number of applications relying on Clerk for access control. Immediate patching is crucial to mitigate the risk of exploitation.

Recommendation

Upgrade to the latest patch release of the consuming app’s framework package as specified in the advisory to remediate CVE-2026-42349.
If immediate upgrade is not feasible, implement the suggested workaround of splitting combined has() or auth.protect() calls into sequential single-condition checks as described in the advisory.
Deploy the Sigma rule ClerkAuthProtectBypass to detect potential exploitation attempts by monitoring for calls to auth.protect that include unauthenticatedUrl, unauthorizedUrl, or token parameters.
Deploy the Sigma rule ClerkCombinedAuthCheckBypass to identify suspicious process creation events that may indicate unauthorized access due to the authorization bypass.

Clerk SSRF Vulnerability in frontendApiProxy Allows Secret Key Leakage

hello@craftedsignal.io — Sat, 28 Mar 2026 12:00:00 +0000

The clerkFrontendApiProxy function in @clerk/backend versions 3.0.0 through 3.2.2, @clerk/express versions 2.0.0 through 2.0.6, @clerk/hono versions 0.1.0 through 0.1.4, and @clerk/fastify versions 3.1.0 through 3.1.4 is susceptible to a Server-Side Request Forgery (SSRF) vulnerability. This flaw enables an unauthenticated attacker to craft malicious request paths that, when processed by the proxy, result in the application’s Clerk-Secret-Key being transmitted to a server under the attacker’s control. Only applications that have explicitly enabled the frontendApiProxy feature are affected. This feature is not enabled by default, limiting the scope of potential impact. Notably, @clerk/nextjs users are not affected due to the framework’s handling of repeated slashes in request paths, which mitigates the vulnerability.

Attack Chain

An attacker identifies an application that has the frontendApiProxy feature enabled and is running a vulnerable version of @clerk/backend, @clerk/express, @clerk/hono, or @clerk/fastify.
The attacker crafts a malicious HTTP request targeting the proxy endpoint (/__clerk/ by default). The request path includes double slashes or other path manipulation techniques to bypass intended routing logic.
The vulnerable clerkFrontendApiProxy function processes the crafted request without proper sanitization or validation of the request path.
Due to the SSRF vulnerability, the proxy makes an internal request to an unintended destination, potentially including an attacker-controlled server.
The application’s Clerk-Secret-Key is inadvertently included in the headers or body of the internal request made by the proxy.
The attacker-controlled server receives the request containing the Clerk-Secret-Key.
The attacker extracts the Clerk-Secret-Key from the captured request.
With the compromised Clerk-Secret-Key, the attacker can impersonate the application, access protected resources, or perform other unauthorized actions within the Clerk ecosystem.

Impact

Successful exploitation of this SSRF vulnerability allows an attacker to obtain the Clerk-Secret-Key of a vulnerable application. While internal logs from Clerk show no evidence of active exploitation, the potential impact of a compromised secret key is significant. An attacker with the key can impersonate the application, potentially leading to unauthorized access to user data, modification of application settings, or other malicious activities. The severity is further heightened because a successful attack can occur without authentication.

Recommendation

Upgrade to the patched version of @clerk/backend (3.2.3), @clerk/express (2.0.7), @clerk/hono (0.1.5), or @clerk/fastify (3.1.5) immediately if you are using the frontendApiProxy feature.
Rotate your Clerk Secret Key in the Clerk Dashboard under API Keys after upgrading to mitigate potential compromise, as recommended by the advisory.
Audit access logs for requests to your proxy endpoint (/__clerk/ by default) containing double slashes in the path to detect potential exploitation attempts.
Deploy the Sigma rule provided below to identify requests with double slashes to the Clerk proxy endpoint.