10月21日に、PHPの修正版がいつもと違う出方をした。前日のうちに、翌日の14時(UTC)に重大な修正版を出すという予告が流れ、その予告には、詳細が漏れたり攻撃が始まったりしたら前倒しで出す、とまで添えられていた。PHPの開発チームがこういう告知を出すのは珍しい。そして実際に、予告の日のうちに詳細が外へ漏れ、Cloudflareは修正版が出る数時間前に攻撃の通信を観測したと伝えている。
出たのは PHP 8.5.12、8.4.27、8.3.36、8.2.35 の4本で、CVE-2026-109618 と CVE-2026-109619 の2件を直している。どちらも CVSS v4.0 で 9.2 という高い評価がついていて、ログインなしで遠隔からコードを動かされる可能性があるとされる。通称は PHP2Shell。WordPressのサイトを預かる立場として、何がどこまで自分たちの話なのかを整理しておきたい。
穴はWordPressの下の層にある
今回の2件は、プラグインやテーマの不具合ではなく、PHPという言語の実行環境そのものの問題だ。PHPの公式の告知によると、1件目はメモリ不足でPHPの処理が途中で止まったとき、まだ準備の終わっていない内部データを後片付けの処理が正しいものとして扱ってしまうという内容。2件目は、あるリクエストで使った内部の状態がメモリを解放した後も残り、同じ作業プロセスが次のリクエストを処理するときにその古い状態を使ってしまうという内容だ。
どちらも、PHPがリクエストを受け取ってから、WordPressの最初の一行が動くまでの間に起きる。Sansec の解説では、PHPのアップロード進捗を扱う処理がアプリケーションの手前で走るため、サイト側が何もしていなくても攻撃が成り立つとされている。さらに、解放済みのメモリの中身が PHPSESSID のクッキーに乗って返ってくる経路もあり、そこには他のリクエストが使ったパスワードやトークン、APIキーが含まれうるという。Patchstack は、Wiz Research が「Hello World」を表示するだけのPHPアプリでも成立することを示したと伝えている。
つまり、WordPressやプラグインをどれだけこまめに更新していても、この穴は塞がらない。WordPress.org もこの件でWordPress側の更新は出さないと明言していると、Codeable が伝えている。直すのはサーバーのPHPで、それ以外に完全な対策はないというのがPHP側の立場だ。
影響を受けるのはどの動かし方か
PHPの告知は、ウェブのリクエストを受けるPHPはすべて対象だとしている。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed のいずれも含まれる。その中で最も危険度が高いとされたのが mod_php で、認証のないリクエスト1本で、アプリケーションのコードが動く前に攻撃できることが実証されている。
PHP-FPM なら安全というわけでもない。Qualys のまとめによると、FPM は起動時の挙動のおかげでメモリ不足を使う経路のひとつは防げるものの、セッションまわりの経路での遠隔コード実行はFPMでも確認されている。Sansec も、既定の設定のままで脆弱であり、問題のコードは2012年の PHP 5.4.0 から入っていたと書いている。14年前から同じ場所に穴があったことになる。
直すのは誰かという問題
ここからが実務の話になる。Codeable の整理が分かりやすいので、それに沿って考えてみる。マネージドのWordPressホスティングなら、PHPの更新は事業者側が行う。共用のレンタルサーバーも、サーバー全体のPHPを事業者が差し替える。この2つの形態では利用者が触れる設定はほとんどなく、できるのは事業者の告知を確かめることと、自分のサイトがどの版のPHPで動いているかを把握することくらいだ。
一方、VPSやクラウドのサーバーに自分で環境を作っている場合、あるいは制作会社がサーバーごと預かっている場合は、誰も代わりに直してくれない。パッケージを更新してPHPを再起動し、すべての作業プロセスが新しい版で動いていることを確かめるところまでが仕事になる。配布元によって更新が届く速さが違う点にも注意がいる。Ubuntu の公式パッケージや Sury のリポジトリは当日中に出たが、RHEL 系で広く使われる Remi のリポジトリは当日は更新を出さないとPHP側が告知しており、別の入手経路を考える必要があった。
自分のサイトのPHPの版は、WordPressの管理画面の「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」の欄で確かめられる。ただし、Linuxのディストリビューションが配るPHPは、版の数字を変えずに修正だけを取り込むことが多い。表示されている数字が古く見えても、未対応とは限らない。迷ったら、10月21日の修正が当たっているかを事業者に直接聞くのが確実だ。
古いPHPのまま動いているサイト
今回の件で、もうひとつ重みを持つのが、サポートの切れたPHPで動いているサイトの扱いだ。PHPの開発チームが修正版を出すのは 8.2 以降だけで、8.1 以前には公式の修正版が出ない。例外として、自分でソースからPHPを組み立てる人向けに 7.4、8.0、8.1 の最小限の修正を公開しているが、これは一般のサイト運営者が使う形のものではない。
では 8.1 以前のサイトは見捨てられたのかというと、そうでもない。Codeable が集めた各社の対応を見ると、Plesk は 8.2 から 8.5 の修正版を出したうえで 8.0 と 8.1 を準備中、cPanel は 7.4 まで含めた修正パッケージを出している。Pantheon は長期サポートの事業者を通じて古い版にも修正を当て、OVHcloud は 7.4 から 8.5 までを自社のクラスタで修正済みとしている。つまり、どこまで面倒を見てもらえるかは、使っている事業者と管理ツール次第という状態だ。
国内の中小企業のサイトには、数年前に作ったまま PHP 7.4 や 8.0 で動いているものが少なくない。動いているから触らないという判断は理解できるし、古いテーマやプラグインが新しいPHPで動かなくなる心配も現実にある。ただ、今回のように実行環境そのものに穴が見つかると、版を上げる以外の選択肢が事業者頼みになってしまう。先送りしてきたPHPの版上げを、検証用のコピーで試してから本番に反映する手順ごと、予定に入れる時期だと思う。
いったん止めるという判断
今回、目を引いたのが、修正版が出るまでサイトを止めた組織が相次いだことだ。Patchstack の時系列によると、オランダでは行政のログイン基盤や下院のサイト、国のサイバーセキュリティセンター自身のサイトまでが一時的に停止した。WordPressのSEOプラグインを作っている The SEO Framework も自社サーバーを止めたという。国内でも大手のレンタルサーバーやウェブサービスが緊急メンテナンスに入ったことが、同じ記事で触れられている。
注意したいのは、WordPressのメンテナンスモードでは意味がないという点だ。Sansec が指摘するとおり、PHPはアプリケーションがメンテナンス中かどうかを確かめる前にリクエストを解析してしまう。止めるなら PHP-FPM を停止して、ウェブサーバーに静的なページを返させる形になる。完全に止められない場合の次善策として、Sansec は multipart/form-data のリクエストをウェブサーバー側で拒否する方法と、GET と HEAD 以外のメソッドを受け付けない方法を挙げているが、いずれもファイルのアップロードやフォームの送信が止まる。あくまで修正版を当てるまでの時間稼ぎだ。
Cloudflare を前段に置いているサイトでは、無料プランも含めて既定で防御の規則が有効になっている。公開の9時間ほど前から配備を始め、今回のために、リクエストとレスポンスの両方を見て判定する新しい仕組みまで用意したという。ただし Cloudflare 自身が、これは多層防御の一枚であってPHPの更新の代わりにはならないと繰り返している。サーバーが Cloudflare 以外からの通信も受け付けていれば、迂回されてしまうからだ。
制作会社として確かめておきたいこと
預かっているサイトが多いほど、見落としが怖い。Patchstack と Qualys の助言を合わせると、まずやるべきは棚卸しだ。本番だけでなく、検証用の環境、コンテナ、PHPを同梱しているアプライアンスや他のソフトまで含めて、PHPが動いている場所を全部数える。更新したあとは、コマンドラインの php -v ではなく、実際にウェブのリクエストを処理しているPHPが新しい版かを確かめる。1台のサーバーに複数の版のPHPが入っていることは珍しくなく、主に使っている版だけ直して他が残る、ということが起きやすい。
更新がすぐにできないサーバーには、PHPが示した暫定の設定がある。session.upload_progress を無効にする、memory_limit の上限を外して post_max_size を小さくする、といった内容だが、PHP自身がこれらは特定の経路を塞ぐだけで安全にはならないと念を押している。memory_limit を外すと1本のリクエストがサーバーのメモリを食い尽くせるようになるため、修正版を当てたら元に戻す作業もセットで考えたい。
狙われた形跡を探す手がかりも、Patchstack が Wiz Research の見解として挙げている。普段と違う multipart のリクエストの直後にメモリ上限のエラーや 500 が続く、応答に妙に大きい PHPSESSID のクッキーが含まれる、PHPの作業プロセスが説明のつかない再起動をしている、といった兆候だ。これらは証拠にはならないが、見つかったら更新だけで終わらせず、そのサーバーが持っていた資格情報の入れ替えまで考えたほうがいい。メモリの中身が読み出される経路があった以上、何が漏れたかは後からでは分からない。
PHPの修正はふだんは地味な作業で、サイトの見た目には何も起きない。だからこそ、どのサーバーで誰がいつ当てるのかが決まっていないまま今回のような日を迎えると慌てることになる。預かっているサイトの一覧に、PHPの版と更新の責任者の欄を足しておく。それだけでも、次に同じことが起きたときの初動はだいぶ違ってくるはずだ。
