Next.jsのCVE対応は誰がやるのか｜2026年8月の緊急パッチから考えるバージョンアップ運用と外注

2026年8月25日、Next.js は 16.3.3(Active LTS)と 15.5.24(Maintenance LTS)を対象にした緊急のセキュリティリリースを公開しました。2件とも「重大(Critical Severity)」に分類される脆弱性で、片方は認証なしにリモートコード実行が可能というレベルのものです。

この記事を書いている今も、社内のNext.jsシステムがこのパッチを当てているかどうか即答できない、という方は少なくないはずです。それ自体は珍しいことではありません。問題は、「今回はたまたま気づいた」を繰り返すのか、「気づく仕組み」を作るのかの分岐点に、実はどの中小企業も立っているということです。

先に、要点をまとめます。

• 2026年8月25日、Next.js は AVIF画像最適化の脆弱性(GHSA-2xp9-vwfh-vxw4)と、Windows環境でのパストラバーサル脆弱性(CVE-2026-75604)という2件の重大(Critical)脆弱性に対応した v16.3.3 / v15.5.24 を公開しました
• CVE対応は「検知」「影響範囲の判定」「検証環境での適用」の3工程に分解でき、この3つを数日以内に回せるかどうかが、内製で運用するか保守を外部に委ねるかの分かれ目です
• 2026年は5月・7月・8月と大型のセキュリティリリースが続いており、単発の対応で終わらせず「バージョンアップ運用」として仕組み化する必要があります

なお、Next.jsのセキュリティ対策全般(認証・入力検証・環境変数管理など)は中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するかで扱っています。本記事は「パッチが出た後、誰が・どう当てるか」という運用面に絞って整理します。

2026年8月の緊急パッチで何が起きたのか？

AVIF画像の最適化機能とWindows環境のファイル処理に、それぞれ認証不要でリモートコード実行につながる重大な脆弱性が見つかり、緊急パッチが公開されました。

Next.js公式ブログの発表によれば、今回のリリースで対応された脆弱性は次の2件です。

対応バージョンは次の通りです。

npm install next@16.3.3   # 16.3系(Active LTS)
npm install next@15.5.24  # 15.5系(Maintenance LTS)

特にWindows環境で稼働しているサーバーは、公式ブログ上でも「既知の回避策はない(there is no known workaround)」と明記されており、該当する場合は即座のアップグレードが必要です。逆にLinux・macOS上でホスティングしている場合は2件目の影響は受けませんが、AVIF画像最適化を使っている場合は1件目が該当するため、いずれにせよパッチ適用の要否を確認する作業自体は避けられません。

この8月のリリースは単発ではありません。今年に入ってから、Next.jsは5月にもmiddleware.js/proxy.jsによる認可を迂回できる複数の脆弱性に対応した大型リリース(v15.5.18/v16.2.6)を行っており(Vercelのセキュリティリリース告知)、8月で少なくとも2度目の重大リリースということになります。フレームワークのメジャーアップデートが年に数回のペースで来る以上、脆弱性パッチも同じか、それ以上の頻度で来るという前提で運用を組む必要があります。

ただし、パッチが出たからといって闇雲に適用すればよいわけではありません。本文後半で、適用前に確認すべき手順を整理します。

CVE対応は誰の仕事なのか？

「気づいた人がその都度対応する」体制のままだと、担当者が休暇中や離任時に見落とされるリスクが構造的に残ります。検知・判定・適用の3工程を役割として明確にしておくことが第一歩です。

中小企業のNext.jsシステムでCVE対応が滞る典型的なパターンは、担当者不在ではなく「担当が曖昧なまま特定の一人に依存している」ケースです。開発を依頼した会社との契約が納品時点で終わっていて、パッチ情報を能動的に追いかける役割が誰にも割り振られていない、という状態は珍しくありません。

CVE対応を仕組みとして考えるときは、次の3工程に分けて捉えると整理しやすくなります。

1. 検知: Next.js公式ブログやGitHub Security Advisoriesを定期的に確認する、またはDependabotやSnyk等のツールで自動検知する
2. 影響範囲の判定: 公開された脆弱性が自社のシステム構成(使用しているルーター・ホスティングOS・機能フラグ)に該当するかを確認する
3. 検証環境での適用: パッチを検証環境に適用し、主要機能が壊れていないかを確認したうえで本番に反映する

この3工程のうち、特に見落とされやすいのが②です。今回のWindows向け脆弱性のように「特定の条件に該当する環境だけが対象」というケースは多く、「パッチが出た」というニュースだけを見て自社に関係あるかどうか判断できないまま放置される、という事態が起きがちです。逆に言えば、自社のホスティング環境(Vercel/AWS/Firebase App Hosting等)とルーター構成(App Router単独か、Pages Routerとの併用か)を正確に把握しているだけで、②の判定スピードは大きく変わります。

御社の場合、この3工程を誰が・どのくらいの頻度で回しているか、一度棚卸ししてみる価値があります。担当者名は決まっていても、実際に直近のパッチ(5月・7月・8月)の適用状況を答えられる人がいない、という状態であれば、それは「担当はいるが機能していない」状態です。

内製で運用するか、保守を外部に委ねるか、どう判断する？

①〜③の3工程を、パッチ公開から数日以内に確実に回せる体制があるかどうかが判断基準です。回せるなら内製、回せないなら保守契約で外部に委ねるのが現実的です。

「内製か外注か」を機能追加の話と同じ土俵で議論すると、判断を誤りやすくなります。CVE対応は機能開発と違って納期の融通が利きません。パッチが公開された時点で、脆弱性の内容自体が公知情報になるため、対応を先延ばしにするほど攻撃を受けるリスクが高まります。

内製での運用が現実的なのは、次のような条件がそろっている場合です。

• 社内に、Next.jsのアップデート内容を読んで影響範囲を判断できるエンジニアが継続的に在籍している(退職・異動で空白が生まれない体制)
• 検証環境(ステージング環境)が用意されていて、パッチ適用後の回帰確認を数時間〜1日程度で回せる
• 本番反映の意思決定を、経営者や情シス責任者の承認を待たずに、担当者の裁量である程度進められる

逆に、次のいずれかに当てはまる場合は、保守契約で外部に委ねたほうが結果的にリスクが下がります。

• 開発を依頼した時点で終わりにしていて、パッチ情報を能動的に追いかける担当が社内にいない
• 検証環境が無い、または本番環境としか呼べない環境でしか動作確認ができない
• エンジニアが1人しかおらず、その人が不在の間は誰も判断できない(いわゆる「1人情シス」のリスク)

この「内製か外注か」という問いそのものは、CVE対応に限らずNext.js開発全般で繰り返し出てくる論点です。判断基準の全体像は内製か外注か、中小企業がNext.jsで選ぶ基準でも整理しているので、パッチ対応以外の場面での判断にも参考にしてください。

当社の開発費用は1時間11,000円（税込）が基準です。ヒアリング後、ご依頼に応じて、要件定義・現状調査、相談内容のすり合わせ・仕様合意、開発・移行・公開準備、テスト・受入確認、不確実な作業へのバッファを当社で見積もり、概算をご案内します。お客様が開発工数を推測する必要はありません。

内製と外注、それぞれの向き・不向きを整理すると次のようになります。

表の「影響範囲の判定精度」は見落とされがちですが、実は外注時に最も注意すべき点です。保守を外部に委ねる場合、委託先が納品時のシステム構成をそのまま把握しているとは限りません。特に納品後に自社側で機能追加や構成変更を行っていた場合、委託先がその変更を知らないまま「パッチ対応済みです」という報告だけを受け取ってしまうと、実際には影響範囲の判定が不正確なまま進んでいるリスクがあります。保守契約を結ぶ際は、システム構成の変更があった場合に委託先へ共有するフローも合わせて決めておくことをおすすめします。

パッチを検証なしで即適用してはいけない理由

バージョンアップには破壊的変更が含まれることがあるため、検証環境での動作確認を経ずに本番へ直接適用するのは避けるべきです。

CVE対応というと「一刻も早くパッチを当てる」ことだけが強調されがちですが、検証を飛ばした適用にはもう一つのリスクがあります。マイナーバージョンアップであっても、内部の挙動変更によって既存機能が意図せず壊れることがあるためです。

たとえば今回のパッチのうち、AVIF画像最適化の脆弱性に対する対応は「AVIF最適化機能自体を無効化する」という形で行われています。つまりパッチを適用すると、AVIF形式の画像を扱っている箇所では、これまでと異なる挙動(最適化されない状態でのフォールバック)になる可能性があります。パッチを当てたことで新たな表示崩れが発生しては本末転倒です。

検証環境での確認手順としては、以下を最低限押さえておくと安全です。

1. パッチ適用前のバージョンで、主要な画面(トップページ・フォーム送信・認証が絡む画面)のスクリーンショットまたは動作ログを残す
2. 検証環境でパッチを適用し、同じ画面を確認する
3. 差分があれば、それが脆弱性対応による意図的な挙動変更か、想定外の不具合かを切り分ける
4. 問題がなければ本番環境に反映する

この一連の作業を、パッチ公開から本番反映までできれば1週間以内、遅くとも2週間以内に完了させるのが現実的な目安です。これより長くかかる場合、検証の手順自体が重すぎるか、判断を待つ承認フローがボトルネックになっている可能性があります。

Next.js 16.3自体の位置づけも押さえておく

8月25日の緊急パッチとは別に、Next.js 16.3は8月3日に正式リリースされており、開発体験・パフォーマンス面でも大きな変更が入っています。

やや紛らわしいのですが、今回の緊急パッチ(v16.3.3)は「Next.js 16.3」という比較的大きな機能リリース(8月3日公開)の、その後に出たセキュリティパッチという位置づけです。16.3の目玉機能であるInstant NavigationsについてはNext.js 16.3で受託開発は何が変わるかで詳しく解説しているので、あわせてご覧ください。Next.js公式ブログの16.3リリース記事によれば、16.3自体には次のような変更が含まれています。

• 開発サーバーのメモリ使用量が最大90%削減(ディスクキャッシュとメモリエビクションの標準有効化による)
• サーバーサイドレンダリングで、負荷時に処理できるリクエスト数が最大22%増加(WebストリームからNode.jsネイティブストリームへの置き換えによる)
• リピートビルドでキャッシュを再利用できるようになり、CI上のビルド時間が案件によっては大幅に短縮(公式の計測例では最大5.5倍)

これらは既存プロジェクトを16.3にアップグレードするだけで恩恵を受けられる変更です。8月の緊急パッチ対応で「とりあえず16.3.3にアップグレードした」というシステムは、意図せずこれらの改善も同時に受け取っていることになります。バージョンアップ運用を後回しにしていた企業ほど、こうした複数のリリースをまとめて追いかける必要が出てくるため、次回以降は個別のリリースごとに小さく対応していくほうが、1回あたりの検証負荷は軽くなります。

まずは、直近1週間分の自社システムのアクセスログか稼働状況を確認するところから始めてみるのがおすすめです。パッチ未適用のまま放置されている期間がどれくらいあるかを把握するだけでも、次に何をすべきかが見えてきます。

ゼットリンカーでの進め方

私たちがNext.jsで受託開発を行う際は、納品後の保守フェーズでこの検知・判定・適用の3工程をチームとして担う形を基本にしています。特に力を入れているのは、Claude Codeを使ったAI駆動開発の文化を保守フェーズにも持ち込み、パッチ適用後の回帰確認をAIエージェントに一次チェックさせることで、検証にかかる工数を圧縮する進め方です。人手だけで全画面を目視確認するのではなく、AIが変更差分の影響範囲を洗い出し、人間が最終判断する体制を取ることで、数日単位でのパッチ追従を無理なく回せるようにしています。

まとめ

この記事で持ち帰れることは、CVE対応を「気づいた人がその都度がんばる」属人的な作業から、検知・判定・適用の3工程として仕組み化して捉え直す視点と、その3工程を数日以内に回せるかどうかを内製・外注の判断基準にする考え方です。

• 2026年8月25日、Next.jsは2件の重大脆弱性に対応したv16.3.3/v15.5.24を公開しました。Windows環境は既知の回避策がないため優先度が高い対応です
• CVE対応は検知・影響範囲の判定・検証環境での適用の3工程に分解でき、これを数日以内に回せる体制があるかが内製・外注の分かれ目です
• パッチは検証を経ずに即適用すると別の不具合を招くことがあるため、主要画面の動作確認を挟んでから本番反映するのが安全です

まずは自社のNext.jsシステムが今回のv16.3.3に対応済みかどうかを確認するところから始めてみてください。それだけでも、パッチ追従の体制が実際に機能しているかどうかの手がかりになります。

保守契約や、パッチ追従を含めた運用体制の相談は、事例や要件が固まっていない段階でも構いません。15分のカジュアル相談(営業目的ではなく、状況整理を目的とした対話)からお受けしています。