はじめに

皆さん、こんにちは。今回は、Next.jsアプリケーション「9router」に存在する重要な脆弱性（GHSA-8gmq-j984-vp4r / CVE-2026-55638）について解説します。この脆弱性は深刻度「high」と評価されており、LLM（大規模言語モデル）のプロキシ機能において、認証をバイパスして不正にアクセスされる可能性があります。

9routerは、OpenAIやAnthropic互換のLLMプロキシを提供するツールです。通常、このプロキシへのリモートアクセスは、Next.jsミドルウェアによるAPIキー認証によって保護されるように設計されています。しかし、ある特定のパスのリライト設定が原因で、この認証が機能しない状況が発生します。

脆弱性の概要：認証バイパスのメカニズム

この脆弱性の核心は、Next.jsのミドルウェアでの認証処理が、リクエストパスのリライトが適用される**前**に行われることにあります。

9routerの`next.config.mjs`では、`/codex/*`というパスをバックエンドのLLMエンドポイントである`/api/v1/responses`にリライトする設定が定義されています。

一方、認証を担当する`src/dashboardGuard.js`内のミドルウェアは、保護対象とするLLM APIのプレフィックスとして`/v1`, `/v1beta`, `/api/v1`, `/api/v1beta`をリストアップしていますが、**`/codex`はこのリストに含まれていません**。

その結果、`/codex/*`へのリクエストはミドルウェアの認証チェックをすり抜け、その後`/api/v1/responses`にリライトされることで、認証なしでLLMプロキシにアクセスできてしまうのです。

技術的詳細と根本原因

具体的なコンポーネント間の相互作用を見ていきましょう。

<ul><li><strong>Middleware authorization gate (`src/dashboardGuard.js`)</strong>: リクエストパスに基づいて認証判断を行います。認証が必要なパスリストには`/codex`が含まれていません。</li><li><strong>Rewrite configuration (`next.config.mjs`)</strong>: `/codex/:path*`を`/api/v1/responses`にリライトします。</li><li><strong>LLM backend route (`src/app/api/v1/responses/route.js`)</strong>: リライトされたリクエストを受け取り、LLMハンドラにディスパッチします。</li><li><strong>Chat handler (`src/sse/handlers/chat.js`)</strong>: 運営者が設定したプロバイダー資格情報を使用して、アップストリームのLLMプロバイダーへの呼び出しを行います。</li></ul>

根本原因は、ミドルウェアがリクエストをオリジナルの受信パス名で分類していることにあります。`/codex`が保護対象のプレフィックスリストに含まれていないため、`/codex/x`のようなリクエストは認証ブランチに入らず、`NextResponse.next()`として通過します。

その後、リライト設定によってこの認証されていないリクエストが保護されるべきバックエンドルート（`/api/v1/responses`）にマッピングされ、最終的にLLMプロバイダーへの呼び出しが実行されます。この段階で再度APIキーの検証は行われないため、認証が完全にバイパスされてしまいます。

攻撃シナリオと影響

攻撃者は、公開されている9routerインスタンスを特定し、認証が必要な`/api/v1/responses`ではなく、認証をバイパスできる`/codex/*`パスに対してLLMプロキシリクエストを送信します。

これにより、ミドルウェアが認証を適用しないままリクエストが通過し、バックエンドでリライト処理を経てLLMプロバイダーへの呼び出しが行われます。この際、9router運営者が設定したLLMプロバイダーの資格情報が使用されてしまいます。

この脆弱性が悪用された場合、以下のような深刻な影響が考えられます。

<ul><li><strong>LLMプロキシの不正利用</strong>: 攻撃者が無制限にLLMプロキシを利用できるようになります。</li><li><strong>運営者のコスト消費</strong>: 攻撃者の利用により、運営者が契約しているLLMプロバイダーの利用料金やクォータが不正に消費されます。</li><li><strong>APIキーの信頼性低下</strong>: APIキーによるアクセス制御が無効化され、セキュリティモデルが破綻します。</li><li><strong>情報漏洩の可能性</strong>: LLMへの不適切な入力や出力により、予期せぬ情報が漏洩するリスクも考えられます（直接の情報漏洩ではないが、利用状況から推測されうる）。</li></ul>

対策

この脆弱性に対する根本的な対策は、Next.jsミドルウェアの認証ロジックを修正し、`/codex`パスも保護対象に含めることです。

具体的には、`src/dashboardGuard.js`内の`PUBLIC_PREFIXES`リストに`/codex`を追加する必要があります。これは、`PUBLIC_PREFIXES`の配列に`"/codex"`という文字列を追加するだけの簡単な修正で対応可能です。例えば、`PUBLIC_PREFIXES = ["/v1", "/v1beta", "/api/v1", "/api/v1beta", "/codex"];`のように記述します。

また、一般的なセキュリティプラクティスとして、リライト後のパスについても再度認証や認可のチェックを行うなど、多層的な防御を検討することが重要です。

利用されている9routerのバージョンが`v0.4.80`（コミット`23da7b1fe3bb8edd2bdbdb63fbbb15a476b02c56`）である場合、この脆弱性の影響を受けることが確認されています。最新のセキュリティパッチが適用されたバージョンへのアップデートを強く推奨します。

まとめ

今回は、Next.js製アプリケーション9routerにおけるLLMプロキシの認証バイパス脆弱性について深く掘り下げて解説しました。ミドルウェアとリライト機能の意図しない連携が、認証メカニズムの抜け穴となる典型的なケースです。

フロントエンドエンジニアの皆さんにとって、Next.jsのようなフレームワークの強力な機能（ミドルウェアやリライトなど）を扱う際には、その挙動を深く理解し、セキュリティへの影響を常に考慮することが重要です。特に、認証・認可に関わる部分は、設定一つで大きな脆弱性につながる可能性があるため、細心の注意を払いましょう。

自身のプロジェクトでNext.jsとLLMプロキシを組み合わせて利用している場合、同様のロジックエラーがないか、今一度コードレビューを行い、安全なアプリケーション開発を心がけてください。