Js-cookie security fix ripples across every Clerk SDK

Security fix sweeps through the entire SDK surface

The most significant story this week is a security-driven dependency update that touched every corner of the Clerk JavaScript ecosystem. Clerk's shared library bumped js-cookie from its earlier version to 3.0.7 to address GHSA-qjx8-664m-686j, a vulnerability in the cookie parsing library. Because @clerk/shared is a foundational dependency for nearly every Clerk SDK, the ripple effect was immediate and total. The v3 line — covering framework integrations for Next.js, Remix, Astro, Express, Fastify, Nuxt, Vue, React Router, TanStack React Start, Hono, Chrome Extensions, and Expo — all received patch releases updating through the dependency chain. The same fix landed on the v4 branch in a parallel upgrade that cascaded into the matching v4 SDKs: Next.js, React, Astro, Expo, Chrome Extensions, Nuxt, Express, and more. If you maintain a Clerk integration, this week's changelog is a single line: update your dependency graph so js-cookie lands on 3.0.7. The patch is entirely transparent — no API changes, no behavioral shifts — but skipping it would leave cookie handling exposed.

Subscription UI fix for seat-based billing

Beyond the security sweep, one user-facing fix stands out. Clerk UI gained a corrected isManageableSubscriptionItem helper that controls when the Manage Subscription button appears in UserProfile and OrganizationProfile, and when Cancel/Re-subscribe actions show in SubscriptionDetails. Previously, the logic checked whether a plan had a base fee — meaning paid seat-based plans with no base fee (common for per-user billing models where each seat is additive) were incorrectly treated as unmanageable. The fix redefines "unmanageable" as "the instance's default plan" rather than "the plan has no base fee," so teams using seat-based pricing now see the correct subscription management controls.

Redirect flow polish in React Router

A smaller but welcome improvement arrived for React Router users: redirect URL options set in middleware are now properly forwarded to client state. This means that when your middleware determines a custom redirect target after sign-in or sign-up, the browser-side code respects that decision rather than falling back to defaults — tightening the round-trip for apps with multi-step authentication flows.