あるメンテナがメモリ関連の不具合を修正し、コミットを push して次の作業に移った。アドバイザリもなく、セキュリティラベルも付かず、CVE 番号も割り当てられなかった。このひとつの欠落が原因で、Vercel は8月の2週間をオープンソース4プロジェクトのパッチ調整に費やし、最終的に自社がホストする全アプリケーションで AVIF の画像最適化を停止することになった。
要点
- Vercel は報告された RCE の原因が自社コードではなく libheif にあると特定し、8月13日にプラットフォーム全体で AVIF 最適化を無効化、8月25日に Next.js のセキュリティリリースを公開した。
- 脆弱な経路は next/image から sharp を経て libvips に至り、libvips が AVIF のデコードのために libheif を呼び出す。ImageMagick や WordPress をはじめ、ウェブの広い範囲がこの連鎖を共有している。
- Vercel によれば、GitHub 上の非公開の脆弱性報告は2026年1月の週500件から5月には週3,000件に増え、5月だけで1,560件のアドバイザリが精査されたという。
本当の失敗はラベルの欠落だった
セキュリティラベルがなければ、下流では何も動かない。ディストリビューションのパッケージャはバックポートの合図を受け取れず、依存関係スキャナには照合すべき識別子すら存在しない。Debian 12 と 13 は影響を受けるバージョンを配布し続け、Debian 自身の更新が届いたのは8月8日だった。修正は公開された git 履歴に残り、diff を丹念に読む者なら誰でも見つけられた一方で、そのパッケージを利用する全員が危険を引き継いだ。
長らくこれは許容できる失敗形態だった。ひとつのデコーダについて1年分の上流コミットを読み、ラベルのないメモリ修正を探し当てる作業には高価な専門性が要る。もはやそうではない。研究者3人が Slack、Meta、GitHub Enterprise、Ruby on Rails、Next.js、Astro、Gatsby の露出範囲を調べた調査は2か月で完了し、トークン費用は3,000ドル未満だった。
なぜ報告は別プロジェクトに届いたのか
Hacktron AI は8月、この問題を Next.js の画像最適化における RCE として整理し Vercel に持ち込んだ。調査は責任の所在を速やかに上流へ移した。Image コンポーネントを使う Next.js アプリケーションは AVIF ファイルをリサイズし最適化できる。その処理が sharp を呼び、sharp が libvips を、libvips がデコードのために libheif を呼ぶ。
つまり細工した AVIF 画像を最適化エンドポイントに送れば、Next.js のコードに一切触れることなく脆弱なデコーダに到達できた。フレームワークは通り道であり、欠陥そのものではない。同時にその時点で Vercel が直接制御できる唯一の層でもあった。
公開までの経緯
Vercel のエンジニアリング記事は各段階の日付を記録している。Hacktron の報告は8月11日と12日で、両チームは最新の Next.js ビルドに対して動作する概念実証コードで RCE を再現した。
8月13日、Vercel はプラットフォーム側の緩和策を適用した。Vercel における画像最適化のリクエストはすべて中央の1サービスを経由するため、そこで AVIF の最適化とリサイズを止めるだけでホスティング利用者全体の経路を一度に遮断できた。受信した AVIF ファイルは libheif に届かなくなった。
問題���セルフホスト環境であり、その後の経緯が続いた理由でもある。Vercel は sharp と libvips のメンテナにメールを送り、GitHub Security Advisory を通じて libheif 側との連携を開始した。Hacktron はエクスプロイトの詳細を libheif に個別に提出した。8月19日には Next.js チームが libvips のメンテナと会い、修正方針をすり合わせた。セキュリティパートナーへの通知は8月24日に行われた。
決着は8月25日だった。Next.js は本来別の問題のために予定していたセキュリティリリースに AVIF の緩和策を組み込み、1日前倒しで公開して AVIF の最適化とリサイズを完全に無効化した。libheif のメンテナも同日、RCE を修正した v1.23.2 をリリースした。すり合わせの会合から6日後のことだ。
同じデコーダが届く範囲
libheif は ImageMagick、WordPress、sharp の依存関係にあたる。目立たない欠陥ひとつが異例の広さで影響を及ぼす理由がここにある。デコーダは前年に上流で修正済みだったが、コミットにセキュリティ上の印がなかったため、その修正はひとつの案件として伝わらなかった。
影響は机上の話ではなかった。Vercel への報告の数週間前、研究者らは同種の libheif オーバーフローを SSO の弱点と組み合わせ、コミュニティフォーラムの画像アップロード経由で OpenAI の内部モノレポに到達している。製品も侵入口も対処経路もまったく異なるが、土台にあったのは同じラベルなしの欠陥だった。
今後の見通し
Vercel は量の問題を率直に指摘した。CVE プログラムは2026年だけで35,000件を超える識別子を公開しており、言語モデルが脆弱性研究を加速させるにつれ、同様の上流の欠陥がさらに表面化すると見ている。近年 Next.js のセキュリティリリースの頻度が上がっており、この傾向は続くとも警告した。
現場にとっての結論は見出しほど大げさではない。プラットフォームの利用者は8月13日の時点で、何もしなくても保護されていた。自前の画像パイプラインを運用する側は、実際にどの libheif ビルドを出荷しているかを確認する必要がある。ラベルのない修正が答えにくくしているのは、まさにこの問いだ。
FAQ
脆弱性は Next.js 自体にあったのか
違う。欠陥は AVIF デコーダである libheif にあり、Next.js が AVIF 画像を最適化する際に sharp と libvips を経てそこに到達していた。Next.js が AVIF 最適化を停止したのは欠陥を抱えていたからではなく、速やかに手を入れられる層だったからだ。
Vercel にデプロイしている場合、対応は必要か
不要だ。Vercel は8月13日に中央の Image Optimization Service で AVIF の最適化とリサイズを無効化し、ホスティング中の全アプリケーションの経路を塞いだ。セルフホスト環境では8月25日の Next.js セキュリティリリース、または v1.23.2 以降の libheif ビルドが必要になる。
上流の修正にラベルがないと、なぜそれほど問題なのか
セキュリティツールは識別子を起点に動く。メモリの不具合を黙って直したコミットはアドバイザリのデータベースに載らないため、ディストリビューションはバックポートせず、CI のスキャナも影響を受けるバージョンを検知できない。修正は公開コードに存在しているのに、下流の利用者はそろって脆弱な���ま残される。
