2026年10月21日、Node.jsの開発チームが22系・24系・26系に向けたセキュリティリリースを公開しました。修正された脆弱性は10件で、そのうち4件が深刻度「高」です*1。中でも圧縮データを展開するBrotliの不具合は、攻撃者が用意したデータを展開させられると、プロセスのメモリ破壊やリモートでのコード実行につながるおそれがあると公式に説明されています*1。
Node.jsは自社サイトや業務システムだけでなく、Claude CodeやCodexで作ったAIアプリの裏側でも広く動いています。先に結論を言うと、Node.jsで動くアプリを持つ企業は、本番で動いているバージョンを実際に確かめ、22.23.4・24.22.1・26.12.1以上へ上げることが最優先です。VercelやAWSに任せている場合も「自動で直っているはず」で終わらせず、数字で確認してください。
この話題は、私もXで紹介しました。
今なら、生成AIの基礎知識から社内導入の6ステップ・定着のポイントまでを1冊にまとめた「はじめての生成AI社内導入ガイド」を無料で配布中!何から始めればいいか分からない方でも、これ1冊で導入の流れがつかめます。
目次
Node.jsとは|WebサイトやAIアプリを裏側で動かす実行環境
Node.jsは、本来はブラウザの中で動くJavaScriptをサーバー側でも動かせるようにした実行環境です。ログインの処理やデータベースとのやり取り、外部APIの呼び出しなど、利用者の目に見えない裏側の仕事を担います。たとえるなら、アプリという車を走らせる「エンジン」のような存在です。

最近はAIアプリの多くもNode.jsの上で動いています。チャット画面の裏でOpenAIやAnthropicのAPIを呼び出す部分を、Node.jsで書くのはごく一般的な構成です。つまりアプリのコード自体に問題がなくても、エンジンであるNode.jsに穴があれば、その影響を受けることになります。
Node.jsには、長期サポートを受けられるLTS版と、新しい機能を先に取り込むCurrent版があります。公式は、本番のアプリにはLTS版だけを使うよう案内しています*2。今回のリリースで対象になった系統と修正版は次の通りです。
| 系統 | 位置づけ(2026年10月時点) | 修正版 |
|---|---|---|
| 26系 | Current(最新機能版・LTSではない) | 26.12.1 |
| 24系 | LTS(最新のLTS) | 24.22.1 |
| 22系 | LTS | 22.23.4 |
| 20系以前 | サポート終了(EOL) | 提供なし |
注意したいのは20系以前です。すでにサポートが終わっているため今回の修正は提供されません。公式は「サポート終了版は、セキュリティリリースのたびに常に影響を受ける」と明記し、新しい版への移行を求めています*1。
今回の脆弱性とは|深刻度「高」4件の中身
公式の告知では、10件の内訳は「高」4件・「中」3件・「低」3件です*1。まず深刻度「高」の4件を整理します。専門用語が多いので、表の右側に「何が起きうるか」を私なりに言い換えて添えました。
| CVE番号 | 内容 | 対象の系統 | 何が起きうるか |
|---|---|---|---|
| CVE-2026-111497 | Brotliの展開処理で範囲外への書き込み | 26・24・22 | 細工した圧縮データでクラッシュ・メモリの漏えい・コード実行 |
| CVE-2026-106069 | 先頭に0を付けたIPv4表記でTLSのホスト名検証がずれる | 26・24・22 | 本来と違うIPアドレス向けの証明書で通信が通ってしまう |
| CVE-2026-105483 | 全角数字で書いたIPアドレスでTLSのホスト名検証をすり抜ける | 26・24 | 一致しない証明書でも安全な通信と見なされる |
| CVE-2026-105482 | NUL文字を含むホスト名がdns.resolve系で切り詰められる | 26・24・22 | 想定と違う宛先の名前解決が行われる |
企業にとって特に重いのはBrotliとTLSの2系統
- Brotliの不具合(CVE-2026-111497) — Node.jsに同梱されたBrotliの展開処理で、壊れた圧縮データが内部のバッファの外側に書き込まれる問題です。
node:zlibで外部から受け取ったデータを展開している場合が該当し、公式はコード実行に至る可能性まで言及しています。 - TLSのホスト名検証(CVE-2026-106069・CVE-2026-105483) — HTTPS通信で「接続先が本物か」を確かめる仕組みが、変わったIPアドレスの書き方で正しく働かない問題です。社内システム同士をIPアドレス指定でつないでいる構成では見直しの価値があります。
- DNSの名前の切り詰め(CVE-2026-105482) — 以前の修正(CVE-2026-48930)が一部の関数にしか効いていなかった「修正漏れ」です。外部から受け取ったホスト名をそのまま名前解決に渡す処理が影響を受けます。
深刻度「中」には、HTTPの接続を使い回す際にリクエスト送信前のレスポンスを受け入れてしまう問題が含まれます*1。
公式の告知には回避策の記載がありません*1。設定変更でしのぐのではなく、修正版へ更新することが対処の基本になります。
もう1つ目を引いたのが、Brotliの不具合の報告者に「OpenAI Codex Security」の名前があることです*1。AIが脆弱性を見つける側に回る流れは加速していて、守る側もAIを使う前提で体制を組む時代に入ったと私は見ています。AIによる脆弱性の発見と修正は、以下の記事で解説しています。
Claude Security公開─Opus 4.7がコードの脆弱性を自動発見・パッチ生成
【AI専門家が徹底解説】DeepMind「CodeMender」とは? コード脆弱性を自動修正するAIが示す新しいセキュリティの形
Vercel・AWS・Cloudflareの比較|自動で直るのはどこまでか
企業の担当者からよく聞かれるのが「うちはクラウドに載せているから大丈夫では?」という質問です。答えはサービスと使い方によって変わります。主要3社の公式ドキュメントをもとに、誰が更新を担うのかを整理しました。
| サービス | Node.jsの更新は誰が行うか | 自社で確認すること |
|---|---|---|
| Vercel | メジャー版(24.x・22.x)を選ぶとマイナー・パッチ版はVercelが展開 | 実際の版数・20系の利用有無 |
| AWS Lambda(マネージドランタイム) | 既定のAutoモードならAWSが適用 | 更新モードの設定・コンテナイメージの再ビルド |
| AWS EC2・ECSなど | 自社(一般論として) | インストールしたNode.jsやコンテナのベースイメージ |
| Cloudflare Workers | Node.jsではなくWorkers独自のランタイム | Node.js互換機能の扱い・開発環境のNode.js |
Vercel|パッチは自動だが版数の確認は自社で
Vercelで選べるのはメジャー版だけで、現在は24.xが既定、22.xも選べます。公式ドキュメントには、セキュリティ修正などが必要な場合にマイナー版とパッチ版をVercelが自動で展開すると書かれています*3。版数は、ビルドコマンドでnode -vを実行するか、process.versionをログに出すと確認できます*3。
気をつけたいのは20系です。Vercelでは2026年10月1日に20系がビルドと関数で使えなくなり、20系のままの関数は新しいデプロイでエラーになります*4。すでに動いている関数はそのまま呼び出せますが、裏を返せば修正の届かない古い版が動き続けることになります。早めに24.xへ移すのが安全です。
AWS|Lambdaは更新モード次第、EC2・ECSは自社の責任
Lambdaのマネージドランタイムには3つの更新モードがあります。既定の「Auto」ではAWSが新しいランタイムを順次適用し、「Function update」では関数を更新したときに適用され、「Manual」では自動更新が行われません*5。コンテナイメージで関数を動かしている場合は、AWSが新しいベースイメージを公開し、再ビルドと再デプロイは利用者が行う分担です*6。
一方でEC2に自分でNode.jsを入れている場合や、ECSで自作のコンテナを動かしている場合は、一般論として中身のNode.jsの更新は利用者側の作業になります。Dockerfileで古いベースイメージを指定したままなら、再ビルドしない限りそのままです。社内で「AWSだから安心」と思われがちな部分なので、構成ごとに分けて確認してください。
Cloudflare Workers|そもそも実行環境が違う
Cloudflare Workersは、Node.jsと同じV8エンジンを使いつつも、独自のWorkersランタイム上で動きます*7。Node.jsのAPIは「一部を提供する」形で、Workersランタイムに組み込んだものと、開発ツールWranglerが補う代替実装の2通りで用意されています*8。そのため今回の修正版の番号は、Workers上のコードにはそのまま当てはまりません。
ただし、Workersのランタイムに個別の影響があるかについて、私が執筆時点で確認した範囲ではCloudflareの見解は見つけられませんでした。また開発者のPCやCI環境にNode.jsを入れている場合は、Workersとは別にそのNode.jsも今回の更新対象と考えてください。
クラウドの設定や更新の運用まで含めて、自社のAIアプリを安全に動かす体制を整えたいと考える方も多いはずです。法人向けAIリスキリングサービスの導入社数No.1*の弊社デジライズが、AIコンサルティング&開発のサービス資料を無料でお送りしています。既製のAIサービスでは要件が満たせず、自社に合わせたシステム構築や環境の検討が必要な場合の進め方をまとめています。
※出典:株式会社東京商工リサーチ「法人向けリスキリングサービスに関する調査」(2026年5月/調査期間:2026年3月26日〜4月17日/調査方法:デスクリサーチおよびヒアリング/2026年3月末時点)
Node.jsの更新の使い方|今日やる5つの確認手順
ここからは、情報システム部門や開発の窓口担当者が今日から動ける手順をまとめます。エンジニアでなくても、どこまで確認できたかを把握するチェックリストとして使えます。
- 洗い出し — 社内で動いているWebサイト・業務アプリ・AIアプリと、その置き場所(Vercel・AWS・社内サーバーなど)を一覧にします。外注先が運用しているものも含めます。
- 版数の確認 — 各環境で
node -vを実行するか、アプリからprocess.versionを出力して、実際に動いている版数を記録します。package.jsonのenginesに書かれた値は「希望」であり、実際の版数とは限りません。 - 修正版への更新 — 22系は22.23.4、24系は24.22.1、26系は26.12.1以上にします。コンテナならDockerfileのベースイメージを更新して再ビルドし、Lambdaなら更新モードを確認します。
- 再デプロイと動作確認 — 更新後にもう一度版数を確かめ、ログインや決済など重要な画面が動くかを確認します。HTTPS通信や圧縮データを扱う機能は特に念入りに見ます。
- 20系以前の移行計画 — サポート終了版が見つかったら、今回のパッチでは直らないことを関係者に共有し、24系への移行日程を決めます。
開発者のPCやCI(自動テスト・自動デプロイの仕組み)で使うNode.jsも忘れがちです。本番だけでなく、コードを作る側の環境も同じ版数にそろえておくと、後のトラブルを減らせます。
Claude CodeやCodexで作ったアプリこそ注意|企業での活用事例と体制
ここ1年で、エンジニアではない社員がClaude CodeやCodexを使って社内ツールを作る例が一気に増えました。私の周りでも、営業部門が自分たちで作ったダッシュボードを日常的に使っています。作るハードルが下がったのは大きな前進ですが、その分「誰が実行環境を管理しているのか分からないアプリ」も増えています。
AIが書いたコードの多くはNode.jsで動きます。コードが正しくても、動かしているNode.jsが古ければ今回のような脆弱性の影響を受けます。Claude Codeの基本的な使い方や料金は、以下の記事で解説しています。
Claude Codeとは?Web版やCoworkとの使い分けから使い方・料金を徹底解説
企業として押さえておきたいのは、作る自由と守る仕組みを同時に用意することです。私がおすすめしている最低限の体制は次の4つです。
- アプリ台帳 — AIで作ったものも含め、社内で動くアプリと公開先・担当者を1枚の表にまとめます。
- 更新の担当者 — 作った本人とは別に、実行環境の更新を見る担当を決めます。外注先が運用している場合は契約上の範囲も確かめます。
- 情報の受け取り口 — Node.js公式ブログの脆弱性ページなど一次情報を定期的に確認する担当を置き、SNSの話題だけで判断しないようにします。
- AIへの確認依頼 — Claude CodeやCodexに「このリポジトリが前提にしているNode.jsの版数を調べて」と頼むと洗い出しが早くなります。ただし結果は必ず実際の環境で確かめます。
AIに更新作業を任せるときの注意
コーディングエージェントにDockerfileや設定の書き換えを任せること自体は有効です。ただし本番環境への反映は、人が差分を見てから行うのが基本です。AIは古い版数を「最新」と思い込んで提案することもあるため、今回の修正版の番号は公式の告知と突き合わせてください。
注意点|「自動更新だから大丈夫」が危ない4つの場面
クラウドの自動更新は心強い仕組みですが、すべてを任せられるわけではありません。公式ドキュメントを読み比べると、次の場面では自社の作業が必要になります。
- サポート終了版を使っている — 20系以前には修正版が出ません。自動更新の仕組みがあっても直る版そのものが存在しない状態です。
- コンテナで版数を固定している — Lambdaのコンテナイメージや自作のECSコンテナは、ベースイメージを更新して再ビルドしない限り古いままです。
- 更新モードを手動にしている — LambdaのManualモードでは自動更新が行われません。一時的な切り戻しのつもりが、そのまま放置されていないか確認します。
- 互換ランタイムを使っている — Cloudflare WorkersのようにNode.jsとは別の実行環境では、Node.jsの修正版番号で安全性を判断できません。提供元の情報を別に確かめます。
また、セキュリティの更新でアプリの動きが変わることもまれにあります。今回の修正はTLSのホスト名検証にも及ぶため、IPアドレスの書き方に依存した古い接続設定があると、更新後につながらなくなる可能性も考えられます。テスト環境で一度動かしてから本番へ反映すると安心です。
まとめ
- 何が起きたか — 2026年10月21日にNode.jsが10件の脆弱性を修正し、うち4件は深刻度「高」でした。
- 修正版 — 22.23.4・24.22.1・26.12.1以上へ上げ、20系以前は移行を急ぎます。
- クラウドの違い — Vercelはパッチ自動、Lambdaは更新モード次第、EC2・ECSは自社、Workersは別の実行環境です。
- 企業の備え — AIで作ったアプリも含めて台帳と更新担当を決め、版数を数字で確かめる運用にします。
AIのおかげで、誰でもアプリを作れる時代になりました。だからこそ、コードの中身だけでなく、それを動かす実行環境まで気を配ることが企業の信頼を守ります。私のおすすめは、今日中に社内のNode.jsの版数を一覧にし、修正版に届いていないものから順に更新することです。最初の一覧づくりさえ済めば、次の脆弱性が出たときも慌てずに動けます。
参考資料
- *1 Node.js「Wednesday, October 21, 2026 Security Releases」
- *2 Node.js「Node.js Releases(Previous Releases)」
- *3 Vercel「Supported Node.js versions」
- *4 Vercel「Node.js 20 is being deprecated on October 1, 2026」
- *5 AWS「Understanding how Lambda manages runtime version updates」
- *6 AWS「Understanding the shared responsibility model for Lambda runtime management」
- *7 Cloudflare「How Workers works」
- *8 Cloudflare「Node.js compatibility」
