Executive brief
Clerk, a popular authentication and user management platform, has a vulnerability in its authorization logic. When developers combine multiple security checks (like checking both a user's role and their billing plan) in a single command, the system may incorrectly grant access even if the user doesn't meet all requirements. This could allow unauthorized users to perform actions or access data they should not be able to see, though it does not allow them to impersonate other users or compromise active sessions.
Technical details
An authorization bypass exists in several Clerk SDKs, including @clerk/shared, @clerk/nextjs, and @clerk/backend. The vulnerability occurs when authorization predicates (e.g., `has()`, `auth.protect()`) are used with combined checks, such as pairing a 'reverification' check with a 'role' or 'permission', or pairing 'billing' checks with 'role' checks. In these specific configurations, the logic may incorrectly evaluate to true even if one condition is not met. Additionally, a secondary issue in @clerk/nextjs caused `auth.protect()` to ignore authorization parameters entirely if specific URL or token arguments were present in the same object. Attackers with low privileges can exploit this over a network to bypass intended access controls. Patches are available across all affected major version lines.
Affected products
- Clerk @clerk/shared >= 3.0.0, <= 3.47.4; >= 4.0.0, <= 4.8.2
- Clerk @clerk/nextjs >= 6.0.0, <= 6.39.2; >= 7.0.0, <= 7.2.3
- Clerk @clerk/backend >= 2.0.0, <= 2.33.2; >= 3.0.0, <= 3.2.13
- Clerk @clerk/clerk-js >= 5.22.0, <= 5.125.9; >= 6.0.0, <= 6.7.4
Timeline
- 2026-04-18: disclosed: Reported by AISafe
- 2026-04-22: patched
- 2026-04-22: advisory