JavaScript・Node.jsの脆弱性情報まとめ

2026年11月1日時点で、米CISAの悪用が確認された脆弱性の一覧（KEV）に載っているもの、深刻度が緊急のもののうち、Node.jsと利用者の多いパッケージに関わるものです。[1]

このほか、Magic LinkとOAuthを併用する構成のbetter-authの認証回避と、Vite 6.4.4のファイル読み取りの記事があります。

Node.js公式は、本番では長期サポート版（LTS）だけを使うよう案内しています。[9]

日付はNode.jsのリリース計画の値です。[10]サポート終了版はセキュリティ修正の告知でも「常に影響を受ける」と扱われ、修正版は出ません。[2]Node.js 27からは年1回の公開になり、すべての版がLTSになります。[9]

npmの監査は、lockファイルにあるパッケージを既知の脆弱性と照らし合わせるもので、Node.js本体は見ません。本体はnode -vの番号を上の表と比べます。npmの監査は、初期設定ではpackage-lock.jsonかnpm-shrinkwrap.jsonが必要です。[11]

node -v
npm audit
npm audit --omit=dev        # 本番で入る依存だけ
npm audit --audit-level=high # high以上で終了コードを1にする（CI向け）
npm audit signatures         # 署名と出所の証明を確かめる

pnpmとYarn（2以降）は次のとおりです。pnpmの結果はCVEではなくGHSAの番号で出ます。[12]

pnpm audit
pnpm audit --prod
yarn npm audit --all --recursive

見つかったパッケージがどこから入っているかは、次のコマンドで確かめます。

npm ls next --all
npm explain react-server-dom-webpack
pnpm why vite
yarn why sharp

npm audit fix --forceはメジャーバージョンを上げることがあるので、変更の内容を見てから使います。直接入れていないパッケージは、package.jsonのoverrides（pnpmはpnpm.overridesなど、Yarnはresolutions）で版を固定できます。[13]

1. 本番で動いている版を見る：手元のnode -vではなく、本番のコンテナやサーバーで確かめます。node:24のようなタグは、イメージを作り直すまで古い版のままです。docker run --rm <イメージ> node -vで実際の番号を見ます。
2. Node.jsの組み込み部品は本体の番号で判断する：Brotliの修正版でもprocess.versions.brotliの表示は変わりません。[2]BunやDenoなど別の実行環境は、それぞれの告知を確かめます。
3. lockファイルで正確な版を見る：package.jsonの^付きの範囲では、入っている版が分かりません。lockファイルとnpm lsで確かめ、CIではnpm ciを使ってlockファイルどおりに入れます。
4. Next.jsはnextの版で判断する：App Routerはnextに組み込まれたReactを使うため、package.jsonのreactを上げても直りません。React Server Componentsの件でも、React公式はNext.jsの利用者にnextの更新を案内しています。[5]
5. 開発用の依存も見る：ViteやMetroの件は開発サーバーの問題です。--omit=devの結果だけで判断せず、開発サーバーをネットワークへ公開していないかも確かめます。[7][8]
6. 不正な版を入れていたら、更新では終わらない：TanStackの件では、該当の版をインストールした環境は侵害されたものとして扱い、資格情報を取り替え、クラウドの監査ログを確かめるよう案内されています。lockファイルに該当の版が残っていないかも見ます。[6]