Next.jsのセキュリティパッチは、単にバージョンを上げるだけでは終わりません
makedream14 мая 2026 г.
0
Computing/SoftwareRelated Video
16:03NextJSはもう終わりだ… 13件の「致命的な」脆弱性が発覚
Better Stack
Comments (0)
Log in to leave a comment
No posts yet
makedream16:03makedream16:03Better Stack
Log in to leave a comment
No posts yet
セキュリティ専門スタッフがいないチームにとって、Next.jsの脆弱性のニュースは途方に暮れるものです。すぐにサービスを止めるわけにもいかず、かといってパッチを後回しにするのも不安ですよね。単に npm update を実行するだけですべての問題が解決するわけではありません。自分のコードのどこかに潜んでいる穴を自ら見つけ出し、塞ぐ必要があります。デプロイ後にサービスをダウンさせることなく、セキュリティを確保するための実務的な対応方法をまとめました。
自分がインストールしたライブラリが使用している「子パッケージ」に脆弱性が発生すると厄介です。上位ライブラリがアップデートされるまで待つのはあまりに危険です。このような場合は、依存関係ツリーの中間に介入して、バージョンを強制的に固定する必要があります。
まず、ターミナルで npm list <脆弱なパッケージ名> を実行してください。どのような経路でそのパッケージが導入されたのかを、自身の目で確認する必要があります。原因が特定できたら、package.json に overrides (npm) や resolutions (yarn) フィールドを追加します。ここにセキュリティが解決されたバージョンを明示すれば、パッケージマネージャーが下位の依存関係までスキャンして、該当するバージョンに置き換えてくれます。package-lock.json を開いて、実際にバージョンが変更されたかを確認するプロセスまで終えてこそ、安心できます。
Next.jsのサーバーアクションやAPIルートで外部データを取得する際、SSRF攻撃にさらされやすくなります。攻撃者がURLパラメータに 169.254.169.254 のようなクラウドのメタデータアドレスを入れると、サーバーは素直に内部の認証情報を読み取って渡してしまいます。インフラの設定を変更するのは手間がかかるため、コードレベルで入り口を狭める必要があります。
標準の fetch をそのまま使わず、IP帯域を検査するロジックを組み込んでください。dns.lookup でホスト名をIPに変換した後、そのアドレスがプライベートネットワーク帯域（10.0.0.0/8, 192.168.0.0/16 など）に属していないかチェックします。社内ネットワークのアドレスであればリクエストを即座に遮断するカスタム関数を作成し、すべてのサーバーサイドの呼び出しに適用してください。インフラチームに依存せず、データ流出事故を防ぐ最も確実な方法です。
CVE-2025-29927 の脆弱性は、ミドルウェアのパス処理ロジックを揺さぶり、認証をパスしてしまう手法を用います。特に多言語設定（i18n）を使用している際、URLに特殊な文字を混ぜるとマッチングロジックが混乱することがあります。
middleware.ts で受け取るすべてのパスは、正規化（normalization）を経る必要があります。重複したスラッシュを削除し、許可された言語コード（ko, en など）のリストと照合するホワイトリスト方式を導入してください。リストにないリクエストは、即座に 400 エラーを返すようにします。また、外部から流入する x-middleware-subrequest のような内部用ヘッダーは、プロキシサーバーの段階で削除するように設定してください。ビジネスロジックには手を加えずに、権限回避攻撃を退けることができます。
React 19で使用されるデータ転送方式は複雑です。CVE-2026-23869のように、循環参照が含まれたデータを送信してサーバーのCPUを100%に急上昇させる攻撃が可能です。コードを修正する前に、まずはサーバーの入り口で物理的な制限をかける必要があります。
Nginxのようなリバースプロキシで、client_max_body_size を 128k 程度に大幅に縮小してください。一般的なAPIリクエストであれば、この程度で十分です。特に Content-Type: text/x-component ヘッダーが付いたリクエストは、より厳密にレートリミットをかけるべきです。サーバーが異常なデータを読み取って時間を浪費するのを防ぐため、タイムアウトは30秒以内と短めに設定するのが望ましいです。
セキュリティパッチをデプロイしたものの、肝心の決済ページが開かなくなってしまっては困ります。パッチ適用後は、実際の攻撃者が行いそうな行動をテストコードで回すべきです。Playwrightを使うと便利です。
認証なしで管理者ページにアクセスしたり、APIパラメータに localhost アドレスを入れてみたりするシナリオを作成してください。この際、システムが 200 OK ではなく 403 や 400 レスポンスを返すことを確認するアサーションを追加します。このテストを CI/CD パイプラインに組み込めば、次回のアップデート時に誤ってセキュリティロジックを削除してしまうといった不祥事を防ぐことができます。完璧なセキュリティはありませんが、自分が書いたコードの入り口を一つずつ閉じていく習慣は、専門のセキュリティチームよりも強力な防衛線となります。