Node.jsの脆弱性【2026年10月】影響・修正版・確認する場所

2026年10月21日、Node.jsのセキュリティ修正版が公開されました。Node.jsを使うサーバーや開発用ツールを管理している人は、修正の適用を確認する必要があります。サービスを利用するだけの人は、まず提供元のお知らせを確認します。

修正版は、22系が22.23.4、24系が24.22.1、26系が26.12.1です。今回の問題には、不正な処理を実行されるおそれがあるものも含まれます。ただし、Node.jsを使うすべての場所で、同じ条件の攻撃ができるという意味ではありません。

「名前も知らなかったのに、更新と言われても困る」という人は、下の立場別の表から読めます。この記事は2026年10月22日に確認した情報をもとにしています。

Node.jsの脆弱性は誰に関係する？

Node.js（ノード・ジェイエス）は、JavaScriptで書かれたプログラムを、ブラウザの外でも動かせるソフトウェアです。JavaScriptは、Webページに動きをつける際にも使われるプログラミング言語。Node.jsがあると、その言語で、Webサービスの裏側で返事を作ったり、手元のPCで開発用の道具を動かしたりできます。

今回の弱点があるのは、その仕事を支えるNode.jsです。このような、安全を損なう弱点を「脆弱性（ぜいじゃくせい）」といいます。ページの文章や、自分で決めたパスワードだけを変更しても、Node.js自体の修正にはなりません。

AIと外部の道具をつなぐ仕組みでは、道具の一部がNode.jsで動くことがあります。ただし、AIアプリやMCPの接続先が、すべてNode.jsを使うわけではありません。 名前だけで決めず、導入した道具の説明を確かめます。

また、ブラウザでJavaScriptを動かすことと、Node.jsを自分のPCで動かすことは別です。ニュースを読んだだけで、新たにNode.jsをインストールする必要はありません。

Node.jsの修正版は22・24・26系で異なる

Node.jsの版番号には、22、24、26のような大きな区分があります。これを「系列」と呼びます。今回、公式が公開した修正版は次のとおりです。

これはNode.js公式の2026年10月セキュリティ告知に掲載された版です。後日、新しい修正版が出た場合は、提供元の最新の案内も確認してください。

「数字が最大の26へ、全員が変更する」という表ではありません。使っているアプリが対応する系列で、修正が入った版を選びます。大きな系列を変える場合には、アプリがこれまでどおり動くかの確認も必要です。

公式の今回の評価では、最も高い深刻度は**HIGH（高）**です。先に公表されたPHPの脆弱性とは別の問題なので、PHPの「9.2」という数値をNode.jsへ当てはめることはできません。識別番号と深刻度の読み方は、CVEとCVSSの違いで整理しています。

表にない古い系列についても、「書かれていないから安全」とは判断できません。サポートが終了した系列を使っている場合は、提供元が案内するサポート中の環境への移行も含めて相談します。

Brotliの脆弱性でコードを実行されるとは

今回の修正の一つに、CVE-2026-111497があります。Brotli（ブロトリ）という方式で小さくしたデータを、元の形へ戻す処理の問題です。

画像や文章などのデータは、送る量を減らすために「圧縮」することがあります。受け取った側がそれを使うには、圧縮をほどいて戻す処理が必要です。この処理をするものを、デコーダと呼びます。

公式告知は、Node.jsのBrotliデコーダで、書き込んではいけない範囲へ情報を書き込む問題を報告しています。コンピューターが作業中の情報を置く場所には、用途に応じた区切りがあります。その区切りを越えて書くと、別の情報を壊し、不正な処理につながるおそれがあります。

この問題で起こり得るとされたのが、リモートコード実行です。離れた相手から、対象のコンピューターに意図しない処理を実行させられることを指します。データを読まれる、書き換えられるなどの被害につながり得るため、優先して対応する必要があります。

ただし、影響する機能が、外部から来たデータをどのように処理するかは、アプリの構成で変わります。「Node.jsが入っていれば、何もしなくても全部乗っ取られる」と決まったわけではありません。詳しい被害の範囲は、リモートコード実行と権限の関係でも説明しています。

また、脆弱性の公表だけでは、自分の環境ですでに悪用されたかは分かりません。修正の確認と、侵入された形跡の調査は、それぞれ別の仕事です。

TLS・DNSなど、Node.js更新で直った問題

今回はBrotliだけの更新ではありません。公式告知には10件の問題が記載されており、ほかのソフトウェア部品の更新も含まれています。

名前の多さに圧倒されそうなら、「どの仕事の確認を直したか」で分けるとつながります。

TLSは、通信を暗号化し、相手の確認にも使う仕組みです。DNSは、サイトの名前から接続先を調べる仕組みを指します。通信先を示す住所にあたるものが、IPアドレスです。名前や住所の表記が少し違うときも、意図した相手かを正しく判断する必要があります。

この表は問題を読むための整理です。10件が全部同じ原因でも、全部リモートコード実行でもありません。 個々の影響条件を調べる仕事は管理担当者に任せ、利用者は自分の使うサービスの対応状況へ進めます。

Node.jsのバージョン確認はどこを見る？

確認でつまずきやすいのは、Node.jsが一か所だけにあるとは限らないことです。手元のPCを更新しても、公開中のサービスのサーバーまで同時に更新されるとは限りません。

たとえば、制作担当者が自分のPCでサイトを作り、別のサーバーで公開しているなら、それぞれで使う版を確かめます。アプリを動かす環境をひとまとめにした「コンテナ」を使う場合は、その中にもNode.jsが含まれることがあります。

普段からコマンドを使う人なら、node --version は、その画面から呼び出されるNode.jsの版を表示する読み取り用の指示です。この表示だけで、別のサーバーやコンテナ、すでに動いているすべての処理まで確認できたことにはなりません。

文字を入力する操作に慣れていない人は、無理に試さなくて大丈夫です。管理画面の情報や担当者への問い合わせで確認できます。

問い合わせるなら、次の形にすると、確認したい対象が伝わります。

私たちが利用しているこのサービスでは、Node.jsを使っていますか。使っている場合、2026年10月21日のセキュリティ修正は、このサービスが動く環境へ適用されていますか。

配布元が、版番号の表示を保ちながら修正だけを取り込むこともあります。この場合は、見た目の番号だけで未対応と決めず、配布元のセキュリティ情報と照合します。

Node.jsの更新は誰が行い、何を確かめる？

自分で管理する環境なら、導入した方法に合う公式の更新手順を使います。更新後は、実際に動いている環境へ修正が反映されたことと、アプリが正常に動くことを確認します。再起動や再配備が必要かは、その構成の手順に従ってください。

ホスティング会社などへ管理を任せている場合は、会社側の対応範囲と、自分が操作する範囲を確かめます。「会社が対応中」と「自分のアプリへ適用済み」は、同じ意味ではありません。

一方、サービスを使うだけの人が、提供元のサーバーを直接更新することはできません。利用中のサービスの案内を確認し、メンテナンスや利用者向けの対応が示されたら、それに従います。今回のニュースだけを理由に、すべてのパスワードを変更すれば解決するという話でもありません。

今回のPHPの脆弱性と共通するのは、画面の裏側を支えるソフトにも修正が必要になることです。ただし、更新するソフトも、確認する担当も、それぞれ異なります。

まずは「このサービスの裏側を管理しているのは誰か」を一つ確かめてください。分からなかった名前が、問い合わせ先と結びつけば、必要な確認を進められます。