Clerk Changelog

The Clerk team recently identified and patched a critical security vulnerability in the @clerk/nextjs SDK that allows malicious actors to gain privileged access or act-on-behalf-of other users.

If you use @clerk/nextjs, please upgrade immediately to 4.29.3

In addition to releasing this patch, we have collaborated with a number of cloud providers to mitigate attacks at the network layer. Below, you will find details about these mitigations, as well as additional details about the vulnerability, and our plans to prevent future reoccurrence.

Proactive network layer mitigation

Upon discovery of the vulnerability, we immediately recognized its severity and reached out to cloud infrastructure providers for help protecting our customers’ applications.

We are pleased to share that Vercel, Netlify, and Cloudflare have deployed mitigations at the network layer. Applications using these providers are already protected. We are incredibly grateful for their fast response and close collaboration to reach the best possible resolution.

It is important to understand that these mitigations are not permanent, and should not be seen as a substitute for immediately upgrading your SDK.

Additional details

• The vulnerability was discovered on Tuesday, January 9 during an internal audit.
• The vulnerability impacts @clerk/nextjs version 4.7.0 to 4.29.2.
• The vulnerability impacts applications that use a Next.js backend. Specifically, those that call auth() in the App Router, or getAuth() in the Pages Router.
• Applications that only use Next.js for its frontend and middleware functionality are not impacted.
• Only the @clerk/nextjs SDK is impacted. Other SDKs, including other Javascript-based SDKs, are not impacted.
• While we are not aware of any exploit, we unfortunately cannot be sure without access to the server’s logs. Detailed instructions for inspecting logs for an attack will be made available to impacted customers who request them, but will not be published publicly. Please email security@clerk.dev if you would like those instructions.
• For the avoidance of doubt, the vulnerability does not grant unauthorized access to Clerk's systems.

Preventing reoccurrence

Security is Clerk’s most important responsibility, and we are continually improving our processes to ensure your application and your users remain safe.

Along with releasing this patch, we have already updated our internal test suites to ensure this particular vulnerability will not be introduced again, or into any other Clerk framework SDK.

In the coming weeks, we will conduct a full post-mortem, which we expect to generate additional preventive measures.

These steps are in addition to our regular independent security audits of our codebase, regular penetration testing, and the continual reports we receive from external security researchers. If you believe you have found a security vulnerability, please report it to us through our vulnerability disclosure program⁠.

Additional support is available

If you have questions or concerns, please do not hesitate to reach out to security@clerk.dev.

From now on when a user attempts to authenticate using OAuth/SSO with an email address domain that is already managed by an Enterprise connection, the user is redirected to their IdP in order to complete the flow

More powerful authorization options

Previously within our Organizations product you had 2 role types to work with (Admin and Member) out-of-the-box. Those roles came with a bunch of default assumptions about how they operated and what rights they each had. For many of our customers, this worked fine – but for a large amount of our more mature customers, you required more. That's where Custom Roles and Permissions comes into play.

With Custom Roles and Permisisons you can now model your application with whatever roles map to your use-case, assign those roles the specific permissions they need and you're on your way. This data gets automatically reflected in your session tokens as claims, ready for you to build out authorization flows within your app.

Customizing your application

We didn't just stop at allowing you to model your application's roles and permissions and enrich your Sessions and JWTs. In pursuit of the best possible DX, like with our <SignUp /> and <SignIn /> components, we took it a step further.

Introducing has(), protect(), and <Protect> - our new authorization helpers. These helpers allow the convenient integration of your custom authorization needs directly inside your apps.

Head to the verifying a user's permissions docs to see all 3 helpers in action.

Learn more

As of today, custom roles and permissions is in public beta. Simply head to the Dashboard⁠ and start configuring your application's roles today.

If you're looking for more detail about the release, read through our announcement blog post, or dive right into the Roles and Permission docs.

We're excited to see what you build 🚀.

Other improvements

• We added a more visible Dashboard UI when you’re in the context of a Development instance. This helps to better indicate that actions taken, such as copying and rotating keys, or modifying other settings, will not apply to the production environment.
• We've improved caching and latency to a handful of our production endpoints.
• We've improved the performance of WAU and MAU calculation for the Dashboard. In some of our larger applications, this was preventing you from seeing data beyond a 6 month lookback.

Filter Users by their latest activity

Use the new last_active_at_since parameter to filter users⁠ according to their latest activity date.

For example, if you were interested to know which users were active between 2023-11-23 and the current day, you could construct a query like this:

You can also use last_active_at as an ordering parameter to sort users by how recently they were active:

Retrieve a single user's latest activity data

You will also now get last_active_at in your response when retrieving user details with the GET /users/{user_id}⁠ endpoint.

Simplified pricing structure

We've completely overhauled and simplified our pricing structure. All plans now include 10k MAUs! Our announcement blog post explains the rationale behind this major shift. For a complete break down, check out our beautifully redesigned pricing page.

Updated Billing Dashboard

We've also overhauled the Plan & Billing section of our Dashboard⁠ so you can more easily understand your current plans usage. If you're one of the folks who shared that our old billing section was inadequate, this update is for you.

A preview of more to come...

You may notice a new look and feel that it's disjointed with the rest of our site. We're working hard behind the scenes on a complete overhaul of our dashboard! Stay tuned for an improved experience...

What is Account Lockout?

Account Lockout is a feature that protects you and your users from brute-force attacks where bots or other nefarious actors repeatedly attempt to gain access. In addition to our other methods of bot detection, now, when a configurable limit of attempts is exceeded – the user's account will be temporarily locked, and they will be prompted to wait for a cooldown period before they can try again.

This prevents malevolent actors from guessing users' credentials by trying out multiple possible codes in rapid succession (brute-force attack).

What do I need to do to activate it?

Well, nothing. We've enabled Account Lockout on all accounts with default settings that shouldn't be intrusive for your users but will certainly inconvenience bots and scripts.

Starting today, you can head to our User & Authentication > Attack Protection⁠ and configure the settings to your application's needs. Specifically, you're able to adjust the number of failed attempts before a user's account is locked and the duration for which they will be prevented from signing in afterwards.

It is also possible to disable Account Lockout, but we highly recommend you keep it on :)

Head to our docs to learn more about brute force attacks and locking user accounts.