自分のサイトは、PHPの脆弱性で今日バージョンを変える必要があるか

10月21日、PHPの開発元が、ログインしていない外部からのリクエストでサーバー上のプログラムを実行されるおそれのある脆弱性を直し、修正版を公開した。この組み合わせはPHP2shellと呼ばれている。エックスサーバー、さくら、ロリポップ、ConoHaは、この対応で管理画面や一部のサイト表示を止めた。

WordPressを自分のサーバーで動かしている人の次の疑問は、サイトヘルスに出ているPHPの番号を、今日上げるのかどうかだ。

先に結論

共用レンタルサーバーで、契約中のサービスとPHPバージョンが運営会社の修正済み対象に含まれ、利用者による変更は不要と案内されているなら、今回の脆弱性対策のためだけにPHPのバージョンを上げる必要はない。修正済みと書かれていないプランやPHPの版には、この結論は当てはまらない。系列を上げると、テーマやプラグインが動かなくなることがある。mixhostは、バージョンアップで起きた不具合への対応はサポート対象外だと書いている。

PHP 8.1以前を使っている場合は、今回の修正が適用されていても、サポート中のPHPへの移行を別途計画する。 開発元の通常の更新はもう来ない。ロリポップは、8.1以下について8.2以降への切り替えを頼んでいる。各社が今回入れた古い版への修正は、次の脆弱性まで面倒を見ると約束するものではない。

画面の番号が古いままかどうかは、会社によって意味が違う。 mixhost、ConoHa WING、お名前.comレンタルサーバーは、番号を変えずに修正だけを入れたと書いている。サイトヘルスが8.4.26や8.5.11のままでも、その会社の案内では修正済みの番号だ。エックスサーバーのPHP 8.2〜8.5は「同じ系列の修正版に更新」と書いてあり、番号を残すとは書いていない。ロリポップの8.2〜8.5は、開発元の修正版（8.4.27など）を適用したと書いている。

VPSや、自分でPHPを入れたサーバーは、共用サーバーの「対応済み」に入らない。 エックスサーバーのVPS、さくらのVPSの中で動かしているPHP、ConoHa VPSは、利用者が更新する。

何が起きたか

PHPは、WordPressや多くのWebサイトが動くためのプログラミング言語だ。今回ふさがるのは、そのPHP側だ。WordPressのプラグインを更新する作業とは別になる。

開発元が10月21日に出した修正版は、次の4つだ。

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

脆弱性は2件で、番号はCVE-2026-109618とCVE-2026-109619。開発元は、Webのリクエストを受けているPHPが対象で、ログインなしに任意のコードを実行されるおそれがあると書いている。リスクが最も高いのは、Apacheのmod_phpだ。手元のPCでコマンドとしてだけ動いているPHPは、この対象に入っていない。

PHP 8.1以前は、開発元の通常の更新対象外だ。一部の配布元は、独自に修正を古い版へ戻している。開発元は、ソースから自分で作る人向けに、7.4、8.0、8.1の最小限の修正も用意したと書いている。

設定を変える緩和策はある。開発元は、更新だけが完全な対策だと書いている。

画面の番号だけで判断しない

WordPressのサイトヘルスや、phpinfoに出る番号が8.4.26や8.5.11だと、ニュースに出ている8.4.27や8.5.12より古く見える。共用サーバーでは、その読み方が会社ごとに違う。

10月24日に公式ページを確認した範囲は、次のとおりだ。追記の時刻は、各社のページに書かれている時点だ。

サービス	自分でバージョンを変えるか	画面に出る番号
エックスサーバー、XServerビジネス、XServer for WordPress	PHP 5.6〜8.5は、急いで変える必要はない（10月23日13時15分の追記）。5.1〜5.5は、10月23日17時時点で過半数のサーバーまで	5.6〜8.1は番号を変えずに対策。8.2〜8.5は同じ系列の修正版に更新
さくらのレンタルサーバ	提供しているPHPに必要な修正を適用した（10月23日の追記）。番号を上げる作業とは書いていない。サポートが終わった版は、今後のためにサポート対象の版を勧めている	番号が変わるかは書いていない
ロリポップ	修正を入れて10月22日13時頃にサイト表示を再開。8.1以下は応急なので、8.2以降への切り替えを頼んでいる。今日の確認は、表示、問い合わせフォーム、ファイルのアップロード	8.2〜8.5は開発元の修正版（8.2.35、8.3.36、8.4.27、8.5.12）を適用
mixhostのレンタルサーバー（アダルト、海外を含む）	必要な作業はない。8.2未満は、今すぐの変更は不要で、8.2以上を推奨	番号は変わらない。例として8.4.26のまま
ConoHa WING	変える必要はない（10月22日20時45分時点で適用完了）	番号は変わらない。例として8.5.11。適用後に出る番号の一覧あり
お名前.comレンタルサーバー（ベーシック、RSプラン、AIホームページパック）	変える必要はない（10月22日20時45分時点で適用完了）	番号は変わらない。例として8.5.11。一覧はConoHa WINGと同じ番号

ロリポップがアップロードの確認を頼んでいるのは、全バージョンで session.upload_progress を切ったからだ。サイトが開くことと、フォームやファイル送信が前と同じかどうかは、別の確認になる。

エックスサーバーは、利用状況によっては追加の対策を改めて案内する、とも書いている。10月23日の「変えない」は、その時点の案内だ。

同じ会社でも、VPSは別

契約名にVPSとあるサーバーは、上の表で変更不要と書いた行には入らない。同じ会社の共用サーバーと並べて判断すると、読み違える。

サービス	公式の案内
エックスサーバーのVPS（XServer VPS、ビジネスプラン、VPSクラウド）	PHPの修正は入れない。利用者がバージョンを確認して更新する
さくらのVPS	サービス本体はPHPを使っていないので、その部分に影響はない。VPSの中でPHPを動かしているなら、利用者が最新版へ更新する
ConoHa VPS	WING向けのパッチの対象外。8.5.12、8.4.27、8.3.36、8.2.35以降へ更新する。5.4〜8.1は修正版がないので、サポート中の版へ上げる

公式サイトから入れたPHPなら、8.4系は8.4.27以降、というように系列ごとの修正版へ上げる。OSのパッケージで入れている場合は、番号が8.4.27にならないまま修正が入ることがある。開発元は、Linuxの配布元が事前に修正を受け取っているので、配布元の更新を確認するよう書いている。

ConoHa VPSのお知らせは、8.2系なら8.2.35未満を対象に数えている。番号の見方は、PHPをどこから入れたかで変わる。

8.1以前と、8.2の期限

PHP公式のサポート表では、8.1以前はサポートが終わっている。8.2のセキュリティサポートは2026年12月31日まで、8.3は2027年12月31日までだ。

ロリポップとmixhostが「8.2以上」と書いているのは、2026年10月24日時点でセキュリティ更新が残っている下限だ。8.2に上げても、2026年末でその更新は終わる。移すなら、表示やフォームが壊れないかを確かめたうえで、8.3以降の方が次の更新までの期間は長い。今回の穴がすでにふさがっているサーバーで、互換性を見ずに今日中へ上げる作業ではない。

攻撃はどこまで確認されているか

ロリポップは、脆弱性を狙ったとみられるアクセスは確認したが、それによる不正アクセスや情報漏えいは、お知らせの時点では確認していないと書いている。さくらは、10月23日17時時点の自社調査では、悪用した不正アクセスや情報漏えいは報告されていないと書いている。

「まだ悪用されていない」と読むには足りない。ロリポップは、設定による緩和だけでは防げない可能性があったため、修正が終わるまで一部のサイト表示を止めた。停止はサーバー単位だったので、PHP 8.2以降のサイトや、PHPを使っていないサイトも表示できない時間があった。

表にないサーバーのとき

契約している会社のお知らせを見る。ここに名前がない会社を、上の表のどれかに当てはめて「番号が古くても大丈夫」とは読まない。

分け方は、PHPを誰が入れているかだ。サーバーパネルでバージョンを選ぶだけの契約は、会社側が直していることが多い。SSHでOSから自分で入れたPHPは、自分が直す。PHPのバージョンを自分で選べないブログサービスは、利用者が上げる場所がない。そのサービスの障害情報を見る。

各社の独自修正が、開発元の8.4.27と中身まで同じかどうかは、お知らせだけでは分からない。mixhostは、適用した修正パッケージの詳細は個別に案内しないと書いている。

10月23日、PHPは別の案内も出している。セッションのアップロード進捗（session.upload_progress）を、次の通常の修正リリースまで無効にする、という内容だ。起きる条件は、アプリが実行中にセッションの保存形式を切り替える組み合わせに限る、と書いている。普段のWordPressがこれに当たるかは、この案内だけでは判断できない。ロリポップは、今回の対策としてすでに全バージョンでこの機能を切っている。