はじめに
2026年10月下旬、PHP、Node.js、Chrome、Goの重大な更新が立て続けに公開されました。私はこれを「脆弱性ラッシュ」と呼んでいます。
一斉に更新を進めるなかで、すでにサポートが切れている php7.4-fpm や Node 18 が見つかり、作業が想定より大規模になりました。この記事では、何が起きたか、どう対応したか、何を学んだかをまとめます。
何が起きたか(時系列)
| 日付(2026年) | 内容 |
|---|---|
| 10/13〜15 | Chromeが37件、続いて10件の脆弱性を修正 |
| 10/19 | Go 1.26.10が crypto/x509 のセキュリティ修正を公開 |
| 10/21 | PHP2Shellの修正版、Brotliの修正版、Node.jsのセキュリティリリースが同日に公開 |
| 10/25〜 | BrotliがPowerShellや.NETにも波及 |
| 10/27 | Chrome 156系で52件を修正(うち4件がCritical) |
PHP2Shell(CVE-2026-109618 / CVE-2026-109619)
- 2件の脆弱性の通称で、いずれもCVSS v4.0で9.2(Critical)。認証なしでリモートコード実行につながるおそれがあります。
- 修正版は PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。修正版の公開前に情報が流出し、攻撃の試行も確認されています。
- CVE-2026-109618 は multipart リクエストを細工してメモリ不足を起こす攻撃、CVE-2026-109619 は中断したリクエストの残骸を次のリクエストに使わせる攻撃です。
- その後、3件目の CVE-2026-115560 も報告されましたが、緊急パッチは出ていません。
Brotli(CVE-2026-111497、通称 HTTP2Shell / Node2Shell)
- Googleの圧縮ライブラリ Brotli のデコーダーにあるバッファオーバーフローで、1.0.3〜1.2.0 が影響を受けます。CVSS 9.2。Node.jsではコード実行が実証され、攻撃の試みも観測されています。
- 修正版は Brotli 1.0.10 / 1.1.1 / 1.2.1。
- 当初はNode.jsの問題として報告され「Node2Shell」と呼ばれましたが、HTTPを扱う他のライブラリやアプリにも影響が及ぶと分かり、「HTTP2Shell」という呼称が使われ始めました。
- PowerShell(7.6.9 / 7.5.13 / 7.4.22)や .NET(10 / 9 / 8)でも修正が出ました。
- 厄介なのは、アプリやライブラリが内部にBrotliを抱えていることです。OSのパッケージを更新しても残る場合があり、自分が使っているソフトにBrotliが入っているか自体が分かりにくい点が教訓になりました。
Node.js
- 10月21日のセキュリティリリースで、26.x / 24.x / 22.x の3系統に修正版(v26.12.1 / v24.22.1 / v22.23.4)が出ました。修正は計10件で、Highが4件です。
- 開発チームは、サポート終了済みの旧バージョンの利用者にも、サポート対象への移行を求めています。
Chrome
- 10月27日に Chrome 156.0.8078.73/.74 がリリースされ、52件を修正しました。
- Criticalには、FileSystemのメモリ破損(CVE-2026-118306)やFileAPIの入力検証不備(CVE-2026-118331)などが含まれます。
Go
- Go 1.26.10(10/19公開)で crypto/x509 のセキュリティ修正が入りました。
- 私の環境では Go 1.22.4 が稼働していました。1.22系はすでにサポート対象外で、今回の修正も降ってきません。サポート中の系統への移行が必要でした。
対応で起きたこと
構成は Ubuntu Server 4台(22.04 / 24.04) です。
調べてみると、複数台のサーバーで古いバージョンのプログラムが動いていました。PHPとNodeだけでなく、OSのアップデートを含めて様々なプログラムの更新が必要になり、GPUドライバーなど、今回の脆弱性とあまり関係のない部分にまで影響が波及して、想定よりかなり大規模な作業になりました。
特に見つかったのは次のものです。
-
php7.4-fpmが稼働していた(7.4には修正版が存在しない) - Node 18 が稼働していた(同じく修正版なし)
- Go 1.22.4 が稼働していた
- パッケージ上は
php8.3-fpmとnode21が入っていたのに、移行が進んでおらず、古い側が実際に動いていた
7.4と18には修正版がないため、「パッチを当てる」ではなく「移行する」作業になり、規模が膨らみました。
調査に使ったコマンド例です。
# 入っているPHPと、実際に動いているfpmを両方確認する
dpkg -l | grep -E '^ii\s+php'
systemctl list-units --type=service | grep -i php
php -v; php-fpm8.3 -v
# Nodeは実行中のプロセスのバージョンまで見る
node -v
ps aux | grep -i node
# Goはバイナリごとのビルドバージョンも確認できる
go version
go version -m /path/to/your/binary
ポイントは、「インストールされているもの」と「実際に動いているもの」は別物だということです。
教訓
1. 定期的なアップデートを仕組みにする
新しいバージョンを入れていても、古いものが残っていれば意味がありません。気づいたときに更新するのではなく、unattended-upgrades や Renovate / Dependabot などで自動化・定期化します。
更新を溜め込むほど、今回のようにOSやドライバーまで連鎖して大工事になります。小さく頻繁に更新するほうが、結果的に楽でした。
2. サポート期限を定期的に確認する
PHP 7.4 には今回の修正が降ってきませんでした。サポートが切れると、脆弱性が見つかっても直す手段がない状態になります。endoflife.date などで期限を確認し、カレンダーに入れておくと安全です。
Node.js は偶数番号のLTS系統を選ぶのが基本です。奇数番号(21など)は短命のリリースで、早くにサポートが終了します。
3. 同梱ライブラリは別途追跡する
Brotli のように、本体を更新しても内部の依存が古いまま、というケースがあります。SBOM、npm audit、コンテナスキャンなどで把握しておくと見落としが減ります。
4. 暫定対策は時間を稼ぐもので、解決ではない
WAFの防御策などは当面の盾になりますが、根本は更新と移行です。
おわりに
脆弱性は、重なるときは一斉に来ます。そのとき慌てずに済むのは、日頃から「何がどこで動いているか」と「いつサポートが切れるか」を把握している人です。この記事が、同じ状況の方の棚卸しの参考になれば幸いです。