Skip to main content

Clerk Changelog

Organization Invitation Sorting

Category
API
Published

We’ve added support for ordering organization invitations when listing them via the /organizations/{organization_id}/invitations endpoint, allowing sorting by creation date or email address in ascending or descending order using the new optional order_by parameter.

Ordering Options

  • +created_at - Sort by creation date in ascending order
  • -created_at - Sort by creation date in descending order (default)
  • +email_address - Sort by email address in ascending order
  • -email_address - Sort by email address in descending order

For more information, see our Backend API documentation.

Contributor
Tom Milewski

Share this article

Model your app's features right inside of Clerk

We’re excited to introduce a new top-level Feature construct for your applications.

Features are utilized inside of our Billing product, like inside your <PricingTable /> implementations, as well as within your app's roles & permissions where you can easily attach permissions to features for authorization checks using our has(), protect(), and <Protect> helpers.

As part of this update, we’ve also redesigned the Roles & Permissions page in the Clerk Dashboard, making it easier to manage user roles and their associated system or feature permissions.

Manage your app’s feature definitions in the Feature Management section of the Dashboard starting today, or as part of your Roles & Permissions configuration.

Contributors
Alex Carpenter
Iago Dahlem
Maurício Antunes
Nicolas Lopes

Share this article

Dashboard accounts now start as an Organization, as opposed to Personal Accounts.

Previously, new users on the Clerk Dashboard started with "personal accounts." This meant that to add collaborators, you first had to convert your account to an Organization. Since July 4th, all new Dashboard users have been automatically set up with an organization, allowing you to invite team members and collaborate immediately.

For existing users, we will automatically migrate your personal account and all its resources to an organization in the coming days. No action is required on your part—all your applications and settings will remain unchanged.

This change only affects Clerk Dashboard users and has no impact on your applications or its users.

Contributor
Clerk

Share this article

CVE-2025-53548

Category
Security
Published

Summary

A vulnerability affecting @clerk/backend >= 2.0.0 < 2.4.0 was recently reported to the Clerk team and resolved. The vulnerability was discovered in the verifyWebhook() helper, which is used to verify incoming Clerk webhooks, and it allowed improperly signed webhook events to be accepted as legitimate. Potentially impacted customers have already been notified via email. If your application does not use verifyWebhook() you are not impacted.

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.

Credits

Thanks to a Clerk customer for responsibly disclosing the issue to the team.

References

Contributor
Bryce Kalow

Share this article

CSS variables support

Category
Product
Published

Clerk's appearance system now supports CSS variables for seamless design system integration and dynamic theming

Clerk's appearance variables object now supports CSS custom properties (CSS variables), making it easier to integrate with your existing design system and enable dynamic theming without JavaScript configuration changes.

How to use CSS variables

You can now use CSS variables directly in your appearance configuration:

styles/globals.css
:root {
  --brand-primary: oklch(49.1% 0.27 292.581);
}

@media (prefers-color-scheme: dark) {
  :root {
    --brand-primary: oklch(54.1% 0.281 293.009);
  }
}

Reference these variables in your Clerk configuration:

app/layout.tsx
<ClerkProvider
  appearance={{
    variables: {
      colorPrimary: 'var(--brand-primary)',
    },
  }}
>
  ...
</ClerkProvider>

Dynamic Theming

With CSS variables, your theme changes automatically based on user preferences, system settings, or any other CSS-driven logic:

/* Theme automatically updates based on user preference */
@media (prefers-color-scheme: dark) {
  :root {
    --brand-primary: oklch(54.1% 0.281 293.009);
  }
}

/* Or with data attributes */
[data-theme='corporate'] {
  --brand-primary: #1e40af;
}

[data-theme='creative'] {
  --brand-primary: #7c3aed;
}

No need to swap Clerk themes or update JavaScript configuration - the components automatically pick up the new colors.

Design System Integration

This enhancement makes it seamless to integrate Clerk with existing design systems:

<ClerkProvider
  appearance={{
    variables: {
      colorPrimary: 'var(--ds-color-brand-primary)',
      colorSuccess: 'var(--ds-color-semantic-success)',
      colorDanger: 'var(--ds-color-semantic-error)',
      colorNeutral: 'var(--ds-color-neutral-base)',
    },
  }}
>
  ...
</ClerkProvider>

Note

Clerk's support for CSS variables relies on color-mix() and relative color syntax, which require a modern browser (Chrome 119+, Safari 16.4+, and Firefox 128+). If your application needs to support older browsers, continue using static color values (like #ff0000 or hsl(0, 100%, 50%)) instead of CSS variables, which will use our existing JavaScript-based color manipulation.

To learn more about support for CSS variables, check out the documentation.

Contributors
Tom Milewski
Alex Carpenter
Dylan Staley

Share this article

Increased Backend Rate Limits

Category
API
Published

We’ve increased the Backend API rate limits for production instances to better support your growing workloads! 🚀

Production instances now support 1000 requests per 10 seconds, a 10x increase from before. This change applies across all endpoints, including Create User.

If you're running high-traffic workloads in production, this gives you more headroom without hitting throttling errors.

We're also working on a smarter, more flexible rate limiting system that scales with your app. More on that soon!

Note: Development instances remain at 100 requests per 10 seconds.

Contributor
Alex Ntousias

Share this article