「PHPに重大な脆弱性。うちのサイトは対応できているだろうか」。サーバー会社や制作会社へ確認した方もいると思います。前回の記事では、WordPressへの影響と、レンタルサーバーごとの確認事項を整理しました。
その対応とあわせて、Node.jsを使っているシステムも確認してください。PHPと同じ2026年10月21日付で、Node.jsにもセキュリティ修正版が公開されています。
今回、PHPの公式評価はCritical、Node.jsの最高評価はHighです。ただし、Node.jsにも外部からプログラムを実行されるおそれのある問題が含まれます。「PHPほど重大ではなさそうだから、確認しなくてよい」とは判断できません。
まず必要なのは、自社で使っているか、誰が更新するか、実際に反映されたかを確認できる状態にすることです。
この記事は、2026年10月22日に確認した公式情報に基づく解説です。個別のシステムの影響や、攻撃を受けたかどうかを調査した結果ではありません。
Node.jsとは何か。自社でも使っている？
PHPとNode.jsは、どちらもWebサイトや業務システムのプログラムを動かすための基盤です。ここでは、まとめて「実行環境」と呼びます。
PHPはWordPressの土台として知られています。一方、Node.jsはWebサービス、外部サービスとの連携、開発や自動処理のツールなどで使われます。普段は名前を意識していなくても、制作会社が納品したサイトや、自社開発のサービスで利用している可能性があります。
ただし、使っていることと、今回の攻撃が成立することは別です。 たとえば、サイトを作成するときだけNode.jsを使い、公開時は作成済みの静的なページを配信する構成もあります。自社のどこで使っているかを、保守担当者に確認するところから始めましょう。
PHPと比べて、今回はどのくらい重大なのか
今回の公表内容には、次の違いがあります。
| 見る点 | PHP | Node.js |
|---|---|---|
| 公式が示す重大度 | 2件ともCritical。CVSSという評価指標では9.2 | 今回の最高評価はHigh |
| 主な問題 | 認証なしで外部からプログラムを実行されるおそれ | 外部からプログラムを実行されるおそれ、通信相手の確認を回避される問題など |
| 影響を調べるときの注意 | Webリクエストを処理する構成が広く対象。特にApacheのmod_phpでは、アプリの処理前の攻撃が実証されている | 問題ごとに対象の版や処理が異なるため、使い方も含めて確認する |
出典：PHP公式のセキュリティ勧告、Node.js公式のセキュリティ勧告。それぞれの公式評価を並べた表であり、個々のシステムの被害の大きさを測った結果ではありません。
PHPの公表内容からは、広い構成で緊急に対応を確認する必要があります。ただ、Node.jsの「High」も、被害が軽いという意味ではありません。 実際の優先順位は、外部から攻撃が届くか、どの情報を扱っているか、修正が入っているかまで含めて判断します。
これは「PHPよりNode.jsのほうが安全」という言語全体の比較ではありません。今回のPHP対応を優先して進めながら、Node.jsも確認の対象へ加える、という話です。
HTTPSでも、接続相手の確認に不備があれば安全性は損なわれる
WebサイトのURLが https:// で始まっていると、通信は安全だと考えがちです。しかし、安全な通信には、通信内容の暗号化に加えて、正しい相手に接続していることの確認も必要です。
今回のNode.jsには、特定のホスト名・IPアドレスの扱いで、証明書と接続先の照合を回避される問題も含まれています。HTTPSを使っていても、接続相手の確認に不備があれば安全性は損なわれます。
図は、Node.js公式のTLS解説と今回の勧告をもとに、確認の役割を整理したものです。
今回確認したいのは、Node.jsで動く自社システムが、外部のAPI（サービス連携の窓口）などへ接続する処理です。利用者のブラウザーそのものの脆弱性を指す説明ではありません。
公式勧告では、TLSという安全な通信の仕組みについて、全角数字のIP表記に関する問題（CVE-2026-105483）と、IPアドレスとして緩く解釈されるホストに関する問題（CVE-2026-106069）を挙げています。前者は24.x・26.x、後者は22.x・24.x・26.xが対象です。Node.js公式の説明をもとに、担当者が利用環境と照合してください。
すべてのHTTPS通信が危険になった、という意味ではありません。 今回のような特定の処理の不備を修正するために、実行環境の更新も必要だということです。
通信以外にも、プログラムを実行されるおそれがある
今回の修正には、Brotliという形式の圧縮データを展開する処理の問題（CVE-2026-111497）も含まれます。公式は、遠隔コード実行につながる問題として、22.x・24.x・26.xを対象に挙げています。
遠隔コード実行とは、外部から攻撃者のプログラムを動かされることです。成功した場合、実行権限などによって、情報の窃取や改ざん、サービス停止につながり得ます。ただし、公式勧告は具体的な攻撃経路を網羅していません。自社への影響は担当者が確認し、「圧縮処理を自分では書いていないから無関係」とは判断しないでください。
図解：見落としたくない3つの確認
図は、今回の修正情報を会社の対応へつなげるための整理例です。以下の3点を保守担当者や委託先へ確認すれば、細かな技術用語が分からなくても状況を把握できます。
1. どのシステムで使っていて、誰が担当するか
会社のWebサイトだけでなく、顧客向けサービス、社内システム、外部サービスとの連携も対象に挙げます。開発や自動処理で使うものも、担当者に洗い出してもらいましょう。
「マネージドサービスだから事業者が全部やるはず」と決め付けず、契約上の保守範囲と、利用者側の作業が残るかを確認します。自社で使っているか分からない場合は、「未確認」として担当者を決めるところから始めてください。
2. 修正済みの版へ、いつ更新するか
今回公開されたNode.jsの修正版は、次の3つです。
| 利用中の系列 | 今回の修正版 | 10月22日時点の位置付け |
|---|---|---|
| 22.x | 22.23.4 | LTS（長期サポート） |
| 24.x | 24.22.1 | LTS（長期サポート） |
| 26.x | 26.12.1 | Current（新しい機能を提供する段階） |
出典：Node.js公式リリースノートの22.23.4、24.22.1、26.12.1。後日読む場合は、その後の修正を含む版も確認してください。
「Node.js 24です」「LTSです」という回答だけでは、今回の修正が入っているか分かりません。末尾の番号まで、または提供元の修正情報まで確認してもらいましょう。公式サポートが終了した20.xなどは、一覧に載っていないから安全という意味ではありません。公式のサポート状態と照合し、移行計画を立てます。
すべてを26.xへ上げる必要はありません。公式は本番向けにLTSを案内しており、利用中のLTS系列で修正を適用する判断もできます。更新で業務に影響が出ないかの確認とあわせて、担当者と期限を決めましょう。すぐ更新できない場合は、公開範囲や対象機能を制限する必要があるかも判断します。
3. 更新が、実際に動く環境へ反映されたか
開発用PCだけ更新しても、本番サーバーやコンテナ（実行環境をまとめたもの）が古いままなら、本番の対応は終わりません。必要な再起動や再デプロイまで含めて、反映を確認します。
担当者からは、対象のシステム名、反映後の版、確認日時、主要機能の動作確認結果をもらいましょう。更新の予定と、作業の完了と、稼働環境での確認は、それぞれ区別して記録します。
また、「依存パッケージの監査で問題は出ませんでした」という報告だけでは、Node.js本体の更新確認にはなりません。たとえばnpmの監査機能は、プロジェクトの依存パッケージを調べる仕組みです。PHPとWordPressの更新を分けて確認するのと同じように、アプリ側と実行環境側の保守をそれぞれ確認してください。
保守担当者へ送る、確認依頼の例
PHPの重大脆弱性への対応とあわせて、10月21日に修正版が公開されたNode.jsについても確認をお願いします。
自社で使っているシステム、今回の修正の適用状況、未対応の場合の担当者と予定を教えてください。
対応済みの場合は、実際に動いている環境の版と確認日時、主要機能の動作確認結果も共有してください。
確認する対象と担当者を決め、対応に必要な時間や判断を支える。その一歩から始められます。PHPのニュースをきっかけに、Node.jsを含む自社システムの保守まで確かめておきましょう。