Clerk SDKs — CVSS 9.1 middleware route-protection bypass in @clerk/nextjs, @clerk/nuxt and @clerk/astro (CVE-2026-41248), plus an authorization-predicate bypass (CVE-2026-42349) and a secret-key-leaking proxy SSRF (CVE-2026-34076); no changelog entry, no press

View raw markdownEdit on GitHub ↗

TL;DR

Clerk — the hosted-auth SDK that most Next.js starter templates and vibe-coding scaffolds drop in for sign-in — published three security advisories on its own GitHub advisory tab between 2026-03-26 and 2026-04-22, with no changelog entry and no press coverage. The one that matters most: CVE-2026-41248 (CVSS 9.1, Critical) — a crafted request evades createRouteMatcher, so clerkMiddleware never runs its gate and the request reaches the "protected" route handler. If your handler also calls auth() you were safe; if the middleware was your only check (the pattern the docs teach, and the pattern an AI assistant generates), any route you thought was behind login was reachable. Fixed 2026-04-15 in @clerk/nextjs 5.7.6 / 6.39.2 / 7.2.1, @clerk/nuxt 1.13.28 / 2.2.2, @clerk/astro 1.5.7 / 2.17.10 / 3.0.15. Two more: CVE-2026-42349 (has() / auth.protect() return true for combined checks that should fail, 17 packages, fixed 2026-04-22) and CVE-2026-34076 (the opt-in clerkFrontendApiProxy could be steered to an attacker host carrying the app's secret key, fixed 2026-03-26). Upgrade all @clerk/* packages together and check that every protected handler enforces auth itself.

What happened

Three advisories, each published on github.com/clerk/javascript/security/advisories and each fetched directly for this write-up. Clerk's public changelog for March–May 2026 carries no security entry for any of them, and this repo found no independent press coverage — the CVSS 9.1 sat unindexed here for five months.

CVE-2026-41248 — middleware-based route protection bypass (GHSA-vqx2-fgx2-5wq9)

  • Published: 2026-04-15 (reported 2026-04-13, patched and disclosed two days later). NVD record published 2026-04-24, CNA GitHub.
  • Score: CVSS 3.1 9.1 Critical — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N on both the vendor page and NVD. CWE-436 (interpretation conflict), CWE-863 (incorrect authorization).
  • Mechanism, per the advisory: createRouteMatcher — the helper you pass route patterns to inside clerkMiddleware — "can be bypassed by certain crafted requests, allowing them to skip middleware gating and reach downstream handlers." The vendor explicitly scopes it: sessions are not compromised and no user can be impersonated. The failure is that the routing decision the middleware makes is skipped, so a handler the developer meant to gate executes for an unauthenticated request. "If those handlers perform their own auth() checks, they will correctly identify the request as unauthenticated." Two parsers, one URL string — the same shape as the Next.js middleware-bypass cluster tracked here in May and July.
  • Affected / fixed (vendor page):
Package Vulnerable Patched
@clerk/nextjs 5.0.0 – 5.7.5, 6.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

The npm registry confirms the patch releases landed on 2026-04-15 (@clerk/nextjs 7.2.1 at 14:29 UTC, 5.7.6 at 14:45, 6.39.2 at 15:10). Credit: Christiaan Swiers (YouGina).

CVE-2026-42349 — authorization predicates return true for combined checks (GHSA-w24r-5266-9c3c)

  • Published: 2026-04-22 (reported 2026-04-18 by AISafe). NVD published 2026-05-11.
  • Score: vendor CVSS 4.0 7.6 High; NVD adds a CVSS 3.1 8.1 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). CWE-754, CWE-863.
  • Mechanism: has(), auth.protect() and related predicates "can incorrectly return true for combined checks when the result should be false" in two combinations — a reverification requirement paired with a role / permission / feature / plan check, and a billing check (feature or plan) paired with a role or permission check. Single-condition checks were unaffected. Additionally in @clerk/nextjs, the authorization parameters were silently discarded when the same object also carried unauthenticatedUrl, unauthorizedUrl or token — so a call that looked like it enforced a role enforced nothing. An authenticated user who fails one half of a compound condition performs the gated action.
  • Affected / fixed: 17 packages. The ones a vibe-coded stack most likely holds: @clerk/nextjs 6.0.0 – 6.39.2 and 7.0.0 – 7.2.3 → 6.39.3 / 7.2.4; @clerk/clerk-js 5.22.0 – 5.125.9 and 6.0.0 – 6.7.4 → 5.125.10 / 6.7.5; @clerk/backend 2.0.0 – 2.33.2 and 3.0.0 – 3.2.13 → 2.33.3 / 3.2.14; @clerk/shared 3.0.0 – 3.47.4 and 4.0.0 – 4.8.2 → 3.47.5 / 4.8.3; @clerk/clerk-react ≤ 5.61.5 → 5.61.6; @clerk/react ≤ 6.4.2 → 6.4.3; @clerk/express ≤ 1.7.78 / ≤ 2.1.5 → 1.7.79 / 2.1.6; @clerk/nuxt ≤ 1.13.28 / ≤ 2.2.4 → 1.13.29 / 2.2.5; @clerk/astro ≤ 2.17.10 / ≤ 3.0.17 → 2.17.11 / 3.0.18; plus @clerk/fastify, @clerk/hono, @clerk/vue, @clerk/react-router, @clerk/tanstack-react-start, @clerk/expo, @clerk/clerk-expo, @clerk/chrome-extension (full table on the advisory page). Note that the @clerk/nextjs fix for this bug (6.39.3 / 7.2.4, published 2026-04-22 per the registry) is one patch release after the CVE-2026-41248 fix — upgrading to 6.39.2 on 2026-04-15 left this one open.

CVE-2026-34076 — SSRF in the opt-in clerkFrontendApiProxy leaks the secret key (GHSA-gjxx-92w9-8v8f)

  • Published: 2026-03-26; found in an internal code audit. CVSS 3.1 7.4 High, CWE-918.
  • Mechanism: clerkFrontendApiProxy lets a backend proxy the browser's Frontend API calls. A crafted request path could redirect the proxy's outbound request to an attacker-controlled server, "causing the application's authentication secret key to be transmitted to unintended hosts." Only apps that explicitly enabled the proxy were exposed; it is off by default.
  • Affected / fixed: @clerk/backend 3.0.0 – 3.2.2 → 3.2.3; @clerk/express 2.0.0 – 2.0.6 → 2.0.7; @clerk/hono 0.1.0 – 0.1.4 → 0.1.5; @clerk/fastify 3.1.0 – 3.1.4 → 3.1.5.

Why this belongs in a vibe-coding feed

Clerk is the auth layer a large share of Next.js scaffolds ship with, and the middleware pattern — const isProtected = createRouteMatcher(['/dashboard(.*)']); clerkMiddleware(async (auth, req) => { if (isProtected(req)) await auth.protect(); }) — is exactly what an AI assistant generates when asked to "add login." That pattern puts all of the authorization in the one place CVE-2026-41248 skips. The vendor's own mitigation language ("if those handlers perform their own auth() checks…") is the defence-in-depth rule this repo already gives for the Next.js middleware bugs: middleware is a convenience gate, not the security boundary; every server action and route handler that touches user data checks auth itself. Add to that the fact that none of this reached a changelog, a blog or a news outlet: an app scaffolded in Q1 2026 and never touched since carries all three bugs today, and npm audit is the only thing that would have said so.

No exploitation in the wild is reported by the vendor, NVD or the one independent write-up located (ZeroPath, 2026-04-24) as of 2026-09-15.

Am I affected?

# Which Clerk packages, which versions?
npm ls @clerk/nextjs @clerk/nuxt @clerk/astro @clerk/shared @clerk/clerk-js @clerk/backend @clerk/express 2>/dev/null
npm audit 2>/dev/null | grep -A3 -i 'clerk'
# Do you gate routes in middleware only?
grep -rn 'createRouteMatcher\|clerkMiddleware\|auth.protect\|has({' middleware.ts proxy.ts src/ app/ 2>/dev/null | head -40
# Did you opt in to the Frontend API proxy?
grep -rn 'clerkFrontendApiProxy' . --include='*.ts' --include='*.js' 2>/dev/null

You are affected by CVE-2026-41248 if @clerk/nextjs is below 5.7.6 / 6.39.2 / 7.2.1 (or the Nuxt/Astro equivalents) and any route relies on clerkMiddleware + createRouteMatcher as its only check. You are affected by CVE-2026-42349 if you combine reverification with a role/permission/plan check, or a billing check with a role/permission check, anywhere in has() / auth.protect() on a version below the 2026-04-22 releases. CVE-2026-34076 needs the proxy explicitly enabled.

If you are affected

  1. Upgrade every @clerk/* package in the lockfile to the 2026-04-22 line or later (that covers all three; the 2026-04-15 releases cover only CVE-2026-41248). The patches are drop-in with no API changes per the vendor.
  2. Audit each protected route handler and server action: does it call auth() / auth.protect() itself, or does it trust that middleware ran? Fix the ones that trust middleware — this closes the class, not just the CVE. → playbooks/auditing-a-vibe-coded-repo.md
  3. If the app was internet-facing with middleware-only gating between January and April 2026, review access logs for unauthenticated hits on gated paths and treat any user data behind them as potentially read. → playbooks/if-your-webapp-was-compromised.md
  4. If clerkFrontendApiProxy was enabled on an affected version, rotate the Clerk secret key and review Clerk dashboard activity. → playbooks/rotating-cloud-credentials.md

Prevention

  • → prevention/credential-hygiene.md — a secret key that a proxy can be steered to leak is a secret key that needs a rotation runbook.
  • Enforce authorization at the data boundary (route handler, server action, RLS), not only at the edge. The Next.js middleware bypasses of 2025–2026 and this Clerk one are the same lesson from two layers of the same stack.
  • Watch the auth SDK's own advisory tab. Clerk, Better Auth and NextAuth.js all disclose through GitHub Security Advisories, not blogs; npm audit or Dependabot alerts on the auth package are the only timely signal.

Sources