「PHPを指定のバージョン以上に更新してください」。サーバー会社から届く通知は短くても、長年更新していないサイトにとって、その対応は簡単とは限りません。
PHPを上げるとサイトが動かなくなるかもしれない。しかし、上げなければ脆弱性を残してしまう。これまで先送りしてきた互換性の確認や改修が、緊急対応と同時に必要になる問題です。
今回のPHPの脆弱性は、何が問題なのか
PHP開発元は2026年10月21日、認証されていない第三者による遠隔コード実行につながり得る、2件の重大な脆弱性を公表しました。
- CVE-2026-109618：メモリ不足時の処理に起因し、初期化が完了していない内部データを後続処理が扱ってしまう問題。
- CVE-2026-109619：解放されたメモリに関係する内部状態が残り、同じ処理プロセスの後続リクエストで使われ得る問題。
問題はWordPressの管理画面だけにあるわけではありません。PHP公式は、PHP-FPM、Apacheのmod_phpなど、Webリクエストを処理するPHP環境を対象として挙げています。特にmod_phpでは、アプリケーションのコードが動く前に攻撃が成立する実証があると説明しています。「管理画面にログインさせなければ大丈夫」とは判断できません。
修正版は次のとおりです。数字は系列ごとに確認してください。出典：PHP公式アドバイザリ。
| PHPの系列 | 今回の修正版 |
|---|---|
| 8.2系 | 8.2.35 |
| 8.3系 | 8.3.36 |
| 8.4系 | 8.4.27 |
| 8.5系 | 8.5.12 |
この表にない古いPHPが安全という意味ではありません。PHP 8.1以前はPHPプロジェクトの通常サポートが終了しています。一部の提供元によるバックポート修正や、旧版向けの限定的な緩和策は、通常の修正版への更新と区別が必要です。サーバー会社やOSの提供元が、利用中のパッケージについて何を修正したか確認してください。表示上のバージョン番号だけで適用状況を断定することも避けます。出典：JPCERT/CCの注意喚起。
プラグインという「部品」ではなく、PHPという「土台」の問題
これまでも、WordPressのプラグインなど、特定の部品の脆弱性は報告されてきました。その場合は通常、問題の部品と影響を受けるバージョンを使っているかが、最初の確認点になります。
今回は、WordPressや多くのWebシステムを動かすPHPそのもの、いわば共通の土台の問題です。「そのプラグインは入れていないから関係ない」とは切り分けられません。WordPress製のサイトだけでなく、PHPを使う独自開発のホームページやサービスも広く確認対象になります。
ただし、すべてのWordPressサイトが無条件に攻撃できる状態になった、あるいは既に被害を受けたという意味ではありません。実際の影響や危険度は、PHPのバージョン、提供元の修正状況、実行方式や構成によって異なります。確認すべき範囲が広いことと、全サイトが同じ危険度であることは区別が必要です。参照：IPAの対策情報。
「同じ系列の修正」と「古いPHPからの移行」は違う
たとえば8.3系を修正版の8.3.36へ更新する作業と、7系のサイトを8系へ移行する作業は、同じ「PHP更新」でも確認する範囲が違います。セキュリティ修正のたびに必ずサイトが壊れる、ということではありません。
一方、古い系列からの移行では、言語仕様の変更や削除された機能への対応が必要です。PHP 8.0では、create_function()やeach()の削除、型に関するエラーの扱いなどに互換性の変更がありました。昔の書き方を使ったテーマ、プラグイン、独自プログラムが残っていると、そこで処理が止まる可能性があります。出典：PHP公式・PHP 8.0の下位互換性のない変更点。
トップページは表示できても、お問い合わせ送信だけ失敗する。管理画面で保存できない。予約や決済の途中で止まる。こうした「特定の操作で初めて分かる不具合」も想定しなければなりません。
保守をしていないサイトで、対応が難しくなる理由
最初の壁は、改修そのものより「何が動いているのか分からない」ことです。
サーバーの契約者は誰か。管理画面に入れるか。PHPの変更権限はあるか。制作会社が追加したコードはどこか。有料プラグインの更新権は残っているか。バックアップはいつのものか。これらを緊急時に一つずつ調べると、安全を確保するための時間が調査に消えていきます。
さらに、PHPを上げるためにプラグインの更新が必要で、その新版を使うにはWordPress本体も更新しなければならない、といった依存関係があります。提供が終了したプラグインには、そもそも対応版がないこともあります。
その場合はコードを修正するのか、別の製品へ置き換えるのか、不要な機能を廃止するのか、判断が必要です。置き換えにデータ移行が伴えば、作業は「サーバー設定の変更」では済みません。止まっていなかったことと、安全に更新できる状態だったことは別なのです。
「壊れるから更新しない」ではなく、安全確保と改修を分ける
互換性が不明なまま本番環境を変更するのは危険です。しかし、検証が終わるまで脆弱なサイトを公開し続けてよい、ということでもありません。
すぐに修正できない場合は、環境に応じたアクセス制限や外部公開の一時停止などを先に検討します。今回のようにアプリケーションの実行前に問題が起こり得るケースでは、WordPressのメンテナンス画面を表示するだけで対策になるとは限りません。PHPへ到達する手前で制限できているか、サーバーの管理者と確認が必要です。
IPAも、有効な暫定対策が難しい場合には、外部からのアクセス遮断や一時停止の必要性を判断するよう案内しています。停止を避けることだけではなく、利用者の情報や業務を守ることまで含めた判断です。出典：IPAの対策情報。
今回、高市早苗氏のXでも事前準備と迅速な対応が呼びかけられ、別の投稿では自身の公式サイトが対策中に一時閲覧できなくなり、その後復旧した旨が報告されました。公的な呼びかけや停止事例は深刻さを理解する材料ですが、個々のサイトの対応方法は技術情報と利用環境に基づいて決めます。参照：10月21日の投稿、10月22日の投稿。
更新を進めるときに、押さえたい順番
- 構成と担当を確認する。PHP、WordPress、テーマ、プラグイン、独自改修、契約・アクセス権限を整理し、サーバー会社側の対応状況も確認します。
- 戻せる状態を用意する。ファイルだけでなくデータベースや設定も保全し、バックアップから復元できることを確かめます。「保存済み」と「復旧可能」は同じではありません。WordPress公式の更新手順も、バックアップの使用可能性を確認する重要性を説明しています。
- 検証環境で差を見つける。本番のPHP拡張、設定、データベースなどを可能な限り再現し、対応版への更新、独自コードの修正、非対応機能の置き換えを進めます。
- 重要な操作を確認して本番へ反映する。表示だけでなく、フォーム送信と受信、ログイン、予約・購入、管理画面での保存、定期処理を確認します。反映後も実際のPHPと修正適用状況、エラーログを確認します。
検証を無期限に続けるのではなく、業務上重要な機能を優先し、公開制限と並行して進めます。切り戻しも、障害時の手段であって、脆弱なPHPへ戻したまま公開を続けるための結論ではありません。戻す必要がある場合は、公開制限を維持し、修正して再適用する道筋を決めます。
また、更新は既に起きた侵害を取り消すものではありません。不審なファイルや通信なども確認し、侵害が疑われる場合はログを保全して調査・隔離へ進みます。痕跡が見つからないだけで無被害とは断定できません。参照：JPCERT/CC「侵害調査」。
日頃の保守は、「更新できない」を減らすためにある
継続的な保守をしていても、不具合や緊急対応をゼロにはできません。それでも構成、更新履歴、検証項目、復旧手順が分かっていれば、緊急時に「調べるところから始める」範囲を減らせます。
保守の価値は、普段サイトが表示されていることだけではありません。更新しなければならない日に、更新へ進める状態を保っておくことにもあります。
なお、緊急改修、侵害調査、データ復旧、大規模な移行が通常の保守契約にすべて含まれるとは限りません。対応時間、費用、連絡先、どこまでを誰が担うかは、平時に確認しておくことが大切です。