Clerk Changelog

Support for 𝕏 / Twitter v2

Social Connection

X (formerly Twitter) created a new version of their OAuth Provider and Clerk now supports it

We are pleased to announce that Clerk now fully supports 𝕏's (formerly and sometimes still known as Twitter) v2 version of their OAuth workflow. This update aligns with their recent changes to 𝕏's API Access tiers.

For detailed instructions on how to seamlessly integrate 𝕏 v2 into your application using Clerk, please refer to the relevant documentation

Konstantinos Pittas

Improved organization billing visibility


Efficiently track and manage their organization's expenses from a single location

Previously, customers found it challenging to discern their expenses within their Clerk organizations - having to navigate through various paid applications individually to understand their costs. To make things more challenging, there was no visibility at all regarding organization-wide seat allocations.

Now when you select Manage Organization in the Clerk Dashboard, we provide a centralized view into the billing details of your entire organization; including individual application usage and seat allocations.

Alex Ntousias

January 2024 Vulnerability Update


Timeline of events for finding and fixing CVE-2024-22206

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 and have not yet upgraded, please upgrade immediately to 4.29.3

Timeline of events

January 9, 2024

Clerk is in the process of developing a new Next.js SDK. During an internal audit of its codebase on the morning of January 9, 2024, one of our team members noticed a discrepancy in how the user’s authentication state was being determined across different helpers.

Around 11:00 AM UTC, more of the the team was notified and it was confirmed that the discrepancy represented a critical security vulnerability. It was determined that the vulnerability was first introduced with @clerk/nextjs@4.7.0 on Jan 17, 2023.

At 1:06 PM UTC, our team created a pull request in an internal fork of our clerk/javascript repository with a potential fix. Simultaneously, we also began investigating whether the same issue existed for any other SDK packages. Fortunately, no other SDKs were affected by this change.

At 3:43 PM UTC, we began identifying which customers were impacted. The Next.js SDK communicates with Clerk servers using a particular header, and we leveraged this to determine which customers were impacted. (Ultimately, we decided it was best to notify all customers, instead of only the impacted Next.js customers.)

At 5:24 PM UTC, we contacted Cloudflare, Netlify, and Vercel to investigate if network-layer mitigation could be added as an additional safeguard for our customers.

At 7:23 PM UTC, we created a GitHub Security Advisory to request a CVE for our package. This was to make sure the vulnerability was picked up in downstream security tooling that checks for dependency vulnerabilities.

By 8:19 PM UTC, each vendor had responded to indicate that network-level mitigation was feasible, and provided a list of additional details required to enable the mitigation.

January 10th, 2024

We spent the day fulfilling the requests from the cloud vendors to enable network-level mitigations. Each vendor had different requests and required different degrees of back-and-forth.

January 11th, 2024

The cloud vendors all notified us of their intended timelines for deploying network-layer mitigation. In turn, we planned to notify to customers on January 12 at 3:00 PM UTC, after receiving confirmation that all providers had deployed mitigation. We prepared the changelog entry and queued the notification email accordingly.

January 12, 2024

At 4:36 AM UTC we were notified that one vendor identified a bug during the rollout of its mitigation. We collaborated with the vendor to identify and resolve the issue. The next rollout was scheduled to start around 2:00 PM UTC, but was not expected to finish before our planned 3:00 PM UTC customer notification. We made the decision to delay notification until the rollout could complete.

By 9:00 AM UTC, the other two vendors had verified that their mitigation efforts were deployed.

At 3:46 PM UTC, we were notified that the final vendor’s rollout was in progress, and that the bug was no longer present.

At 5:35 PM UTC, @clerk/nextjs@4.29.3 was released with the fix.

At 5:53 PM UTC, the changelog was published and we emailed all customers notifying them of the issue and to upgrade to 4.29.3.

At 5:58 PM UTC, the GitHub advisory was published.

At 6:10 PM UTC, GitHub assigned CVE-2024-22206 for this vulnerability.

We chose to omit specific technical details of the vulnerability to reduce the probability of a zero-day attack. However, additional information was made available to customers who sought to inspect their logs for evidence of an exploit.

At 11:04 PM UTC, we announced the vulnerability on Twitter.

January 12 - January 26, 2024

All customers were welcomed to email our team for assistance with upgrades. We dedicated a team to helping resolve any issues that arose as customers upgraded.

By January 26, all open threads had closed.

January 31, 2024

We deprecated @clerk/nextjs versions in the range >= 4.7.0, < 4.29.3 on the NPM registry

Technical details

The @clerk/nextjs SDK uses JWTs to determine the user making a request. A cryptographic signature is used to verify the authenticity of the JWTs. Since verifying the signature is a relatively expensive operation, the SDK only verifies the JWT once per request, within Next.js middleware.

In Next.js, middleware runs in a separate process from the endpoint handler (meaning, the page rendering endpoint or API endpoint). Therefore, Clerk needed to devise a solution for passing the authentication state from middleware to the endpoint handler.

Our solution was to decorate the request with an additional header containing a boolean that indicated the authentication state. If that boolean indicated the user was signed in, the endpoint would parse user details (like userId) from the JWT, without re-verification.

The vulnerability arose due to mismatch in where the SDK looked for the JWT. In both middleware and the endpoint handler, Clerk’s SDK should have looked at the header first, then the cookie. This is how the mechanism was originally designed, and how it functioned until version 4.7.0.

In version 4.7.0, a code refactor resulted in the endpoint handler mistakenly looking at the cookie first, then the header. As a result, it became possible to pass a valid JWT in the header, but a fabricated JWT in the cookie. Middleware would verify the header JWT and decorate the request to indicate it was authenticated, but then the endpoint handler would read fabricated claims from the cookie JWT without re-verification.

Using this technique, the vulnerability allowed an attacker could fabricate claims for two types of attacks:

  • Act-on-behalf: an attacker could modify the subject claim (”sub”) to act on behalf of an arbitrary user ID
  • Privilege escalation: the attacker could modify any claims used for authorization to attain increased privileges. For example, a “role” can be arbitrarily changed from “member” to “admin”

Only applications that used authentication in endpoint handlers were impacted. Applications were not impacted if they use a Next.js frontend with a different framework’s backend.

Lessons and Remediation

While we are fortunate this vulnerability did not escalate into an incident, we regret that it was introduced in the first place. Going forward, we have shifted our focus to preventing vulnerabilities like this from being introduced again.

When Next.js middleware was first introduced in 2021, our SDK team recognized it presented a unique security challenge compared to other frameworks because it runs in a separate thread. In turn, the team consulted with one of our website security experts on the design. The original implementation was safe, but an end-to-end test against this particular vector was not created. The missing test allowed for the refactor, which was performed by a different individuals, to unknowingly introduce the vulnerability.

Alongside releasing the patch version, we updated our CI suites so this exact vulnerability could not be re-introduced. We have also adapted our processes so our web security experts are not only responsible for participating in the design and review of the implementation, but also the design and review of our tests.

In addition, we plan to perform the following over the next two quarters:

  • Engage with a third party to conduct code audits of all our SDKs with fresh eyes
  • Add security automation to our build pipelines including vulnerability and risk analysis for first and third-party code
  • Provide additional security training and resources for our engineers

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. For any additional questions or concerns, please reach out to


This was a true, critical vulnerability in our most popular SDK. We want to thank the teams at Cloudflare, Netlify, Vercel for working closely with us to protect our customers against exploits. We are pleased that no customers have reported evidence of an exploit, and we believe that is in large part due to the cloud vendors proactive, network-layer mitigation. We are incredibly grateful for their collaboration and swift action.

Colin Sidoti

Please upgrade immediately to 4.29.3

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 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

Colin Sidoti

Improved UX for SAML authentication


Enforce the usage of your IdP even when customer's initiate using SSO

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

Haris Chaniotakis

More control to operate your B2B SaaS via Custom Roles and Permissions

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.

<Protect role="org:admin">
  <Link href="/admin">Admin Panel</Link>

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.
Colin Sidoti