Next.js脆弱性｜CVE-2026-75604とAVIF RCEの影響範囲・自分のアプリの確認手順

2026年8月25日（日本時間26日未明）、Next.js に critical 判定の脆弱性が2件 同時に公開されました。ひとつは Windows 上で動くサーバーで認証なしのリモートコード実行に至る CVE-2026-75604、もうひとつは画像最適化が AVIF ファイルを処理したときに同じく認証なしの RCE に至る GHSA-2xp9-vwfh-vxw4 です。Vercel は当初予告していたリリース日を前倒しして、15.5.24 と 16.3.3 を公開しました。この記事では「自分のアプリは影響を受けるのか」を切り分けられるところまで、公式アドバイザリと npm 配布物の実測にもとづいて整理します。

Next.js の脆弱性は単発の事故ではなく、npm エコシステム全体の依存関係リスクの一部です。今回の AVIF 側の問題も、Next.js 自身ではなく sharp が使う libheif という2段階下の依存に原因があります。依存の連鎖がどう攻撃面になるかは サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 で全体像を扱っています。

Next.jsの脆弱性とは——2026年に公開された33件の全体像

まず前提として、Next.js の脆弱性公開は「たまに起きるイベント」ではありません。GitHub Security Advisory API で vercel/next.js のアドバイザリを取得すると、2026年1月1日以降に公開されたものだけで33件あります（2026年8月28日時点の実測）。

内訳は以下のとおりです。

重要なのは公開のパターンです。Next.js のセキュリティ修正は個別に小出しにされるのではなく、複数件をまとめた「セキュリティリリース」としてまとめて公開されます。2026年5月6日の10件、7月21日の8件がその典型で、そのたびに 15系・16系それぞれの修正版が同時にリリースされます。

つまり「前回アップデートしたばかりだから大丈夫」は成立しません。2026年だけで修正版が出たタイミングは6回あり、そのつど15系・16系の両方でパッチ番号が進んでいます。

なお2026年5月の一斉公開（CVE-2026-44574〜44582）については Next.js脆弱性CVE-2026-44574〜44582一斉公開｜最大CVSS 8.6・15.5.18で修正 で個別に扱っています。本記事は「いま自分のバージョンが安全か」を判断するための通しの視点、あちらは5月時点の各CVEの詳細という役割分担です。

2026年8月のcritical 2件で何が起きたのか

8月25日に公開された2件は、性質がまったく異なります。

2つのスコアは別の物差しです。 9.0 は CVSS 3.1、9.5 は CVSS 4.0 で算出されており、単純に「9.5 のほうが 0.5 だけ危険」とは読めません。同じ列に並べて比較しないでください。

また、両方とも攻撃の難易度を示す要素が付いています。CVE-2026-75604 は AC:H（攻撃条件の複雑さが高い）、AVIF 側は AT:P（攻撃要件あり）です。これらは「悪用が自明ではない」ことを示しますが、回避策が存在しないことと、後述するとおり公開から数時間でPoCが出回ったことのほうが、実務上の緊急度を決めています。

AVIF側の原因はNext.jsの外にある

AVIF 側の根本原因は Next.js のコードではありません。Next.js は画像最適化に sharp を使い、sharp は HEIF/AVIF のデコードに libheif を使います。この libheif に GHSA-g89c-p67h-r497（CVSS 3.1 で 9.8、こちらもCVE未採番）というヒープバッファオーバーフローが見つかりました。

脆弱性の性質を悪用に踏み込まない範囲で述べると、細工された HEIF / AVIF ファイルが、8ビット精度で確保されたアルファプレーンの領域に対して16ビット幅の書き込みを行わせるというものです。画像の内部構造上、同じアルファチャンネルが複数登録されうるのに、確保サイズの決定には最初のひとつしか参照されていませんでした。書き込む値と溢れる量の両方が細工したファイル側から制御できるため、単なるクラッシュに留まりません。libheif 側のアドバイザリには、複数のアプリケーションで実際にRCEに到達できたと記載されています。

libheif 側は v1.23.2 で修正済み（v1.23.1 以前が影響対象）ですが、この修正が sharp の配布バイナリに行き渡るまでには時間がかかります。Vercel が「上流の修正が伝播するまで AVIF の最適化を無効化する」という判断を取ったのはこのためです。

自分のアプリは脆弱性の影響を受けるか——バージョンと条件の確認手順

ここが本題です。3つの軸で切り分けます。

1. 使っている Next.js のバージョンを確定させる

package.json の記載ではなく、実際にインストールされている版を見てください。キャレット指定でも lockfile が古ければ古い版のままです。

# 実際に解決されているバージョンを確認する
npm ls next

# pnpm / yarn の場合
pnpm why next
yarn why next

15.5.24 以上（15系）または 16.3.3 以上（16系）であれば、8月25日公開の2件については修正済みです。

2. Windows ファイルシステム上で動いているか

CVE-2026-75604 の条件は「Next.js サーバーが Windows のファイルシステムを使っていること」です。Vercel は Linux と macOS が影響を受けないことを明記しています。

判断のポイントは開発機ではなく本番の実行環境です。Windows マシンで開発していても、本番が Linux コンテナなら CVE-2026-75604 の対象ではありません。逆に Windows Server や Windows 上の IIS / PM2 でホストしているなら対象です。WSL2 上で Linux ファイルシステムに置いて動かしている構成は対象外と考えられますが、/mnt/c 配下にプロジェクトを置く構成は Windows ファイルシステムを経由するため、対象として扱うのが安全です（この2ケースは当サイトでは未検証のため、断定は避けます）。

3. AVIF 画像を最適化しているか

AVIF 側は「Next.js が攻撃者の制御下にある AVIF 画像を最適化したとき」に成立します。次の2点を確認してください。

# next.config の画像設定を確認（formats の指定と remotePatterns の広さを見る）
grep -rn -A6 "images" next.config.js next.config.mjs next.config.ts 2>/dev/null

# プロジェクト内にAVIF素材があるか
find . -name "*.avif" -not -path "./node_modules/*" | head

注意すべきは、formats の設定は「出力」形式であって「入力」ではないことです。Next.js の formats のデフォルトは ['image/webp'] ですが、これは変換後の形式を指します。AVIF を出力形式に指定していなくても、元画像が AVIF ならデコードのために libheif が呼ばれます。したがって「formats に avif を入れていないから安全」とは言えません。

より広い影響を受けるのは、next.config の images.remotePatterns で外部ドメインからの画像取得を許可している構成です。攻撃者が制御できる URL の画像を最適化しうるためです。

Windows RCE（CVE-2026-75604）の修正パッチを実測で読む

ここからは公式アドバイザリの説明より一段深く、npm から 15.5.23 と 15.5.24 を実際に取得して差分を取った結果を示します。パッチの中身が分かると、「なぜ Windows だけなのか」が腑に落ちます。

# 実際に行った検証（配布物の差分を取る）
npm pack next@15.5.23
npm pack next@15.5.24
mkdir -p a b   # 展開先を先に作る（無いと tar: could not chdir to 'a' で失敗する）
tar xzf next-15.5.23.tgz -C a && tar xzf next-15.5.24.tgz -C b
diff -ru a/package/dist b/package/dist

セキュリティに関係する変更は2ファイルに集約されていました。

修正1：エスケープ対象にバックスラッシュが追加された

dist/shared/lib/router/utils/escape-path-delimiters.js の変更は、正規表現の文字クラスに1文字を足しただけです。

つまり、パス区切りとしてエスケープされていたのは /・#・? の3つだけで、バックスラッシュ \ が抜けていました。

ここが Windows 限定である理由です。POSIX（Linux / macOS）では \ はファイル名に使える普通の文字であり、ディレクトリの区切りにはなりません。しかし Windows では \ がパス区切りとして解釈されます。エスケープされずに残った \ を含むセグメントがファイルパスの組み立てに流れ込むと、Windows 上でだけ意図しないディレクトリへ抜け出せてしまう、という構造です。

そして最も示唆的なのは、同じ関数がエンコード済みのバックスラッシュ %5c はすでに処理対象にしていたという点です。修正前のコードにも %(2f|23|3f|5c) という分岐が存在します。5c はバックスラッシュの URL エンコード表現ですから、このコードは「エンコードされたバックスラッシュが危険であること」を最初から知っていて、生のバックスラッシュだけを取りこぼしていたことになります。典型的な、片側だけを塞いだ入力検証の抜けです。

修正2：キャッシュの書き込み先が親ディレクトリ配下に制限された

もう1ファイル、dist/server/lib/incremental-cache/file-system-cache.js の getFilePath() に封じ込めチェックが追加されています。

修正前は、キャッシュ種別ごとにベースディレクトリと受け取った文字列を path.join() するだけで、そのまま返していました。修正後は結果のパスがベースディレクトリの配下に収まっているかを検証し、外れていればエラーコード E799（Invalid file path）を投げて処理を止めます。

引数名も pathname から key に変更されています。これは「これはパスではなくキーであって、そのままパスとして信用してはいけない」という意図の表明と読めます。

この2つの修正の関係は、入口（エスケープ漏れの修正）と出口（書き込み先の封じ込め）の二重化です。片方が破られてももう片方で止まる設計に変わりました。なお本記事には、攻撃を組み立てるために必要な入力の形式や再現手順は記載していません。

公開から約3時間でPoCが出現している

緊急度の判断材料として重要な事実があります。GitHub のリポジトリ API で確認したところ、CVE-2026-75604 の PoC を掲げる公開リポジトリが 2026年8月26日 4時06分（日本時間）に作成されています。アドバイザリの公開は同日1時15分（日本時間）なので、2時間51分後です。

2026年8月30日 2時台（日本時間）に再確認した結果、この時間差は初出時の記載どおりで、リポジトリも公開されたままです。拡散は続いており、スターは初出時の58個から74個へ、フォークは34個になっています。最終更新は2026年8月28日11時53分（日本時間）で、アドバイザリ公開から3日後もまだ手が入っている状態です。

その内容が実際に動作するかは当サイトでは検証しておらず、リポジトリ名もリンクも掲載しません。しかし「公開情報からの再現を試みる人がすでに動いていて、しかも増え続けている」という事実そのものが、AC:H（攻撃条件が複雑）というベクタを額面どおりに受け取るべきでない理由になります。フォークが34個あるということは、仮に元リポジトリが削除されても複製は残るということでもあります。悪用の敷居が下がる方向にしか動いていないので、更新の緊急度は初出時より上がったと判断してください。

AVIF側の修正——libheifの穴とdefault-denyへの切り替え

同じ差分から、AVIF 側の修正も読み取れます。Vercel の公式アナウンスは「AVIF の最適化を無効化した」とだけ書いていますが、実際の変更は2層になっています。

層1：libvips のローダーを原則すべて禁止し、6つだけ許可する

dist/server/image-optimizer.js の sharp 読み込み直後に、次の処理が追加されました。

・まず sharp.block({ operation: ['VipsForeignLoad'] }) で libvips の画像ローダーを一括してブロックする
・そのうえで sharp.unblock() で 6つのローダーだけを明示的に解除する

解除されているのは VipsForeignLoadJpeg・VipsForeignLoadNsgif・VipsForeignLoadPng・VipsForeignLoadSvg・VipsForeignLoadTiff・VipsForeignLoadWebp の6つです。JPEG・GIF・PNG・SVG・TIFF・WebP に対応します。

これは allowlist（原則禁止・例外許可）への切り替えです。従来は libvips が対応する形式を読める状態でしたが、修正後は明示的に許可された6つ以外のローダーが動きません。HEIF / AVIF を扱う libheif はこの6つに含まれていないため、そもそも呼ばれなくなります。

この設計変更の効果は、今回の libheif の問題を塞ぐことに留まりません。この operation 配下の他のローダーに将来同種の問題が見つかっても、Next.js の画像最適化経由では到達できなくなります。個別の穴を塞ぐのではなく攻撃面そのものを縮めた修正です。

この変更は sharp 0.34 系でも動くのか（実測）

ここに気になる点がありました。package.json の sharp の対応範囲が、15.5.23 の ^0.34.3 から 15.5.24 では ^0.34.3 || ^0.35.3 に広げられています。もし block() / unblock() が 0.35 系で追加された新 API なら、0.34 系に固定している環境では例外が発生し、sharp の読み込み自体が失敗して画像最適化がまるごと止まるおそれがあります。

実際に確認しました。

npm i sharp@0.34.3
node -e "const s=require('sharp'); console.log(typeof s.block, typeof s.unblock)"
# => function function

sharp@0.34.3 にも block / unblock は存在し、Next.js 15.5.24 が呼び出しているのとまったく同じ引数で実行しても例外は発生しませんでした。0.34 系に固定していても、この防御は有効に働きます。 対応範囲の拡大は、libheif 修正版を取り込んだ新しい sharp へ移行できるようにするための許容であって、要件の引き上げではありません。

層2：AVIFが「素通し」リストに追加された

もうひとつの変更は、BYPASS_TYPES という定数への AVIF の追加です。15.5.23 では SVG・ICO・ICNS・BMP・JXL・HEIC の6種類でしたが、15.5.24 で AVIF が加わって7種類になりました。

このリストに含まれる形式は、画像最適化処理の途中でアップストリームから取得したバッファをそのまま返して終了します。次のセクションで見るとおり、これが利用者から見える副作用を生みます。

アップデート後に変わる挙動——AVIF最適化の副作用

セキュリティ修正には、利用者から見える挙動の変化が伴っています。ここは公式アナウンスにも日本語の速報にも書かれていない部分なので、アップデート前に把握しておく価値があります。

AVIF画像はリサイズもされなくなる

前述の BYPASS_TYPES に入るということは、単に「再圧縮しない」だけではありません。差分を読むと、この分岐はアップストリームのバッファをそのまま返して即座に処理を終える実装です。

つまり <Image> コンポーネントで AVIF の画像を指定した場合、リクエストされた幅に関係なく、元の解像度・元のバイト数のファイルがそのまま配信されます。4K の AVIF 素材をサムネイル表示していたなら、アップデート後はサムネイルの位置に 4K のファイルが配信されることになります。

AVIF 素材を使っているサイトでは、転送量と LCP（Largest Contentful Paint）の悪化として観測される可能性があります。セキュリティ上は正しい判断ですが、パフォーマンス上は後退です。 アップデート後に画像まわりの指標が動いたら、まずここを疑ってください。

AVIFで「出力」している場合は画質係数も変わっている

もうひとつ、同じ差分に AVIF の出力品質の計算式の変更が入っています。

コード内のコメントによれば、これは sharp のデフォルト値（WebP が 80、AVIF が 50）から導いた比率で、dssim と ssimulacra2 という画質評価指標で検証したうえでの変更とされています。

影響は指定品質によって向きが変わります。

分岐点は quality ≈ 53 です。 これより上を指定していれば新しい式のほうが低い値になり、下なら逆にわずかに上がります。「常に下がる」わけではありません。

ただしこの変更が効くのは、next.config の images.formats に image/avif を明示的に指定している場合だけです。formats のデフォルトは ['image/webp'] であることを配布物で確認しました。したがって、大半のプロジェクトには影響しません。AVIF を出力形式に選んでいる場合にのみ、デフォルト品質で 55 → 47 相当の変化が起きます。

安全なバージョンはどれか——2026年アップグレード早見表と対策

最後に、対策をバージョン別に整理します。ここが「Next.js の脆弱性」を調べている人がいちばん知りたい部分だと思います。

2026年に修正版が出たバージョン系列

この表から読み取れる、実務上いちばん重要な事実が2つあります。

1つ目：13系・14系には修正版が存在しません。 2026年に公開された33件のアドバイザリを通して、パッチが提供された系列は 15.5.x と 16.x だけです。CVE-2026-75604 の影響範囲は「13.4 以上 15.5.24 未満」と記載されていますが、13系・14系向けの修正版はリリースされていません。これらのバージョンを使っている場合、対策は 15.5.24 以上へ上げること以外にありません。

2つ目：16.2 系で止まっていると、マイナーバージョンを上げる必要があります。 7月のセキュリティリリースで 16.2.11 に上げた人は多いはずですが、8月の修正は 16.3.3 で提供されています。16.2 系には 8月分のパッチが出ていません。パッチバージョンを上げるだけでは追いつかず、16.2 → 16.3 のマイナー移行が必要です。

対策コマンド

# 15系を使っている場合
npm install next@15.5.24

# 16系を使っている場合（16.2系からは16.3へのマイナー移行になる）
npm install next@16.3.3

# 適用後に実際の解決バージョンを再確認する
npm ls next

アップデート後は、npm ls next で実際に新しい版が入ったことを確認してください。lockfile やモノレポの hoisting の都合で、package.json を書き換えただけでは反映されないことがあります。

判断フロー

CVE番号・脆弱性DBでの追跡状況（2026年8月30日に再確認）

このセクションは2026年8月30日 2時台（日本時間）に全項目を測り直しました。初出時の記述のうち npm audit に関する部分が誤っていたので訂正します。

CVE-2026-75604 は、再確認した時点でも NVD（National Vulnerability Database）に登録されていません。NVD の API に問い合わせると、初出時と同じく該当なし（totalResults: 0）が返ります。加えて今回、NVD の上流にあたる CVE Program 側にもレコードが存在しないことが分かりました（cveawg.mitre.org の API が CVE_RECORD_DNE を返す）。CVE番号は採番されアドバイザリにも記載されていますが、CVEレコード自体がまだ公開されていない段階です。

理由はデータベースの層が違うことです。vercel/next.js の2件はリポジトリ内アドバイザリとして公開されていますが、npm audit や OSV 系スキャナが参照するのはグローバルの GitHub Advisory Database のほうです。この2件は観測時点でまだグローバル側へ伝播しておらず、実際グローバル側で next 向けに登録されている最新のアドバイザリは 2026年7月22日公開分のままでした。

この「0件」がコマンドの叩き方の誤りでないことは、対照群で確かめています。まったく同じ手順を7月公開分の対象である 15.5.20 に対して実行すると、npm audit のデータ源は8件のアドバイザリを返します。手順は動いていて、8月25日公開の2件だけが返ってこない、というのが実測結果です。

# npm audit が参照しているデータ源に直接問い合わせる（next のインストールは不要）
curl -s -X POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk \
  -H 'content-type: application/json' -d '{"next":["15.5.23"]}'
# => {}      … 8月25日公開の critical 2件は返ってこない

# 対照：7月公開分の対象バージョンなら返ってくる（＝手順自体は動いている）
curl -s -X POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk \
  -H 'content-type: application/json' -d '{"next":["15.5.20"]}'
# => アドバイザリが8件返る

ひとつ紛らわしい点があります。実際のプロジェクトで npm audit を流すと、15.5.23 でも next は結果に出てきます。ただしそれは推移的依存（postcss / sharp）を経由した報告であって、8月25日公開の2件が根拠ではありません。npm audit --json の vulnerabilities.next.via を見ると、15.5.23 では postcss と sharp の2つだけが並び、対照の 15.5.20 では next 自身のアドバイザリ8件が並びます。「next が出ているから今回の件も検知できている」と読み替えないでください。

なお、この状態は恒久的なものではなく、グローバル側へ伝播すれば解消する見込みです（いつ伝播するかは当サイトでは予測できないため、断定は避けます）。実務上の要点は、スキャナが静かなことを安全の根拠にしないことです。判断材料にすべきはスキャナの出力ではなく、前述の「自分のアプリが影響を受けるか」で示した npm ls next の実解決バージョンと、15.5.24 / 16.3.3 との比較です。

なお AVIF 側の GHSA-2xp9-vwfh-vxw4 と、上流の libheif GHSA-g89c-p67h-r497 は、いずれもCVE番号自体が採番されていません（2026年8月30日時点でも変わらず「No known CVE」表記）。CVE番号でのみ管理しているワークフローでは、この2件は引っかかりません。

同じく Next.js の個別CVEを掘り下げた記事として Next.js CVE-2026-44578｜WebSocket SSRF（CVSS 8.6）の仕組みと緊急対策 もあります。あちらは5月公開の SSRF 単体の詳細解説です。

まとめ

2026年8月25日公開の Next.js の脆弱性2件について、実務上の要点を再掲します。

・修正版は 15.5.24 と 16.3.3 のみ。13系・14系には修正版が存在せず、16.2系はマイナー移行が必要
・CVE-2026-75604 は Windows ファイルシステム限定。原因は escapePathDelimiters がバックスラッシュをエスケープ対象から落としていたことで、POSIX では \ が区切り文字でないため影響が出ない
・回避策はないとVercelが明記。アドバイザリ公開の2時間51分後に公開PoCリポジトリが出現し、2026年8月30日時点でスター74・フォーク34まで拡散している
・AVIF 側はOS非依存。原因は libheif（v1.23.2 で修正）で、Next.js 側は libvips ローダーの allowlist 化と AVIF の素通し化という2層で塞いだ
・アップデートで挙動が変わる。AVIF 画像はリサイズされず元ファイルが配信される。AVIF を出力形式に指定している場合はデフォルト品質が 55 → 47 相当に変化する
・CVE-2026-75604 は NVD 未登録（2026年8月30日に再確認）。上流の CVE Program 側にもレコードが無い
・npm audit と OSV も8月25日公開の2件を報告しない（2026年8月30日の実測。初出時の記述を訂正）。リポジトリ内アドバイザリがグローバルの GitHub Advisory Database へ未伝播のため。スキャナが静かなことを安全の根拠にせず、npm ls next の実解決バージョンで判断する

本記事の差分検証（15.5.23 と 15.5.24 の npm 配布物の比較、sharp@0.34.3 での block/unblock の動作確認、NVD API への問い合わせ、PoC リポジトリの作成時刻確認）は、いずれも2026年8月28日に実施した実測値です。加えて2026年8月30日 2時台（日本時間）に、NVD・CVE Program・GitHub Advisory Database・npm audit のデータ源・OSV・PoC リポジトリの状態・npm の dist-tags を測り直しました（このとき npm audit に関する初出時の記述の誤りが判明し、訂正しています）。libheif の脆弱性の内部構造については、悪用可能な再現手順を含まない範囲で記述しました。

参照ソース

・August 2026 Security Release — Next.js 公式ブログ（2026年8月25日公開）
・GHSA-p293-qw3h-jr36 — Unauthenticated Remote Code Execution on windows-hosted servers（CVE-2026-75604）
・GHSA-2xp9-vwfh-vxw4 — Unauthenticated Remote Code Execution in Image Optimization API when AVIF files are used
・GHSA-g89c-p67h-r497 — libheif のヒープバッファオーバーフロー（上流の原因、v1.23.2 で修正）
・vercel/next.js GitHub Security Advisories 一覧（2026年の33件の集計元）
・NVD CVE-2026-75604（2026年8月28日・8月30日の2回とも未登録を確認）