WordPressの更新通知は見ていても、サーバーのPHPまで確認したことはありませんでした。今回「php2shell」とも呼ばれる一連の脆弱性を知って、私のサイトで使っていたPHPを調べると8.2.19。2026年10月21日に公開された修正版の8.2.35より古い版でした。そこで公開中の古いPHPをいったん止め、バックアップを取って新しい環境へ移しました。「php2shell」は研究者の投稿などで使われた呼び名で、脆弱性の正式な識別子は下のCVE番号です。GMO Flatt Securityの解説
「WordPressの問題なの？」「すぐ対応しないといけないの？」と気になった人向けに、分かっていることと、私が急いだ理由を整理します。
何が起きる可能性があるのか
PHP開発チームは、CVE-2026-109618とCVE-2026-109619という2件の重大な問題を公表しました。両件の深刻度はCVSS v4.0で9.2と告知されています。どちらも条件がそろうと、外部からサーバー上で任意のコードを実行される可能性があるものです。いわゆるRCE（遠隔コード実行）です。PHP公式のセキュリティ告知と1件目の公式アドバイザリ、2件目の公式アドバイザリに詳細があります。
難しい内部構造をひと言で言うと、PHPがリクエストの処理や後片付けをする途中で、もう使うべきでないメモリを参照してしまう問題です。攻撃者がその状態を作れた場合、ただページを見るだけの外部リクエストから、Webサーバーの実行権限でコードを動かされるおそれがあります。そこからサイトの改ざん、設定ファイルやDB接続情報の読み取りなどにつながり得ます。これは起こり得る影響であり、公開されたすべてのサイトで侵入が確認されたという意味ではありません。
特に注意したいのは、Apacheの mod_php 構成では、WordPressの処理が始まる前に、ログイン不要のHTTPリクエストだけで攻撃が成立する例が実証されたことです。つまり、WordPressのログイン画面を隠したり、管理者パスワードを強くしたりするだけでは、この経路を防げません。一方、PHP-FPMなどの構成については、PHP側が影響を調査対象に含めていますが、同じ形の完全な攻撃がすべての構成で実証されたわけではありません。構成差を無視して「すべて同じように攻撃できる」とは言えません。PHP公式告知、公式アドバイザリ
WordPress利用者が他人事にできない理由
今回の問題はWordPress本体の欠陥ではなく、その下で動くPHPの問題です。WordPressはPHPで動きます。WordPress公式の説明にも明記されています。W3Techsの2026年10月の調査では、WordPressは調査対象のWebサイト全体の約4割で使われています。したがって、このPHPの問題を確認すべき人の中には、個人ブログから企業サイトまで非常に多くのWordPress運営者が含まれます。
ただし、WordPressサイトの約4割がこの脆弱性にさらされている、という数字ではありません。 実際の危険性は、サーバーで動いているPHPの版、配布元による修正のバックポート、WebサーバーとPHPの接続方式、公開範囲によって変わります。WordPress本体のバージョンを更新しても、サーバーのPHPが同時に更新されるとは限りません。LightsailでもOS・Webサーバー・PHPの更新は利用者側の管理対象です。AWSの更新ガイド
なぜ「そのうち」で済ませにくいのか
理由は3つあります。まず、ログインなしで届く経路が実証されていること。次に、成功した場合の影響が「表示が少し崩れる」程度ではなく、サーバー上でコードを実行される可能性まであること。さらに、修正内容と対象版が公開されているので、古いPHPを使い続けるサイトは、対応状況を確認する価値が高いことです。PHP開発チームも、Webリクエストを処理するPHPの利用者に速やかな更新を求めています。PHP公式告知
修正版はPHP 8.2系なら8.2.35、8.3系なら8.3.36、8.4系なら8.4.27、8.5系なら8.5.12です。ディストリビューションやホスティング会社が古い版番号のまま修正を取り込む場合もあるため、数字だけで断定せず、提供元のセキュリティ情報も確認します。PHP 8.1以前はPHP本体の通常サポートが終了しています。PHP公式告知
PHP設定を変えて一部の攻撃経路を狭める案も公式に示されていますが、更新と同じ完全な対策ではありません。 私は旧サーバーのPHPを外部から動かせない状態にして、その間に修正版を含む新環境を用意しました。単にWordPressの「メンテナンスモード」プラグインで画面を差し替えるだけでは、PHP自体を停止したことにはなりません。PHP公式の緩和策
自分のサイトなら、まず何を確認するか
- ホスティングの管理画面やサーバーでWeb側のPHPの版と配布元の修正状況を確認する。SSHの
php -vはCLI版なので、PHP-FPMやApacheのモジュールが別ならそれも確かめる。 - 影響が残るなら、DBとファイルをサーバー外にもバックアップし、更新方法と切り戻し方法を決める。更新がすぐできない場合は、公開中の古いPHPへのアクセスを一時的に止める。
- 修正版へ更新した後、WordPress本体・プラグイン・テーマ、記事、管理画面、フォーム、メール、同居アプリを試し、再起動後も動くことを確認する。アクセスログやエラーログも保全する。
共用レンタルサーバーなら、まず事業者の告知とPHP切替画面を確認するのが早いはずです。Lightsailのような自分で管理するインスタンスでは、WordPressの更新とは別にサーバーのPHPを管理する必要があります。
私のBitnami版Lightsailでは、その場でPHPだけを安全に入れ替えるより、新しい公式WordPressイメージへ移す方が、バックアップと動作確認を段階的に進めやすいと判断しました。同じように移行を考える人向けに、旧PHPを止めてから、Bitnami版WordPressをLightsail公式版へ移した手順を別の記事に残しています。新環境の選び方だけでなく、DB・画像の復元、静的IP、HTTPS、WordPress以外のアプリ、再起動後の確認まで、私がつまずいた点を含めて書きました。
コメント