Next.js: セキュリティの崩壊

Vercelからの厳しい発表を受け、開発者コミュニティに新たなパニックの波が押し寄せました。13の新たなCommon Vulnerabilities and Exposures (CVEs) がNext.jsとReactに同時に影響を与えたのです。2026年5月の変更履歴で詳述されたこの前例のないセキュリティリリースは、無数の本番アプリケーションを即座に危険に晒しました。膨大な数の欠陥により、Better Stackチャンネルのような著名な声が「I'm Done With NextJS...」と宣言し、開発者の広範な不満を示しました。

Severity 評価は厳しい状況を示していました。これらの脆弱性のうち6つは「高」severity 分類を受け、緊急の対応が求められました。重大な欠陥には、複数のDenial of Denial of Service of Denial of Service ベクター、深刻なServer-Side Request Forgery (SSRF) エクスプロイト（一部は最高 severity と評価）、および様々なCross-Site Scripting (XSS) の機会が含まれていました。これらは理論的な弱点ではなく、攻撃者がユーザーデータを侵害し、Denial of Servicesを無効にし、セキュリティ対策を回避するための具体的な経路でした。

これらのCVEsの影響は、複数の最近のNext.jsバージョンに及び、事実上すべての現行プロジェクトにとって即時のアップグレードが不可欠となりました。パッチは、server-side propsを露呈させたPages Routerにおける7.5/10 severity のi18n脆弱性のようなmiddleware bypassから、キャッシュポイズニング、その他の巧妙な問題まで、多岐にわたる問題に対処しました。Vercelの解決策は明確でした。露出を軽減するために、すべてのNext.jsインストールを遅滞なく更新することです。

この最新のセキュリティ爆弾は、Reactエコシステム内で根強く、不穏な議論を再燃させました。サーバーコンポーネントは間違いだったのか？多くの重大な脆弱性、特に7.5/10 severity のDenial of Denial of Service of Denial of Service 攻撃は、サーバーコンポーネントの基盤となるシリアライゼーションフォーマットであるReact Flight Protocolに直接起因しています。これは今年3度目となるサーバーコンポーネント関連のCVEsの大きな波であり、このパラダイムの根本的なセキュリティアーキテクチャについて深刻な疑問を投げかけています。React Server DOMパッケージを避けるTanStack Startのようなフレームワークは影響を受けておらず、セキュリティプロファイルの相違が拡大していることを浮き彫りにしています。

重大なi18n middleware bypassにより、Next.jsのPages Routerで構築されたアプリケーションが不正なデータアクセスに晒されました。10段階中7.5 severity のCVEとして特定されたこの欠陥は、機密性の高いサーバーサイドデータを保護するために設計された認証ロジックを攻撃者が回避することを可能にしました。この脆弱性は、Next.jsの国際化 (i18n) 機能を利用するアプリケーションに特に影響を与えました。

このバイパスを悪用するには最小限の労力しか必要ありませんでした。攻撃者はまず、レンダリングされた任意のページの`_next/data`スクリプト内に通常見られる、アプリケーション固有のbuild IDを取得しました。このIDを使用して、`getServerSideProps`にデータ取得を依存するページをターゲットとする、`/_next/data/[build ID]/[page].json`のような直接URLを構築することができました。この直接アクセスにより、ページのデータペイロードがJSONとして取得され、アプリケーションのmiddlewareに実装された認証チェックが完全にバイパスされました。

根本原因分析により、Next.jsのi18n統合内のロジックに欠陥があることが判明しました。i18nが有効になっている場合、フレームワークのmiddleware matcherは、ページのベースルート（例：`/secret`）を適切に保護できませんでした。`/en/secret`や`/fr/secret`のようなロケール固有のバリアントは正しくmiddleware認証をトリガーしましたが、生の非ローカライズデータエンドポイントは保護されないままでした。これにより、本来保護されている情報への直接アクセスを許す大きな穴が生まれました。

`getServerSideProps`を介して機密情報を渡すアプリケーションにとって、その影響は甚大でした。未承認のユーザーは、ログインせずにユーザーのメールアドレス、内部フラグ、独自のヘッドラインなどの機密データを取得できました。これは中核的なセキュリティの前提を損ない、わずかな設定ミスが本番環境で深刻なデータ漏洩につながる可能性を示しました。

最近のi18n middlewareバイパス（深刻度7.5のCVE）は、多くのNext.jsアプリケーション内に存在する、より根深いアーキテクチャ上の脆弱性を露呈させました。開発者はmiddlewareを決定的なセキュリティ境界だと誤解することが多く、この誤解は「I'm Done With NextJS」という動画によって直接的に異議を唱えられています。Next.jsのドキュメント自体も、重要な認証にmiddlewareのみに依存しないよう忠告しています。

Middleware関数は、設計上、主にリクエストの変更、リダイレクト、または基本的なアクセス制御のために機能します。これらはエッジ層で動作するため、i18nの脆弱性やデータ取得エンドポイントへの直接アクセスのような特定のバイパスベクトルに対して脆弱です。この固有の制限は、堅牢なアプリケーションセキュリティのためにdefense-in-depth戦略を要求します。

真のセキュリティは、初期のリクエストパイプラインだけでなく、すべての層でのチェックを必要とします。サーバーサイドAPIルートおよび`getServerSideProps`または`getStaticProps`関数内に、包括的な認証と認可を直接実装してください。これにより、middlewareが失敗したりバイパスされたりしても、機密データは明示的なサーバーレベルの検証によって保護されます。

重要な認可をmiddlewareのみに依存することは、危険な脆弱性を生み出します。攻撃者はバイパスを悪用して以下を行う可能性があります。 - `_next/data` JSONペイロードから、メールアドレスや内部フラグなどの機密性の高いユーザーデータにアクセスする。 - ロールベースのアクセス制御を回避し、管理インターフェースへの不正な侵入を果たす。 - アプリケーションの状態を操作したり、通常は認証されたユーザーに制限されているアクションを実行したりする。

このような脆弱性がウェブアプリケーションにどのような影響を与えるかについての詳細な情報については、Security Update: Multiple vulnerabilities in Next.js and React - Netlifyのようなリソースを参照してください。この多層的なアプローチは、単一障害点がアプリケーション全体の整合性を損なうことを防ぎます。

攻撃者はまた、Next.jsサーバーコンポーネントおよびReact Server DOMパッケージを利用するあらゆるフレームワークを標的とした、重大なDenial of Denial of Service of Denial of Serviceの脆弱性を発見しました。この欠陥は10段階中7.5の深刻度評価が割り当てられており、最小限の労力でアプリケーションを著しい速度低下にさらします。Next.jsアプリケーションで最も単純なサーバーアクションを使用している開発者でさえ、脆弱でした。

エクスプロイトのメカニズムは、サーバーに大量に肥大化したペイロードを送信することを含みます。攻撃者は、React Flight Protocol の逆シリアル化フェーズ中にサーバーの処理能力に負荷をかけるように特別に設計された、何千ものキーとポインタを含むリクエストを作成します。このプロトコルは、React がサーバーとクライアント間でコンポーネントツリーとデータをシリアル化する方法を標準化します。

この一見無害なデータ構造は、アルゴリズムの破綻を引き起こします。逆シリアル化プロセスは、このような過度に大きく複雑なペイロードに直面すると、文字列比較の二次的な複雑性 (K * N) に陥ります。これにより、単一の不正なリクエストに対して驚異的な2億回の操作が発生し、予想される処理負荷をはるかに超えます。

その影響は即座かつ深刻です。通常わずか0.02秒で解決するリクエストが、1回のエクスプロイト実行後には6秒にまで伸びます。このようなリクエストを複数連鎖させることで、サーバーのスレッドを効果的にブロックし、アプリケーションを応答不能にし、正規のユーザーがアクセスできない状態にすることができます。

ReactとNext.jsのエンジニアは、React Flightプロトコル内の Denial of Service (DoS) 脆弱性を軽減するために、洗練されたパッチを迅速に開発しました。このエクスプロイトは以前、攻撃者が単一の悪意を持って作成されたリクエストでサーバーを過負荷にすることを可能にしていました。この修正は主に、以前は複雑なデータ構造に苦慮していた逆シリアル化プロセスを対象としました。

開発者は、受信データストリームを逆シリアル化するための斬新な カーソルベースシステム を実装しました。この独創的なアプローチは、プロトコルの複雑なコンポーネントツリーとデータを驚くべき効率で処理します。ペイロード全体を複数回解析する代わりに、カーソルシステムはデータをインテリジェントにナビゲートし、リソース使用量を最適化します。

このエンジニアリングの偉業は、計算複雑度を劇的に改善しました。古い逆シリアル化方法は、ネストされたオブジェクトの深さをK、アイテムの総数をNとするK * Nの複雑度に悩まされ、指数関数的な速度低下を引き起こしていました。新しいシステムは、N + Kで動作する非常に効率的な線形複雑度を達成しました。この根本的な変化は、サーバーがペイロードを処理する方法を根本的に変えました。

パフォーマンスとセキュリティへの影響は即座かつ甚大でした。ベンチマークは、悪意のあるペイロードに対する操作の驚異的な削減を明らかにしました。以前は2億回以上の操作を引き起こし、サーバーを限界まで追い込んでいたものが、現在では約20万回の操作しか必要としません。この決定的な行動は、DoSの脅威を効果的に無力化し、React Flightプロトコル上に構築されたアプリケーションを同様の攻撃から保護しました。

数ある脆弱性の中で、最も高い深刻度スコアである8.6/10の Server-Side Request Forgery (SSRF) が、自己ホスト型Next.jsアプリケーションに影響を与えるものとして際立っていました。この重大な欠陥は、信頼の深刻な侵害を表しており、攻撃者が公開サーバーを内部偵察および悪用のための無意識の共犯者に変えることを可能にしました。

SSRFは、サーバーを根本的に騙して、攻撃者の代わりに、通常はアクセスできない内部サービスに対してリクエストを行わせます。堅牢なファイアウォールによって通常保護されているサーバーが、外部の悪意のあるアクターのコマンドによって、突然自身の内部データベース、キャッシュ層、またはプライベートAPIに接続している状況を想像してみてください。これがSSRF攻撃の本質です。

このNext.jsの脆弱性の悪用は驚くほど簡単であることが判明しました。攻撃者は`Upgrade: websocket`ヘッダーとカスタムリクエストターゲットを含む`curl`リクエストを作成しました。この一見無害な組み合わせは、サーバーを操作してその内部ネットワーク内で任意の接続を開始させ、外部防御を迂回させました。

このSSRFによってもたらされた危険は壊滅的でした。これは直接的なファイアウォールバイパスを提供し、攻撃者に組織の最も機密性の高いインフラストラクチャへの比類のないゲートウェイを与えました。通常は隔離され保護されている内部データベース、Redisインスタンス、その他のプライベートAPIが、侵害されたNext.jsアプリケーションを通じて直接公開されました。

この脆弱性は、攻撃者が内部ネットワークをマッピングし、機密データを抽出し、あるいはそれらのDenial of Servicesに直接触れることなく内部システムでアクションをトリガーできることを意味しました。アプリケーションのセキュリティ確保に関するさらなるガイダンスを求める開発者向けに、Guides: Data Security - Next.jsのようなリソースが貴重な情報を提供しています。悪用の容易さと深い内部アクセスへの可能性が相まって、このSSRFはNext.jsのセキュリティリリースにおいて最も懸念される開示の一つとなりました。

Better Stackのビデオ「I'm Done With NextJS... 13 NEW vulnerabilities」は、サーバーコンポーネントは間違いだったのかと挑発的に問いかけました。この問いは、React Server Components (RSCs) の本質的なセキュリティオーバーヘッドに関する開発コミュニティ内の高まる懸念を具体化しています。このパラダイムシフトは、アーキテクチャの複雑性の否定できない増加と攻撃対象領域の拡大という、重大な「セキュリティ税」をもたらします。

RSCsの実装は、従来のHTTPリクエスト・レスポンスサイクルを超えて、サーバーとクライアントの契約を根本的に再定義します。この新しいモデルは、多くの場合カスタムプロトコルを通じて、データのシリアライゼーションとデシリアライゼーションの細心の注意を払った処理を必要とします。ビデオで引用されたPrimeagenの痛烈なツイートは、この課題を完璧に要約しています：「カスタムシリアライゼーションプロトコルを作るのは難しい。」RSCsの中核であるReact Flightプロトコルは、まさにそのようなカスタムレイヤーとして機能し、その複雑な性質が堅牢で安全な実装を極めて困難にしています。

最近の13のCVEの分析は、明確なパターンを明らかにしています。多くの脆弱性、特に重大なDenial of Denial of Service of Denial of Serviceの欠陥は、RSCsの斬新なアーキテクチャとFlightプロトコルの複雑さに直接起因しています。例えば、DoS脆弱性はRSCsの基礎的な要素である`React Server DOM`パッケージを悪用しました。これは従来のAPIバグではなく、コンポーネントツリーとデータがサーバーとクライアント間でどのようにストリームされるかを利用しました。

このパターンは、サーバーとクライアントのロジックを曖昧にするシステムに内在する独自のセキュリティ課題を浮き彫りにします。ミドルウェアバイパスは、Flightプロトコルの直接的な問題ではありませんが、i18nのような機能を伴う新しいルーティングパラダイムが、複雑なフレームワークにおいて予期せぬ攻撃ベクトルをどのように導入しうるかを示すことで、全体的な「セキュリティ税」に貢献しています。開発者は今や、従来のHTTPリクエスト検証だけでなく、コンポーネントのシリアライゼーションとハイドレーションの奥深くにある脅威を考慮しなければなりません。これは、より高いレベルの精査とスタック全体にわたる潜在的なエクスプロイトのより広範な理解を要求し、セキュリティ分析の負担をアプリケーションのはるかに深く、より抽象的なレベルへと移行させます。

TanStack Startは、最近のNext.jsの脆弱性の波から完全に無傷で出現しました。Next.jsが、重要なミドルウェアのバイパスやServer-Side Request Forgeryを含む13のCVEに苦しむ中、TanStack Startは影響を受けませんでした。この顕著な対照は、フレームワークのアーキテクチャとそのセキュリティ体制への直接的な影響に関する重要なケーススタディを提供します。

この違いは、根本的な設計思想にあります。Next.jsは、「マジック」を通じて開発者の利便性を優先し、サーバー境界や暗黙的なデータフローを抽象化することがよくあります。このアプローチは強力である一方で、React Flight protocolやi18nルーティングのような基盤となるメカニズムが予期せぬ動作をする場合に、隠れた攻撃対象領域を導入する可能性があります。

対照的に、TanStack Startは、明確に定義されたローダーとアクションを備えた、明示的で型安全なアプローチを提唱しています。開発者はサーバーサイドの操作を明示的に宣言し、サーバーとクライアントの境界を曖昧にしません。このアーキテクチャの明確さは、フレームワークの動作が開発者の期待とより予測可能に一致するため、設定ミスや意図しないデータ漏洩の可能性を最小限に抑えます。

「マジック」を減らすフレームワークは、開発者にデータフローと実行環境に直接向き合わせることで、セキュリティを強化することがよくあります。TanStack Startの設計選択は、明示的なサーバー関数と堅牢な型チェックを強調することで、本質的に、より安全で監査可能な開発体験を育みます。この予測可能性は、最近のセキュリティリリースでNext.jsを悩ませた種類のバイパスやデータ漏洩の脆弱性に対する強力な防御となります。

最終的に、これはあるフレームワークの全体的な優位性を宣言するものではなく、アーキテクチャに関する教訓です。TanStackが無傷であったことは、明示的な設計、明確なサーバー境界、および堅牢な型安全性がいかにフレームワークの攻撃対象領域を劇的に減らすことができるかを強調しています。これは、開発者とフレームワークの作者双方に、利便性と制御のセキュリティ上の影響を考慮するよう促します。

Next.js開発者は緊急の義務に直面しています。最近の13のCVEの開示は、アプリケーションとユーザーデータを保護するための即座の断固たる行動を要求します。ミドルウェアのバイパスやServer-Side Request Forgeryのような問題の深刻さを考えると、先延ばしは許容できないリスクをもたらします。

まず、現在のNext.jsとReactのバージョンを正確に特定してください。この基本的なステップは、最近パッチが適用された脆弱性への露出レベルを決定します。`npm list next`と`npm list react`を使用するか、`package.json`を調べて、これらの重要な依存関係を確認してください。

影響を受けるすべてのアプリケーションをパッチ適用済みのバージョンに直ちにアップグレードしてください。Next.js 15.5.18以降、およびReact 19.0.6以降を対象としてください。これらのリリースには、React Flight protocolを介したDenial of Denial of Service of Denial of Serviceを含む、広範囲にわたるセキュリティ上の欠陥に対する重要な修正が含まれています。このような脆弱性に関するさらなる技術的な詳細については、CVE-2026-23864: React and Next.js Denial of Denial of Service of Denial of Service via Memory Exhaustion | Akamaiのようなリソースを参照してください。

アプリケーションコードの徹底的な監査を実施し、セキュリティがフレームワークの抽象化に依存している領域に焦点を当ててください。ミドルウェアロジックに特に注意を払い、認証および認可のチェックが堅牢であり、i18nの欠陥のようなバイパスの影響を受けないことを確認してください。データ取得パターンを厳密に調査し、Server-Side Request Forgeryやその他のデータ漏洩リスクを防ぐためです。

アーキテクチャ上のリスクと将来のフレームワークの選択について、包括的なチームディスカッションを開始してください。このインシデントは、表面的なAPIの使用を超えた深いセキュリティ理解の必要性を浮き彫りにしています。現在のフレームワークの選択が、組織のセキュリティ体制とリスク許容度と一致しているかどうかを評価してください。

最近明らかになった事実、特にNext.jsとReactに影響を与える前例のない13のCVEの大量発生は、Web開発にとって重要な岐路を示しています。この出来事は、現代のアプリケーション構築を支配するようになったアーキテクチャパラダイムの根本的な再評価を強いるものです。巧妙なミドルウェアのバイパスから深刻なServer-Side Request Forgeryに至るまで、脆弱性の広範さは内省を促します。

統合されたサーバー駆動型UIフレームワークは、比類のない開発者エクスペリエンスとパフォーマンスを約束しますが、意図せず基本的なセキュリティベストプラクティスを追い越してしまったのでしょうか？React Flightプロトコルを介して単一の不正なリクエストがDenial of Denial of Service of Denial of Serviceを引き起こしたり、i18nの設定ミスが機密性の高いサーバーサイドプロパティを公開したりする場合、「サーバーコンポーネントの『セキュリティ税』」という説は大きな重みを持つようになります。

開発者はサーバーとクライアントのロジックを統合する利便性を受け入れましたが、この密接な結合は本質的に新たな攻撃対象領域を生み出します。何がどこで、どのようなコンテキストで実行されるかの境界が曖昧になることで、現在のセキュリティモデルでは完全に対処できない複雑さが導入されます。これにより、堅牢な脅威モデリングがこれまで以上に困難になります。

将来の開発では、明示的で分離されたアーキテクチャに新たな重点が置かれるかもしれません。クライアントとサーバー間の明確な境界、おそらく明確に定義されたAPI契約と個別のセキュリティドメインを持つことが、セキュリティ推論を簡素化し、システムリスクを低減する方法として再び支持される可能性があります。シンプルさはしばしばセキュリティと直接相関します。

逆に、Next.jsのようなフレームワークは成熟し安定し、より堅牢なセキュリティプリミティブを組み込み、より厳格でプロアクティブな監査を受ける可能性があります。React FlightプロトコルのDenial of Denial of Service of Denial of Service脆弱性に対して実装された巧妙なエンジニアリング修正は、プレッシャーの下での迅速かつ効果的な修復能力をチームが持っていることを示しています。

TanStack Startがこれらの広範な脆弱性から著しく免れていることは、説得力のある代替視点を提供します。そのアーキテクチャ上の選択、特にReact Server DOMパッケージを避けていることは、異なる設計哲学が本質的に異なるセキュリティプロファイルを生み出すことを示唆しています。これは、フレームワークアプローチの多様性に対する強力な議論となります。

エコシステムが最終的にどのような道を進むにせよ、このエピソードは厳しい教訓となります。セキュリティは後回しにすることはできません。すべてのアーキテクチャ上の決定に異議を唱え、すべての依存関係を精査し、次のプロジェクトの最初のコード行から回復力のあるセキュリティ体制を優先してください。責任はすべての開発者にあります。

2026年5月リリースで最も重要なNext.jsの脆弱性は何ですか？

最も重要な脆弱性には、高深刻度のServer-Side Request Forgery (SSRF) (8.6/10)、複数のMiddleware Bypasses (7.5/10)、およびReact Flightプロトコルを標的としたDenial of Service (DoS)攻撃 (7.5/10)が含まれます。

React Server Components (RSCs)は本質的に安全ではないのですか？

RSCsは本質的に安全ではないわけではありませんが、攻撃対象領域を大幅に拡大する新しい複雑なパラダイムを導入します。この『セキュリティ税』は、安全でないデシリアライゼーションのような脆弱性を防ぐために、フレームワークの作者と開発者の両方により一層の注意を要求します。

これらの脆弱性からNext.jsアプリケーションを保護するにはどうすればよいですか？

唯一保証された修正策は、公式の Vercel セキュリティアドバイザリで指定されているパッチ適用済みのバージョンに、Next.js および React の依存関係を直ちにアップグレードすることです。WAF だけに頼るのは十分ではありません。

TanStack Start はこれらの Next.js の脆弱性の影響を受けましたか？

いいえ、TanStack Start は React Server DOM パッケージや Next.js と同じアーキテクチャパターンを使用していないため、これらの特定の CVE の影響を受けませんでした。これは、より明示的な設計によるセキュリティ上の利点を強調しています。