A critical authentication bypass vulnerability (CVE-2026-41248) has been discovered in Clerk’s official JavaScript SDKs, allowing unauthenticated attackers to bypass middleware-level route protection and access protected application resources without valid credentials.
With a CVSS v3.1 score of 9.1 (Critical), the flaw impacts millions of web applications built on Next.js, Nuxt, and Astro frameworks that rely on Clerk’s createRouteMatcher for access control.
Tracked as CVE-2026-41248 and assigned GitHub Security Advisory GHSA-vqx2-fgx2-5wq9, the vulnerability resides in the createRouteMatcher function distributed across @clerk/nextjs, @clerk/nuxt, @clerk/astro, and the underlying @clerk/shared packages.
Security researcher Christiaan Swiers responsibly disclosed the issue to the Clerk security team on April 13, 2026. The team responded swiftly patches were released on April 15, 2026, the same day as public disclosure.
The flaw is rooted in two weakness classifications: CWE-436 (Interpretation Conflict), where conflicting route-matching logic between components creates a security gap, and CWE-863 (Incorrect Authorization), where the authorization check itself fails to enforce access control under adversarial request conditions correctly.
How the Bypass Works
At its core, the vulnerability exploits the createPathMatcher() function in @clerk/shared, which serves as the foundational logic for createRouteMatcher() used by all three affected SDKs.
When a specifically crafted HTTP request is sent to a Clerk-protected application, the route-matching decision at the middleware layer evaluates the request incorrectly, causing isProtectedRoute(req) to return false even for routes that should require authentication.
The following vulnerable middleware pattern, commonly used in Next.js applications, is directly susceptible:
// VULNERABLE PATTERN Next.js (equivalent in Nuxt and Astro)
const isProtectedRoute = createRouteMatcher(['/admin(.*)']);
export default clerkMiddleware(async (auth, req) => {
if (isProtectedRoute(req)) {
await auth.protect();
}
});In this pattern, if the crafted request bypasses the isProtectedRoute() gate, auth.protect() is never called, and the request flows directly to downstream handlers API routes, server components, or server actions without enforcing authentication.
Critically, the bypass is confined strictly to the middleware-level gate. clerkMiddleware It still processes the request and auth() still reflects the genuine authentication state of the caller.
Any application that enforces secondary auth() checks inside route handlers or server components is therefore protected from exploitation at the application layer.
Affected Packages and Versions
The vulnerability affects a wide range of actively maintained package versions across all three frameworks:
| Package | Affected Versions | Patched Version |
|---|---|---|
@clerk/nextjs | ≥5.0.0 ≤6.39.1 / ≥7.0.0 ≤7.2.0 | 5.7.6, 6.39.2, 7.2.1 |
@clerk/nuxt | ≥1.1.0 ≤1.13.27 / ≥2.0.0 ≤2.2.1 | 1.13.28, 2.2.2 |
@clerk/astro | ≥0.0.1 ≤2.17.9 / ≥3.0.0 ≤3.0.14 | 1.5.7, 2.17.10, 3.0.15 |
@clerk/shared | ≥2.20.17 ≤3.47.3 / ≥4.0.0 ≤4.8.0 | 2.22.1, 3.47.4, 4.8.1 |
Applications using @clerk/shared directly via createPathMatcher are also affected, even without any of the framework-specific packages installed. Developers can verify their installed version by running npm why @clerk/shared or the equivalent command for their package manager.
The vulnerability scores 9.1 out of 10 on the CVSS v3.1 scale, a near-maximum Critical rating driven by the following vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
The Attack Vector is Network with Low Complexity, meaning no special tools or configuration are needed. No Privileges or User Interaction are required, making this trivially exploitable by any remote, unauthenticated attacker.
The impact on Confidentiality and Integrity is High; an attacker can read and potentially manipulate protected data, while Availability is unaffected.
Remediation:
Clerk’s security team confirms that all patched versions are drop-in replacements with zero API changes, making upgrading the lowest-friction remediation path. Organizations should apply the version matching their current installed major:
@clerk/nextjs→ v5.x →5.7.6| v6.x →6.39.2| v7.x →7.2.1@clerk/nuxt→ v1.x →1.13.28| v2.x →2.2.2@clerk/astro→ v1.x →1.5.7| v2.x →2.17.10| v3.x →3.0.15@clerk/shared→ v2.x →2.22.1| v3.x →3.47.4| v4.x →4.8.1
For teams unable to upgrade immediately, Clerk recommends inverting the middleware gate by using the “deny-all except public” pattern rather than the vulnerable “allow public, deny protected” approach, and additionally, adding explicit. auth() Calls within every protected route handler, server component, and server action ensure defense-in-depth: even if the middleware gate is bypassed, the downstream authorization check will block unauthenticated access.
FAQ
Q1: Does CVE-2026-41248 compromise existing user sessions or allow account impersonation?
No session tokens remain secure, and no authenticated user can be impersonated; only the middleware-level route-matching gate is bypassed.
Q2: Are external APIs using token-based authentication affected by this vulnerability?
No external APIs that independently verify tokens per request are unaffected since token verification runs outside the impacted middleware logic.
Q3: How can I check if my project uses a vulnerable version of @clerk/shared?
Run npm why @clerk/shared (or your package manager’s equivalent command) to inspect the installed version and cross-reference against the affected ranges.
Q4: Is there a known public exploit available for CVE-2026-41248?
No public exploit has been confirmed, but the low attack complexity and zero privilege requirements make this highly exploitable. Immediate patching is strongly advised.
About the Author
