脆弱性の修正版は、なぜ夜中にひっそり出てくるのか

CVE は脆弱性1件ごとに振られる世界共通の番号で、今回は CVE-2026-109618 と CVE-2026-109619 の2件です。番号があるので、ニュース・メーカーの告知・社内の対応表で「同じ穴の話か」を取り違えずに済みます。CVSS は深刻度を0〜10点で表す採点の仕組みで、今回の最新版（v4.0）では 0.1〜3.9 が「低」、4.0〜6.9 が「中」、7.0〜8.9 が「高」、9.0〜10.0 が「緊急」です。9.2 は緊急の帯に入ります。

php.net の告知によると、2件はどちらも認証なしでサーバー上の任意のコードを動かせる（リモートコード実行）恐れがあるものです。1件はメモリ不足の処理が途中で割り込み、作りかけの内部データを正しいものとして片付けてしまう問題。もう1件は、すでに解放されたメモリを指す内部の状態が次のリクエストまで残ってしまう問題です。PHP-FPM、Apache の mod_php、php-cgi など、Webのリクエストを受ける構成はほぼすべてが対象で、mod_php ではアプリのコードが動く前に攻撃が成立する例が示されています。WordPress のような「PHPで動くもの」が巻き込まれるのは、穴がアプリではなく PHP 本体の側にあるからです。

PHPのセキュリティチームは10月20日、「21日14時（UTC）に重大な修正版を出す。2件とも CVSS v4.0 で9.2」とだけ告知し、中身は伏せました。これは「協調的な脆弱性開示」と呼ばれる慣習で、見つけた側と直す側が公開日を決め、その日まで詳細を出しません。先に詳しく書けば、直す前に攻撃者に手口を教えることになるからです。一方で、利用者が更新の準備をできるよう日時だけは先に知らせます。予告には「詳細が漏れたり、実際の攻撃が見つかったりしたら前倒しする」とも書かれていました。

告知には「Linux ディストリビューションと LTS の提供元には、事前に修正を渡してある」とあります。サーバーの多くは PHP を自分でビルドせず、配布元のパッケージで入れているため、公開と同時にそれぞれの更新が出せるよう、先に限られた相手にだけ配っておくのです。ただし全員が間に合うわけではなく、今回はボランティアで運営されている配布元（remirepo）について「今日は更新が出ない」と明記されました。PHP 8.1 以前はもう PHP プロジェクトの更新対象外ですが、今回は深刻さを踏まえ、7.4・8.0・8.1 向けにも最小限の修正が別に用意されています。

2012年5月の CVE-2012-1823 は、php-cgi がURLの一部をコマンドの指定として読んでしまう穴でした。2019年10月の CVE-2019-11043 は、nginx と PHP-FPM の特定の組み合わせで外からコードを動かせるもの。2024年6月の CVE-2024-4577 は、Windows の文字の置き換え（Best-Fit）を突いて php-cgi に命令を渡せるもので、公開から3日で米国 CISA の「悪用が確認された脆弱性」の一覧に入りました。3件とも NVD の評価は 9.8（CVSS v3.1）で、いずれもこの一覧に載っています。公開された穴は、直されるまでの間に狙われる。夜中でも更新を急ぐ理由はここにあります。

①CVSS が9.0以上か（緊急かどうか）。②「認証なし」「リモートから」と書かれているか（外から誰でも狙えるか）。③自分の使っている構成や版が対象に入っているか。今回は3つともそろっており、PHP で動くサイトを持つ人は 8.5.12・8.4.27・8.3.36・8.2.35 のいずれかへすぐ更新するのが答えでした。人と話すなら「23時は世界時間の14時。中身を伏せて日時だけ予告し、配布元に先に修正を渡してから一斉に出すのが作法」と言えると、ニュースの見え方が変わります。