PHP 本体の脆弱性 2 件（CVE-2026-109618 と CVE-2026-109619）の修正版を、PHP の開発チームが 10/21 に公開しました。ログインしていない第三者が細工したリクエストを送るだけで、サーバー上で任意のコードを実行できるものです。WordPress のプラグインやテーマではなく、WordPress を動かしている PHP そのものの問題なので、WordPress の更新画面には何も出ません。
修正版が出た日に、脆弱性の中身も公開されました。10/21 の時点では、修正版に切り替える前の WordPress サイトが、PHP のバージョンに関係なく全部攻撃対象です。
https://www.php.net/archive/2026.php#2026-10-21-5
PHP の開発チームの公開情報をもとに、やることだけ整理しました。
取るべき対応
- サイトヘルスで PHP のバージョンを見る
- WordPress の管理画面の「ツール → サイトヘルス → 情報 → サーバー」に出ます。8.5 なら 8.5.12、8.4 なら 8.4.27、8.3 なら 8.3.36、8.2 なら 8.2.35 以上で対応済みです
- サーバー会社が修正版を自動で入れる場合もあります。入ったかどうかは、この画面の数字だけで判断する
- それより前なら、サーバー会社の管理画面で PHP を修正版に切り替える
- 切り替える場所はサーバー会社ごとに違い、修正版がまだ選べない会社もあります。選べないときは、その会社の告知を待つ
- 同じ系統の中の切り替え（8.3 の中で上げるなど）では、サイトの動作は変わりません
- 8.1 以前のサイトは、8.2 以降に切り替える
- 8.1 以前には開発チームの修正版が出ません。8.2 も 12/31 でサポートが終わるので、切り替える先は 8.3 以降が無難です
- 系統が変わるので、切り替えた直後にトップページと問い合わせフォームなど主要な動作を見る。崩れたら元の系統に戻せるので、確認してから進めるのが無難です
- 開発チームは 7.4 / 8.0 / 8.1 向けにも最小限の修正をソースコードで出していますが、当てるのはサーバー会社です。古い系統にも当てたと告知している会社では、その告知が根拠になります。バージョンの数字では分かりません
すぐ切り替えられない場合の軽減策として、開発チームは session.upload_progress.enabled=0 と memory_limit / post_max_size の制限を挙げていますが、どれも一部の攻撃経路を塞ぐだけで、安全にはならないと明記しています。レンタルサーバーでは、どれもサーバー会社側の設定です（.user.ini では効きません）。
対象者
対象は、Web のリクエストを受けているすべての PHP で、修正版より前はバージョンを問わず対象です。8.1 以前も含み、PHP-FPM か Apache の mod_php かといった動かし方も問いません。ログインも、特定のプラグインやテーマも要らず、WordPress 本体のバージョンは関係ありません。
| PHP の系統 | 修正版（10/21 公開） |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35（8.2 は 12/31 でサポート終了） |
| 8.1 以前 | 修正版なし。8.2 以降に切り替える |
起こったこと
ログインしていない第三者が、細工した HTTP リクエストを送るだけで、Web サーバーの実行ユーザーの権限で任意のコードを実行できます（CVSS v4.0 9.2、2 件とも）。開発チームは mod_php の既定の設定に対して、WordPress などアプリケーションのコードが動き出す前に攻撃が成立することを実証していて、mod_php をいちばん危険としています。
原因
開発チームによると、1 件目はメモリー不足の処理が、リクエストの内部データを初期化し終える前に PHP を中断するもので、後片付けがその不完全なデータを正しいものとして扱います。2 件目は、リクエストが終わってメモリーが解放されたあとも内部の状態が残り、同じワーカーが次のリクエストでその古い状態を使うものです。詳細は GitHub の公開情報（1 件目・2 件目）にあります。
