「うちのNode.js、今回の脆弱性は関係あるのかな」と検索した方へ。
2026年10月21日、Node.js公式が重大な脆弱性を修正したバージョンを公開しました。
この記事では対象バージョンの確認方法と、環境別の対応手順をまとめています。
まずは自分のサーバーが対象かどうか、今すぐ一緒に確認していきましょう。
2026年10月21日、Node.js公式がセキュリティリリースを公開しました。修正版はv26.12.1（26.x系・最新版）、v24.22.1（24.x系・LTS）、v22.23.4（22.x系）です。最高の深刻度はHigh（高）。該当するバージョンを使っているなら、できるだけ早い確認とアップデートが必要です。
出典はNode.js公式のセキュリティリリースです。配布一覧（dist/index.json）でも、v26.12.1が2026年10月21日付のセキュリティリリースとして記録されています。
Node.jsの脆弱性、結局何が起きた？今すぐ何をすればいい？
2026年10月21日、Node.js公式がHighを含む10件の脆弱性を修正したバージョンを公開しました。対象はv26.12.1、v24.22.1、v22.23.4です。まず結論から言うと、該当者がやるべきことはひとつ。ターミナルで`node -v`と打ってバージョンを確認し、対象より古ければすぐにアップデートしてください。
今回のリリースで特に注意したいのが、Brotli（データを小さく圧縮する仕組み）の展開処理に見つかった脆弱性です。遠隔からのコード実行につながるおそれがあり、深刻度はHighと判定されています。公式ブログでは全部で10件の脆弱性が報告されており、内訳はHigh 4件、Medium 3件、Low 3件です。
次の章では、修正されたバージョンと10件すべての脆弱性を表で一覧化します。
修正されたバージョンと深刻度一覧
今回のリリースで押さえておくべきは「どの系列が」「いつ」「どのバージョンに」修正されたかです。まずは系列ごとの対応表を見てください。
| 系列 | 修正バージョン | 公開日 | 最高深刻度 |
|---|---|---|---|
| 26.x（最新版） | v26.12.1 | 2026年10月21日 | High |
| 24.x（LTS） | v24.22.1 | 2026年10月21日 | High |
| 22.x | v22.23.4 | 2026年10月21日 | High |
続いて、修正された脆弱性をCVE番号単位で整理しました（内容は発表時点のものであり、配信後に一部修正される場合があります）。CVE番号とは、世界共通で脆弱性を識別するための管理番号のことです。
| CVE番号 | 深刻度 | 脆弱性の内容（平易な説明） | 影響する系列 |
|---|---|---|---|
| CVE-2026-111497 | High | Brotli（圧縮）の展開処理で範囲外の書き込みが発生し、遠隔からのコード実行につながるおそれ | 26 / 24 / 22 |
| CVE-2026-105482 | High | dns.resolveにNUL文字を含む名前を渡すと、途中で名前が切られてしまう | 26 / 24 / 22 |
| CVE-2026-105483 | High | IPアドレスを全角数字で記述すると、TLS証明書のホスト名確認をすり抜けられる | 26 / 24 |
| CVE-2026-106069 | High | ホスト名がゆるくIPアドレスに解決される時に、TLS証明書のホスト名確認をすり抜けられる | 26 / 24 / 22 |
| CVE-2026-105481 | Medium | keep-alive接続で、要求を送る前に書かれた応答を処理してしまう | 26 / 24 / 22 |
| CVE-2026-106072 | Medium | 標準でないIPv4の書き方で、DNS名の証明書がIPアドレスの接続を誤って認証してしまう | 26 / 24 / 22 |
| CVE-2026-106074 | Medium | crypto.randomUUID()とrandomInt()の乱数の元が起動スナップショットやSEAに保存され、別プロセスで同じ値を繰り返してしまう | 26 / 24 / 22 |
| CVE-2026-106070 | Low | ZIPのヘッダーの検証に失敗した後、攻撃者が仕込んだ先頭のデータを返してしまう | 26のみ |
| CVE-2026-106071 | Low | Permission Model（権限管理の仕組み）で、ワイルドカードの扱いによりファイルの権限を広く与えすぎる | 26のみ |
| CVE-2026-106073 | Low | Permission Modelの制限を fs.realpathSync ですり抜けられる | 26 / 24 / 22 |
あわせて、Node.jsに同梱されている部品も更新されています。c-ares（名前解決のライブラリ）、CA証明書（eMudhraの中間認証局が侵害された件への対応）、OpenSSL（24系・22系）、SQLite（22系）、Undiciが対象です。アプリやコンテナのイメージを使っている場合は、これらの部品も含めて作り直して出し直す必要がある、と公式が案内しています。
自社のバージョン確認・対応に不安がある方は、現状をまとめて相談できる無料相談窓口もご活用ください。
一番注意すべきはどれ？
優先度が最も高いのはCVE-2026-111497です。遠隔からのコード実行につながるおそれがあるためで、攻撃者がサーバーを乗っ取る最悪のケースまで想定されます。
次点として、TLS証明書のホスト名確認をすり抜けるCVE-2026-105483とCVE-2026-106069も見逃せません。外部サービスとの通信で「本当に正しい相手と通信しているか」の確認が崩れるため、なりすましや中間者攻撃のリスクにつながります。Medium・Lowの項目も含め、使っているバージョンが古いなら一括でアップデートするのが現実的です。
自分のNode.jsのバージョンはどう確認する？
Node.jsのバージョン確認は、ターミナルで`node -v`と打つだけで完了します。Windows・Mac・Linuxどの環境でも共通のコマンドです。ただし、管理方法によって確認すべき場所が変わるので、環境別に整理しました。
▼Node.jsバージョン確認チェックリスト
ローカルPC
ターミナルやコマンドプロンプトで node -v を実行。表示されたバージョンが対象より古ければアップデートが必要です。
nvm管理の場合
nvm list で入っている全バージョンを表示し、nvm current で現在使用中のバージョンを確認します。
Dockerコンテナの場合
docker exec -it コンテナ名 node -v で稼働中のコンテナ内のバージョンを確認します。
サーバー・VPSの場合
SSHで接続し node -v を実行。複数サービスが動いているなら、各ディレクトリで確認しましょう。
複数のサーバーやアプリでNode.jsを使っている会社ほど、確認漏れが起きやすいポイントです。チェックリストをそのまま社内の確認フローに転用してもらっても構いません。
古いバージョンが見つかった場合、焦ってすぐ上書きするのではなく、まずはどの環境で何が動いているかを洗い出すことが先決です。次の章では、クラウド環境ごとに対応の違いを見ていきます。
クラウド環境ごとの対応はどう違う？AWS Lambdaは自動で直る？
AWS Lambdaの管理ランタイム（AWSが用意しているNode.jsの実行環境）は、既定の設定であれば自動的に更新されます。ただし、更新タイミングを決める設定（Auto／Function update／Manual）によって挙動が異なるため、「自動だから何もしなくていい」と思い込むのは危険です。
環境ごとに確認すべきポイントをまとめました。
| 環境 | 自動更新されるか | 確認すべきこと |
|---|---|---|
| AWS Lambda（管理ランタイム） | 設定がAutoなら自動更新。Function updateは関数更新時のみ、Manualは更新されない | ランタイム更新設定を確認し、Manualなら手動更新が必要 |
| AWS Lambda（コンテナイメージ） | 自動更新されない | ベースイメージを新しいバージョンで作り直し、再デプロイが必要 |
| Cloudflare Workers | Node.js本体とは異なる仕組みのため断定不可 | Node.js本体ではなく、Workersの実行環境上でAPIの一部を提供している構成。今回の脆弱性がそのまま当てはまるかは個別確認が必要 |
| Vercelなど他のホスティング | 各社の方針次第のため断定不可 | 使用中のNode.jsバージョンを管理画面や公式の告知で確認する |
| 自前のEC2・ECS・VPS | 自動更新されない | nvmやパッケージ管理で手動更新、または再デプロイが必要 |
AWS Lambdaのランタイム更新についてはAWS公式のドキュメントのとおり、設定によって自動更新されるかどうかが変わります。コンテナイメージで関数をデプロイしている場合は、この自動更新の対象外になる点に注意してください。
Cloudflare Workersについては、Cloudflare公式ドキュメントによると、Node.js本体をそのまま動かしているわけではなく、Workersの実行環境上でNode.jsのAPIの一部を提供する形です。そのため今回の脆弱性が同じ形で影響するとは言い切れず、過度に心配する必要はありません。
表を見て「うちはどの環境に当てはまるか分からない」という方は、現状の構成確認から一緒に整理できます。無料相談でお気軽にご相談ください。
アップデートはどう進める？
Node.jsのアップデートは、nvmやDockerで使っているバージョンを新しいものに入れ替え、アプリやコンテナイメージを作り直して出し直す、という流れが基本です。いきなり本番環境で上書きするのではなく、段階を踏んで進めることをおすすめします。
更新前に確認したいことは次の通りです。
- 現在使用中のNode.jsバージョンと、依存しているパッケージの対応状況
- ステージング環境やテスト環境があるか
- デプロイのバックアップやロールバック（元の状態に戻す）手順の有無
- Dockerを使っている場合は、ベースイメージのタグ指定方法
更新後は、アプリが正常に起動するか、主要な機能が動くかを確認してください。特にTLS証明書やDNS関連の修正が含まれているため、外部APIとの通信やHTTPS接続まわりは重点的にチェックしておくと安心です。
サポート終了（EOL）バージョンの扱いに注意
サポートが終了したバージョンを使っている場合は、今回のような修正版が今後も提供されません。Node.js 20は2026年4月30日、Node.js 18は2025年4月30日でサポートが終了しています（Node.js公式のリリーススケジュール）。公式のセキュリティリリースでも、サポート終了済みのバージョンは「セキュリティリリースのたびに常に影響を受ける」と明記されています。
20以前のバージョンで運用を続けているなら、今回を機に22以上への移行を検討してください。移行には既存コードの互換性確認が必要になるケースもあるため、早めの着手をおすすめします。
次に、弊社自身が今回どう対応したかを見ていきましょう。
【独自】弊社がおすすめする確認の進め方
Node.jsは、Webサイトの裏側、社内ツール、AIで作ったアプリなど、思わぬ所で動いていることがあります。弊社がお客様のシステムを確認する時は、まず「どのサーバー・どのコンテナで、どの版のNode.jsが動いているか」を一覧にするところから始めます。
サービスごとに版がばらばらになっていることは珍しくありません。古い版が見つかったら、テスト用の環境で動きを確かめてから本番に反映する、という順で進めると、更新でサービスを止める心配が減ります。
日頃から版の一覧を持っておくと、今回のような深刻度Highの脆弱性が出た時に、すぐ動けます。自社のバージョン確認体制に不安がある、あるいは何から手をつければいいか分からないという方は、現状確認からお手伝いできますので、ぜひ一度ご相談ください。
同じ日にPHPの重大な脆弱性も出ています
2026年10月21日は、Node.jsだけでなくPHPでも重大な脆弱性の修正が公開された日です。CVE-2026-109618とCVE-2026-109619という2件の脆弱性が報告されており、PHPで構築されたWebサイトやシステムを運用している場合は、こちらも併せて確認することをおすすめします。
PHPはWordPressをはじめ多くのCMSの基盤になっている言語のため、Node.jsのアプリと並行してPHPのシステムも持っている会社は少なくありません。詳しい内容は以下の記事にまとめています。
NodeとPHPの両方を運用している会社は、この機会にシステム全体のバージョン棚卸しをしておくと、今後の対応がぐっと楽になります。
まとめ：まずは自社のNode.jsバージョン確認から
2026年10月21日に公開されたNode.jsのセキュリティリリースは、v26.12.1、v24.22.1、v22.23.4という3つの修正版を含み、Highを含む10件の脆弱性に対応したものでした。該当するバージョンを使っているなら、`node -v`での確認とアップデートを急いでください。
Lambdaやコンテナ、VPSなど環境によって対応の手間は変わります。この記事のチェックリストと比較表を参考に、まずは自社の構成を洗い出すところから始めてみてください。
よくある質問（FAQ）
Q1. Node.jsの脆弱性は自分の環境に影響しますか？
A1. v26.12.1、v24.22.1、v22.23.4より前のバージョンを使っていれば対象です。まずは node -v でバージョンを確認し、古ければアップデートしてください。
Q2. node.jsのバージョン確認のコマンドは？
A2. ターミナルで node -v と入力するだけです。Windows・Mac・Linuxどの環境でも共通で使えます。
Q3. アップデートすると既存のアプリは壊れませんか？
A3. 多くはマイナーアップデートのため影響は小さいケースが多いです。ただし念のため、更新前にバックアップを取り、ステージング環境での動作確認をおすすめします。
Q4. AWS Lambdaを使っていれば何もしなくていいですか？
A4. 管理ランタイムは既定で自動更新されますが、コンテナイメージで運用している場合や更新設定がManualの場合は自分での対応が必要です。設定を一度確認してください。
Q5. Node.js 20や18を使っていますが大丈夫ですか？
A5. Node.js 20は2026年4月30日、18は2025年4月30日でサポートが終了しており、今回のような修正版は提供されません。22以上への移行を検討してください。
Q6. axiosなどライブラリの脆弱性とは別物ですか？
A6. はい、別物です。今回はNode.js本体の脆弱性で、axiosなど個別のライブラリの脆弱性とは管理が異なります。両方を確認しておくと安心です。
Q7. ReactやNext.jsを使っている場合も関係ありますか？
A7. サーバーサイドでNode.jsを実行している構成であれば関係があります。クライアントサイドのみの利用であれば影響は限定的ですが、Next.jsのサーバー機能を使っている場合は確認が必要です。
今回の脆弱性対応をきっかけに、サーバーやWebサイトの運用保守体制を見直したいという方も多いのではないでしょうか。弊社ではWeb制作・SEOのご相談の中で、サーバー環境の点検やバージョン管理の仕組みづくりについてもあわせてお話しできます。「今すぐ自社の状況を確認してほしい」という方は、ぜひ無料相談からお気軽にお問い合わせください。
コメント