10月22日を、開発者の非公式な記念日「バグの日」と呼びたくなる出来事がありました。前日の2026年10月21日、PHPは認証なしのリモートコード実行(RCE)につながる重大度Criticalの脆弱性2件を修正し、Node.jsも計10件のCVEに対処するセキュリティ更新を公開しました。うちNode.jsの4件はHighです。偶然重なった更新を軽く笑うことはできても、企業にとっての課題は明確です。アプリケーションが正常に動いていても、その土台が安全とは限りません。[1][5]
同じ日にPHPとNode.jsで何が修正されたのか
PHPが修正したのはCVE-2026-109618とCVE-2026-109619です。PHP Security Teamは両件をCriticalと評価し、条件が成立すると認証していない第三者によるリモートコード実行が可能になると説明しています。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12。Linuxディストリビューションやホスティング事業者の提供パッケージを利用している場合は、バックポートの有無を含めて提供元の情報を確認する必要があります。[5]
一方、Node.jsは22.23.4(LTS)、24.22.1(LTS)、26.12.1(Current)を公開しました。セキュリティ通知に記載されたCVEは計10件で、Highが4件、Mediumが3件、Lowが3件です。PHPとNode.jsの脆弱性に技術的な関連があると示す情報はありません。ただ、いずれも企業のWebサービスを下支えする実行環境である点が重要です。[1][2][3][4]
特に注意したいBrotliの脆弱性:RCEの可能性
Highの中で注目すべきなのはCVE-2026-111497です。Node.jsのBrotliデコーダーで領域外書き込み(out-of-bounds write)が発生し、リモートコード実行につながる可能性があると公式に説明されています。BrotliはWeb通信などで使われる圧縮方式です。実際に影響を受けるかどうかは、信頼できない圧縮データが該当処理に到達するかなど、アプリケーションの構成によって異なります。RCEの可能性と、実際の攻撃が広く確認されたことは別です。[1]
残るHighの3件はDNSとTLSに関係します。CVE-2026-105482はNUL文字を含む名前をdns.resolveが切り詰めて扱う問題、CVE-2026-105483は全角数字を使ったIPアドレスの証明書ホスト名検証、CVE-2026-106069はIPアドレスとして緩く解釈されるホスト名でのTLS検証に関する問題です。Brotliとは原因が異なりますが、外部システムとの通信や接続先の本人確認を行うサービスにとって重要です。[1]
MediumにはCVE-2026-105481(HTTP keep-alive接続での応答処理)、CVE-2026-106072(非標準表記のIPv4アドレスと証明書の検証)、CVE-2026-106074(startup snapshotや単一実行ファイルで一部の乱数生成結果が繰り返される可能性)が含まれます。LowはCVE-2026-106070(ZIPヘッダー検証)、CVE-2026-106071(Permission Modelでの過剰な権限付与)、CVE-2026-106073(fs.realpathSyncによるPermission Modelの回避)です。影響範囲はバージョンや使用機能により異なります。[1]
Node.jsのバージョンごとに対象CVEは異なる
公式の一覧では、22.xで7件、24.xで8件、26.xで10件が影響対象です。対応先はそれぞれ22.23.4、24.22.1、26.12.1、または同一のサポート対象系列でそれ以降に公開された修正版となります。Lowのうち2件は26.xのみが対象です。[1][2][3][4]
Node.js 20と25を稼働させている場合は、パッチ適用だけでなくバージョン系列の移行計画が必要です。公式EOLページによれば、両系列の最終更新はそれぞれ2026年3月24日と3月31日。EOL後は通常のセキュリティ更新が提供されません。アプリが問題なく動いていることと、修正プログラムが届くことは同じではありません。[6]
開発チームだけの問題ではない理由
企業では、API・認証・受注処理にNode.jsを使い、会社サイトやWordPress、古い管理画面にはPHPを利用していることがあります。顧客には見えない基盤ですが、脆弱性が悪用されればサービス停止、情報漏えい、復旧費用などの事業上の影響が生じかねません。
リスクは、ソースコードにJavaScriptやPHPがあるかどうかだけでは判断できません。ビルド時にNode.jsを使った静的サイトと、インターネットから入力を受け付けるNode.jsのAPIでは攻撃面が異なります。一方、開発用ライブラリを更新しても、本番のコンテナ、SSRサーバー、バッチ処理、外部ソフトウェアが古い実行環境を使い続けることはあります。
「バグの日」の翌日にやるべきこと
まず本番環境で実際に起動しているランタイムのバージョンを確認します。開発者のPCで新しいNode.jsを使っているだけでは不十分です。プロセスやコンテナイメージを調べ、サポート対象の修正版へ移行し、互換性を確認します。PHPは公式修正版またはディストリビューションの対応パッケージを確認し、管理権限がない場合はホスティング事業者と担当範囲を明確にします。[1][5]
更新後はワークロードを再配置し、実際に新しい実行ファイルが読み込まれたことを確認します。ログイン、決済、注文などの主要経路をテストし、エラー監視と切り戻し手順も用意します。npm updateで依存パッケージを更新しても、稼働中のNode.js本体が自動的に置き換わるわけではありません。
特に信頼できない圧縮データを取り込むサービスではBrotliの解凍経路を点検し、公開PHPサーバーは優先して更新すべきです。PHPの公式通知は、暫定的な緩和策では完全に安全にならず、修正版の適用が必要だとしています。すぐに対応できない場合も、担当者・期限・一時的な防御策を定めて管理することが重要です。[1][5]
記念するなら、ランタイムを点検する日に
「バグの日」はAutomizeが2026年の偶然の重なりにつけた呼び名です。公式記念日ではなく、毎年10月22日に脆弱性が集中するという意味でもありません。オープンソースの開発者が脆弱性を見つけ、公開し、修正することは健全な保守活動です。CVEの数だけでソフトウェア品質を評価するのも適切ではありません。
それでも10月22日を年に一度のきっかけにするなら、運用中のシステムを棚卸しし、サポート終了の有無、更新の責任者、そして修正版が本番まで反映されたかを確認する日にしたいところです。ケーキよりも、正確な台帳と検証済みのパッチが実用的な「お祝い」になるはずです。
参考文献・出典
- [1]Wednesday, October 21, 2026 Security Releases Node.js Project · 2026-10-21
- [2]Node.js 22.23.4 (LTS) Node.js Project · 2026-10-21
- [3]Node.js 24.22.1 (LTS) Node.js Project · 2026-10-21
- [4]Node.js 26.12.1 (Current) Node.js Project · 2026-10-21
- [5]Security advisory: Critical remote code execution vulnerabilities, update now PHP Security Team · 2026-10-21
- [6]Node.js End-of-Life versions and last updated dates Node.js Project · truy cập 2026-10-23




