はじめに：Clerk SDKミドルウェアの重要な脆弱性

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、皆様のプロジェクトでClerk JavaScript SDKをご利用の場合に緊急の対応が必要となる重要な脆弱性（CVE-2026-41248）について解説します。この脆弱性は、Clerkのミドルウェアによるアクセス制限機能が特定の状況下で迂回される可能性があり、早急な対応が求められます。

脆弱性の概要と仕組み

この脆弱性は、Clerkの公式JavaScript SDK（`@clerk/nextjs`、`@clerk/nuxt`、`@clerk/astro`）が提供する`createRouteMatcher`関数に存在します。ミドルウェアで`createRouteMatcher`を使ってルーティング保護（`middleware`によるアクセス制限）を設定している場合、特殊な細工が施されたリクエストによってその保護が迂回されてしまう可能性があります。

これにより、本来ミドルウェアによってブロックされるべき認証されていないユーザーが、APIルート、サーバーコンポーネント、サーバーアクションなどの保護された後続の処理に到達してしまう恐れがあります。

ただし、この脆弱性が直接的にユーザーセッションを侵害したり、既存のユーザーに成りすましたりするリスクはありません。影響は、あくまでミドルウェアレベルでのアクセス制御の判断が迂回される点に限定されます。

影響を受ける条件

`createRouteMatcher`を使用しているすべてのアプリケーションが潜在的に影響を受けます。特に、以下のようなパターンでミドルウェアを設定している場合は注意が必要です。

ミドルウェア内で`createRouteMatcher`を使って特定のルート（例：`/admin(.*)`）を保護し、その内部で`auth.protect()`を実行しているアプリケーションは影響を受ける可能性があります。例えば、Next.jsの`clerkMiddleware`で`isProtectedRoute(req)`がtrueの場合に`await auth.protect()`を呼び出しているケースです。

また、アプリケーションコードで`@clerk/shared`を直接インポートし、影響を受けるバージョンの`createPathMatcher`を使用している場合も同様に影響を受けます。プロジェクト内で`npm why @clerk/shared`などのコマンドを実行し、インストールされているバージョンを確認することをお勧めします。

影響を受けないケース

以下のケースでは、このミドルウェアの脆弱性の影響を直接受けません。

1. **ルートハンドラー、サーバーコンポーネント、サーバーアクション内部での`auth()`チェック:** `clerkMiddleware`自体はリクエストを認証し、`auth()`関数は呼び出し元の実際の認証状態を正確に反映します。そのため、ミドルウェアの迂回があったとしても、これらの内部で別途`auth()`を使った認証チェックを実装している場合、その内部チェックは引き続き正しく機能し、アクセスをブロックできます。

2. **独立したトークン検証:** トークン検証を独自に実装している外部APIのエンドポイントは、この脆弱性の影響を受けません。

3. **「パブリックルートではない場合に保護する」パターン:** 例えば、`createRouteMatcher`でパブリックルートを定義し、そのルートではない場合に`auth.protect()`を実行するパターン（`if (!isPublicRoute(req))`のような条件）を使用している場合、ミドルウェア層で適切にブロックされるため、この脆弱性の影響は受けません。

推奨される対応策：最優先でアップデートを！

最も重要な対応策は、**現在ご利用中のフレームワークとメジャーバージョンに合わせたClerk SDKのパッチバージョンへのアップデート**です。これらのアップデートはAPIの変更なしにそのまま適用可能です。

以下に、各SDKの修正済みバージョンを示します。

<ul><li><strong><code>@clerk/nextjs</code></strong><ul><li>v7.x: <code>7.2.1</code>で修正済み</li><li>v6.x: <code>6.39.2</code>で修正済み</li><li>v5.x: <code>5.7.6</code>で修正済み</li></ul></li><li><strong><code>@clerk/nuxt</code></strong><ul><li>v2.x: <code>2.2.2</code>で修正済み</li><li>v1.x: <code>1.13.28</code>で修正済み</li></ul></li><li><strong><code>@clerk/astro</code></strong><ul><li>v3.x: <code>3.0.15</code>で修正済み</li><li>v2.x: <code>2.17.10</code>で修正済み</li><li>v1.x: <code>1.5.7</code>で修正済み</li></ul></li><li><strong><code>@clerk/shared</code></strong><ul><li>v4.x: <code>4.8.1</code>で修正済み</li><li>v3.x: <code>3.47.4</code>で修正済み</li><li>v2.x: <code>2.22.1</code>で修正済み</li></ul></li></ul>

一時的な回避策

もしすぐにSDKのアップデートが難しい場合は、ルートハンドラー、サーバーコンポーネント、またはサーバーアクションの内部で、`auth()`関数を使って別途認証チェックを実装することで、この脆弱性に対する多層防御を追加できます。これにより、ミドルウェアが迂回されたとしても、最終的なリソースへのアクセスを防ぐことが可能です。

まとめ

Clerk JavaScript SDKのミドルウェアにおけるアクセス制限の脆弱性は、アプリケーションのセキュリティにクリティカルな影響を及ぼす可能性があります。プロジェクトの安全性を確保するため、**可能な限り速やかにClerk SDKを最新のパッチバージョンにアップデートする**ことを強く推奨します。常に依存関係のセキュリティを意識し、最新の状態に保つことが、セキュアなアプリケーション開発の基本です。