会員がプロフィール画像を上げる、CMSに写真を貼る、外部URLの画像をサムネイルに縮める。Node.jsでこうした処理を書くときの代表的な選択肢の1つがsharpで、AstroとNext.jsも画像の最適化にsharpを使います。2026年9月8日に公開された勧告によると、sharpがAVIF画像を読み込む部分に、細工された画像で遠隔コード実行（RCE）につながり得る脆弱性がありました。
厄介なのは、package.jsonに書いた覚えがなくてもフレームワークの依存としてsharpが入っており、フレームワークを修正版に上げても古いsharpが残る場合があることです。勧告を一次資料で確認し、実際に動いている版の確かめ方と、すぐ上げられないときの止め方を、編集部の検証環境で動かした結果とともに示します。
AVIFを読む部分は、sharpの中のlibheifにある
sharpは画像処理ライブラリlibvipsをNode.jsから使うパッケージで、npmから入るビルド済みバイナリにはlibvipsとその依存が同梱されています。AVIFとHEIFの読み書きを担うのがlibheifです。
sharpの勧告（GHSA-rgj7-g3m4-5g8c）によると、上流のlibheifで複数の脆弱性（GHSA-g89c-p67h-r497 / CVE-2026-84383、GHSA-2jg2-4ch7-h545）が修正され、うち2件はCVSSv3で「Critical」、特定の条件下でglibcベースのLinuxでRCEに至る可能性があります。sharp自体はネットワーク機能を持たないとして深刻度をCVSSv4の「High」に下げつつ、後続システムへの影響に注意を促しています。対象は「信頼できない入力を処理している、0.35.4より前のsharp」です。同じ日に、sharpを使うフレームワークも勧告を出しました。
| パッケージ | 勧告 | 修正版 | 修正の中身 |
|---|---|---|---|
| sharp | GHSA-rgj7-g3m4-5g8c | 0.35.4 | libheif 1.23.2を同梱 |
| astro | GHSA-26w7-cxv4-gfx2 | 7.2.8 | sharp 0.35.4以上を必須に |
| next | GHSA-2xp9-vwfh-vxw4 | 15.5.24 / 16.3.3 | AVIFの最適化を無効化 |
Astro 7.2.8の変更は、optionalDependencies のsharpの範囲を ^0.34.0 || ^0.35.0 から ^0.35.4 に上げたものです。Next.jsの勧告は「修正が行き渡るまでAVIFの最適化を無効にする」と書いており、15.5.24と16.3.3の該当コミットでは、画像最適化APIでsharpのAVIF読み込み（VipsForeignLoadHeif）を許可リストから外し、AVIFの元画像を変換せずそのまま返すようにしています。一方、Next.jsのsharpの範囲は16.3.3が ^0.35.3、15.5.24が ^0.34.3 || ^0.35.3 で、0.35.4以上を必須にはしていません。
npmでの公開日時は、sharp 0.35.4とAstro 7.2.8が8月26日、Next.js 15.5.24と16.3.3が8月25日（いずれもUTC）で、勧告より前です。
自分のシステムは当てはまるか
sharpの勧告は「信頼できない入力」、Astroの勧告は「攻撃者がAstroに信頼できないAVIF画像を処理させられる場合」を対象としています。この文言を当てはめた編集部の整理は次のとおりです。
- 優先して対応する。 アップロード画像をsharpで変換するAPI、外部URLの画像を縮めるサムネイル生成、Next.jsの画像最適化で外部の画像を許可している構成、Astroをサーバー出力で動かして外部の画像を最適化する構成
- 確認してから判断する。 CMSから取り込んだ画像をビルド時に最適化するサイト。画像を入れられる人の範囲やアカウント乗っ取りを考えると、「自社の画像だけ」と言えるかは運用次第です。Astroの
image.domainsやimage.remotePatternsで許可した先も同様です - 影響は小さいと考えられる。 自分たちで用意した画像だけを、手元やCIでビルド時に変換する静的サイト
3つ目を名指しで除外する記述は、3つの勧告のいずれにもありません。「影響は小さい」は編集部の判断で、上げない理由にはなりません。どの分類でもsharpは上げておくのが安全です。依存更新の運用はDependabotが既定で3日待つ — 依存更新の運用を組み直すで整理しました。
Astroはsharpの版を引き上げ、Next.jsはAVIFを読まないことで直しています。Next.jsのプロジェクトで自分のコードからもsharpを呼んでいるなら、sharpの版を別に確認する必要があります。
実際に動いているsharpの版を確かめる
見るのはpackage.jsonではなく、インストールされた依存ツリーと、実行時に読み込まれる版です。2026年10月1日に、編集部の検証環境（Linux x86_64、glibc 2.39、Node.js v22.22.0の公式バイナリ、npm 10.9.4）で実行しました。
npm ls sharp # どのパッケージが、どの版のsharpを入れているか
npm explain sharp # 依存の種類と要求している範囲
node -p "require('sharp').versions.sharp + ' / libheif ' + require('sharp').versions.heif"sharp.versions は、sharpとlibvips、ビルド済みバイナリ利用時はその依存の版を返すプロパティです。heif はsharp 0.35.3で 1.23.1、0.35.4で 1.23.2 でした。
次に、古いロックファイルを再現するためsharp 0.35.3を固定した最小プロジェクトを作り、フレームワークだけを上げました。
| 試したこと | npm lsのsharp | npm auditの検出 |
|---|---|---|
| astro@7.2.7を新規に入れる | 0.35.5 | astroのみ |
| sharp 0.35.3固定のastro@7.2.7をastro@7.2.8に上げる | 0.35.3 → 0.35.5 | astroとsharp → なし |
| sharp 0.35.3固定のnext@16.3.2をnext@16.3.3に上げる | 0.35.3のまま | sharpが残る |
続けて npm update sharp | 0.35.5 | sharpは消える |
npm explain sharp では、AstroでもNext.jsでもsharpは optional として入っていました。0.35.3はAstro 7.2.7やNext.js 16.3.3の範囲を満たすため、npmはそのまま残します。Astro 7.2.8は範囲が ^0.35.4 なので、sharpも入れ替わりました。
npm auditは版で判定するため、sharpが新しくてもastro 7.2.7を検出し、Next.jsを上げてもsharp 0.35.3を検出しました。フレームワークとsharpの両方を上げるまで消えません。next@16.3.3では別の勧告GHSA-vcvr-r3jv-pc5j（next/ogのImageResponse）も検出され、これはNext.jsのnext/og・Windows RCE（2026年9月）で扱っています。
sharpの最新版は0.35.5（9月27日公開）でlibheif 1.23.5を同梱しています。libheifのリポジトリでは1.23.2の後もGHSA番号付きの修正コミットが続いているため、0.35.4で止めず最新版に上げるのが編集部の提案です。
すぐに上げられないときは、AVIFの読み込みを止める
sharpの勧告は回避策として、AVIFのデコードを止める次の1行を示しています。
const sharp = require('sharp');
sharp.block({ operation: ['VipsForeignLoadHeif'] });sharp.block() はlibvipsの操作を実行時に止める関数です（0.32.4から）。編集部の検証環境で、sharpで作った64×64ピクセルのAVIF・JPEG・PNGをこの1行の前後でWebPに変換しました。sharp 0.35.3と0.35.4で結果は同じでした。
- 入れる前は3形式とも変換できた
- 入れた後、AVIFはBuffer・ファイル・ストリームのいずれの入力でも
unsupported image formatのエラーになった。metadata()もエラー - JPEGとPNGは変換でき、JPEGからAVIFへの書き出しも成功した
止まるのは読み込みだけで、AVIFでの配信は残せます。ただし設定はsharpを読み込んだプロセスの中だけに効くため、ワーカーなど別プロセスではそれぞれで呼びます。AVIFのアップロードを受け付けなくなる点も利用者への案内が要ります。AVIFを配信形式に使うかはWebP・AVIF・JPEG XL — 2026年、サイトの画像はどれで出すかで整理しました。
勧告はもう1点、位置独立実行形式（PIE）でビルドされたnodeを使うよう勧め、多くのLinuxのパッケージマネージャーはPIEにしているが「公式」のNode.jsバイナリはそうではないと注意しています。
readelf -h "$(command -v node)" | grep Type # DYN ならPIE、EXEC ならPIEではないnodejs.orgから取得したv22.22.0のlinux-x64版（SHASUMS256.txtとハッシュ一致）は EXEC でした。これは回避策の補助で、sharpの更新の代わりにはなりません。
上げたつもりで残る落とし穴
ここまでの確認から、見落としやすい点を編集部の整理として挙げます。
- フレームワークだけを上げて終わる。 Next.jsの修正版はsharp 0.35.3を許したままです。next/imageの外で自分のコードがsharpを呼んでいれば影響が残るため、
npm update sharpなどでsharpそのものを上げます - package.jsonだけを見る。 optionalDependenciesとして入るsharpは名前が出てきません。
npm ls sharpで、複数の版が入っていないかも見ます - 本番のイメージが古い。 開発機で入れ直しても、本番のコンテナイメージが前のロックファイルのままなら変わりません。本番で
sharp.versions.heifを出力して確かめます - システムのlibheifを使っている。 勧告は、グローバルにインストールしたlibheifを使う場合は1.23.2にするよう書いています。ビルド済みバイナリを使わない構成では、OS側の版を確認します
2026年10月1日に、sharp・Astro・Next.jsの勧告を github/advisory-database（commit 3113af4）の収録内容で確認し、sharp・sharp-libvips・libheif・Astro・Next.jsの各リポジトリのタグ・変更履歴・コミットと照合しました。libheifの版、
sharp.block()の効果、依存解決とnpm auditの結果は、Linux x86_64・Node.js v22.22.0・npm 10.9.4で実行した結果です。脆弱性そのものの再現は行っていません。Windows・macOS・musl（Alpine）、pnpm・yarn、AstroとNext.jsの実アプリでの画像最適化、HEIC画像の扱いは未検証です。libheif側の勧告ページは閲覧できず、脆弱性の技術的な詳細は確認していません。
画像を扱うNode.jsシステムの依存更新やアップロード処理の見直しは、グリームハブへご相談ください。
Sources
- sharp: Vulnerabilities in libheif: GHSA-g89c-p67h-r497 and GHSA-2jg2-4ch7-h545 (GHSA-rgj7-g3m4-5g8c)
- Astro: Remote code execution through AVIF image optimization (GHSA-26w7-cxv4-gfx2)
- Next.js: Unauthenticated Remote Code Execution in Image Optimization API when AVIF files are used (GHSA-2xp9-vwfh-vxw4)
- GitHub Advisory Database（上記3件の収録データ）
- sharp v0.35.4 changelog
- sharp API: Utilities (block / unblock / versions)
- sharp-libvips versions.properties (v1.3.3)
- libheif v1.23.2
- Astro: Update Sharp to 0.35.4 (ecb4082)
- Next.js: [16.3.x] [next/image]: disable avif image optimization (3a15b4a)
