認証プラットフォームのClerkで@clerk/nextjs などでミドルウェア認可を迂回する重大な脆弱性|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年04月23日更新日時: 2026年04月23日

人気のユーザー管理プラットフォームであるClerkは2026年4月15日、createRouteMatcher を使ったミドルウェアベースのルート保護が、細工したリクエストによって回避される重大脆弱性を公表しました。対象は @clerk/nextjs、@clerk/nuxt、@clerk/astro と、その内部で使われる @clerk/shared です。GitHub Advisoryでは深刻度は Critical、CVSS v3.1 は 9.1 です。

今回の問題は、セッションそのものが奪われるものではありません。Clerkも、既存ユーザーになりすますことはできず、影響はミドルウェア段階のアクセス制御判断に限られると説明しています。ただし、createRouteMatcher によるミドルウェア判定だけに依存して保護していたアプリでは、下流のAPIルートやServer Componentsまで到達されるおそれがあります。

1 何が起きたか
2 影響を受ける条件
3 対象バージョン

何が起きたか

問題となったのは、Clerkの createRouteMatcher を使って、特定パスだけをミドルウェアで保護する実装です。GitHub Advisoryでは、たとえば Next.js で const isProtectedRoute = createRouteMatcher(['/admin(.*)']) とし、if (isProtectedRoute(req)) { await auth.protect(); } のように書くパターンが、細工したリクエストで迂回され得ると説明しています。

一方で、すべてを保護して一部だけを公開する、いわゆる deny by default に近い書き方は、今回の迂回をミドルウェア層で防げるとされています。Clerkは、const isPublicRoute = createRouteMatcher(['/docs(.*)']) としたうえで、if (!isPublicRoute(req)) { await auth.protect(); } とする一般的な実装は、今回の問題の影響を受けにくいと案内しています。

影響を受ける条件

影響を受けるのは、createRouteMatcher を使ったミドルウェア判定だけで保護を完結させているアプリです。

Clerkは、clerkMiddleware 自体はリクエストの認証状態を正しく扱っており、auth() が返す認証状態も実際の呼び出し元を反映すると説明しています。そのため、ルートハンドラー、Server Components、Server Actions の内部で auth() などによる追加の認可確認をしている場合は、防御層が残ります。

また、外部APIで各リクエストごとにトークン検証をしているエンドポイントも、今回の影響対象ではないとされています。つまり、本件は Clerk 全体の認証破綻ではなく、ミドルウェアの経路判定だけに依存した設計で、保護対象パスの選別を迂回される問題です。