Next.jsの重大な脆弱性を修正！画像最適化とキャッシュ処理の影響を点検

Next.jsの開発元は2026年10月14日、画像最適化とキャッシュ処理に関する重大な脆弱性、およびServer Actionsに関するサービス妨害の問題を公表しました。修正を含む16.4.1が公開され、15系には画像最適化とサービス妨害の修正版15.5.28が案内されています。Webアプリケーションを運用している担当者は、ソースコードの変更だけでなく、本番で動いている依存関係とデプロイ成果物を確認する必要があります。

本記事は10月17日に一次資料を確認して整理した更新情報です。脆弱性の公表日を当日の新事件として扱うものではありません。参照した告知から実環境での悪用や攻撃開始日は確認できておらず、AIが攻撃に使われたとも断定しません。対象条件を示す開発元の説明と、本サイトが提案する確認手順を分けて解説します。

今回の更新で区別したい三つの問題

開発元のSVG画像最適化に関する告知では、glibcを使うLinux上のNext.jsで、画像最適化に用いる上流ライブラリのメモリ関連の問題から、リモートコード実行につながる可能性が示されています。識別子はCVE-2026-96889、評価はCritical、CVSS v4で9.5です。修正版は15.5.28と16.4.1で、この問題の回避策としてNext.jsが使用するsharpを0.35.5以上にする方法も案内されています。

開発元のuse cacheに関する告知は別の問題です。App RouterとCache Componentsを使い、複数のTypedArrayを返すuse cache関数があるアプリケーションで、リモートコード実行につながると説明されています。対象は16.0.0〜16.4.0、修正版は16.4.1です。評価はCritical、CVSS v4で9.5。確認時点の告知にCVE番号はなく、該当する関数がある場合の既知の回避策も示されていません。

開発元のServer Actionsに関する告知では、App Routerで少なくとも一つのServer Actionを使うアプリケーションに対し、細工したリクエストがCPUを過剰に消費し、同じプロセスの後続リクエスト処理を妨げるとされています。評価はHigh、CVSS v4で8.2、修正版は15.5.28と16.4.1です。Pages Routerのみ、またはServer Actionsを使わない構成はこの問題の対象外とされ、更新以外の回避策は案内されていません。

Next.js 16.4.1の公式リリース情報でも、上記のCritical二件とHigh一件の修正を確認できます。三件は影響する機能も対処の条件も異なります。「画像を使っていないからすべて対象外」「sharpだけ変えれば全部直る」とまとめず、個々の告知を自分の構成と照合してください。

ブラウザーの表示機能でも処理場所はサーバーにある

画面に画像やフォームがあると、危険がブラウザーの中だけに閉じるように感じるかもしれません。しかし運用上の確認では、入力を受け取る場所、画像を加工する場所、結果を保存・再利用する場所を分ける必要があります。ページが正常に表示されることは、その処理を担当するサーバーが修正版になっている証拠にはなりません。

今回の画像最適化の問題では、まず実行環境と依存ライブラリを確認する視点が重要です。Linuxという大きな分類だけで判断せず、実際のコンテナーやホストがどの構成か、どのsharpを読み込むかを把握します。Macの開発環境で不具合が再現しないことを、Linuxの本番環境が安全である根拠として扱わないでください。

キャッシュの問題とサービス妨害の問題では、使っているルーターと機能を確認します。アプリケーションの一部だけが新しい構成へ移行している場合もあるため、古い設計書より現在の設定とコードを優先します。ただし自前の検索だけで完全な対象外を証明しようとせず、開発元が勧める更新を軸に判断することを本サイトは提案します。

最初の確認はリポジトリーより稼働中のアプリから

本サイトが提案する初動は、公開中のアプリケーションを一覧にして、各環境の責任者と現在のデプロイを結びつけることです。一つのリポジトリーから複数サイトを配信していたり、同じサイトに複数のコンテナーが残っていたりする場合、開発者の手元だけを更新しても確認が完了しません。

• 本番・検証・プレビューの各環境と、外部から到達できる入口を確認する。
• 稼働するNext.jsの版と、対応するロックファイル・コミット・イメージを記録する。
• 画像最適化の実行環境とsharpの解決結果を確認する。
• App Router、Cache Components、Server Actionsの利用箇所を把握する。
• 更新を担当する人、展開先、確認予定を一つの作業記録にまとめる。

依存関係の確認には、使用しているパッケージマネージャーの表示機能を使います。たとえばnpm環境ならnpm ls next sharpの出力が調査の入口になります。ただし、モノレポのどの作業ディレクトリーで実行したか、開発用のnode_modulesか、本番の成果物かによって意味が変わります。コマンドが成功したことだけを更新完了に置き換えないでください。

管理画面やホスティングの表示だけで内部の実行環境が分からない場合は、提供元が管理する範囲と利用者が更新する範囲を確認します。本記事で全マネージド環境が影響を受けない、あるいは自動で対処済みだとは判断していません。サービスの名前だけで除外せず、その環境の公式案内と実際の依存関係を照合します。

更新はロックファイルから本番への反映まで追う

更新作業では、修正版を指定した変更、依存関係の解決、ビルド、テスト、配信を一続きで追跡する方法を提案します。package.jsonの指定を書き換えただけでは、既存のロックファイルや再利用されたビルド成果物との関係が分かりません。逆に、ロックファイルを理由なく削除すると無関係な依存まで大きく変わり、問題の切り分けが難しくなります。

利用中のリリース系列と互換性を確認し、必要な更新を限定して行います。開発元が示す修正版は今回の問題を修正した版の情報であり、その後の更新も含めた運用上の最適な版を永続的に保証するものではありません。導入時点で追加のセキュリティ告知やサポート方針がないかも確認してください。

コンテナー運用なら、新しいイメージを作成した時点と、全稼働インスタンスがそれを使う状態を分けて記録します。ローリング更新中に旧版が残る、停止していた処理が古いイメージで再開する、といった状況も確認対象です。これは今回の脆弱性で特定の配信基盤に問題があるという報告ではなく、更新漏れを避けるための運用上の提案です。

sharpの回避策をほかの問題へ広げない

三件をまとめて対応するなら、Next.js自体の修正版への更新を中心に進める方が、対応範囲を説明しやすくなります。画像処理の依存だけを先に直す場合には、どの告知への対処なのかを作業記録に明記してください。一件の回避策を適用したという記録が、三件すべての完了報告へ変わらないようにします。

たとえば、説明用の仮想例として、画像処理を含むサービスAと、Server Actionsで問い合わせを処理するサービスBが同じ管理表に載っているケースを考えます。Aのsharpを確認できても、Bのサービス妨害への対処が済んだことにはなりません。機能別の影響条件と、サービスごとの修正版導入を交差させて確認する必要があります。

WAF、レート制限、外部への通信制限などは運用全体の防御に役立つ場合がありますが、それぞれの告知で修正と同等の対処だと保証されているわけではありません。暫定的に公開範囲を縮小するなら、業務影響、期限、担当者を記録します。独自のフィルターを入れたことだけで、更新を無期限に延期しないようにしてください。

更新後のテストは正常な操作から始める

公開環境に攻撃用リクエストを送って安全性を確かめる必要はありません。検証環境で通常の画像表示、画像サイズ変更、キャッシュを使うページ、Server Actionsを通る操作を確認し、次に本番の少数の正常操作と監視値を確認する手順を提案します。テスト用データと外部通知先を用意し、課金・メール送信・本番データの変更を不用意に発生させないようにします。

動作確認の記録には、確認したURLや機能、時刻、成果物の識別子、担当者を残します。画像の表示崩れ、応答時間、CPU使用率、エラーログの変化などを見ますが、正常に動いたという結果だけで脆弱性が存在しないと証明したことにはなりません。修正版の導入確認と機能の回帰確認は別の証跡として扱います。

また、問題が起きた際に戻すための旧イメージが脆弱な版なら、単純なロールバックで元のリスクも戻ります。不具合の範囲を限定し、修正済みの代替成果物や一時停止を選べるようにしておくことを提案します。復旧手順の存在だけでなく、戻し先がセキュリティ上どの状態かも確認します。

侵害の有無と更新の完了は別々に判断する

今回確認した一次資料から実際の悪用を確認できなかったため、本記事では「悪用なし」とも「悪用確認済み」とも断定しません。自組織で不審なプロセス、通常と異なる外向き通信、想定外のファイル変更などが見つかった場合は、更新作業とは別にインシデント対応へ引き継いでください。

更新を済ませても、過去に起きたことが消えるわけではありません。一方、影響条件に該当したという理由だけで認証情報の窃取まで断定することもできません。疑わしい事象がある場合はログと成果物を保全し、アプリケーションが持つ権限や秘密情報の範囲を担当者と調べます。調査前にログを消したり、証跡を上書きする作業を急いだりしないことが大切です。

今回の更新では、画像処理、キャッシュ、Server Actionsという異なる入口を分けて確認することが要点です。修正版の版数を読むだけで終わらせず、稼働する成果物、利用機能、展開完了、通常動作の確認までを追ってください。以下は実際に本文を開いて確認した開発元の一次資料です。