PHP本体のRCE脆弱性（CVE-2026-109618・109619）にWordPress保守担当が今日やること

2026年10月21日（UTC 14:00）、PHPのセキュリティチームが2件のリモートコード実行（RCE）の脆弱性を修正した緊急リリースを公開しました。どちらもCVSS v4.0で9.2とされ、WordPressのプラグインやテーマの問題ではなく、WordPressを動かしているPHP本体の問題です。サイトのプラグインを全部最新にしていても、サーバー側のPHPが古いままなら影響を受けます。

この記事は、複数のサイトを預かっている制作会社や保守担当の方が、今日と数日のうちに何をするかを決められるように書いています。

何が起きたのか

CVE-2026-109618は、メモリ不足でPHPの処理が途中で止まったとき、まだ初期化が終わっていない内部データを、後始末の処理が正しいものとして扱ってしまう問題です。CVE-2026-109619は、リクエストごとに使う内部の状態が、メモリを解放した後も残り、同じワーカーが次に受けたリクエストで、初期化される前に使われてしまう問題です。

どちらもPHPの内部の問題なので、WordPressのコードやプラグインに問題があるわけではありません。PHPの公式アドバイザリによると、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、ウェブのリクエストを処理するPHPはすべて対象です。とくにmod_phpでは、ログインしていない相手の1回のリクエストで、WordPressのコードが動き出す前に攻撃できるとされています。

10月20日に詳細が先に流出し、動くエクスプロイトがあるとも報じられました。修正版の公開後、セキュリティ会社のwatchTowrが、両方の脆弱性に対する攻撃の試行を観測したと発表しました（10月21日14:19 UTC）。Cloudflareも、顧客のサイトへの攻撃通信があり、攻撃者がWAFのルールをすり抜けるようにペイロードを変えていると報告しています。特定のサーバーが実際に侵害されたという報告は、10月22日朝の時点では見つかっていません。修正版が出て、どこが直ったかを読み解ける状態になったので、ここから攻撃が増える可能性があります。

修正版と、直らないバージョン

修正版は次の4つです。

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1以前は公式の更新が出ません。ソースからビルドする場合向けに、PHP 7.4、8.0、8.1用の最小限のパッチが配られていますが、レンタルサーバーを使っている場合は、自分でビルドできないので、ホスティング会社が対応するかどうかで決まります。PHP 8.2は2026年12月31日にサポートが終わるため、今回の更新を機に8.3以降への移行も予定に入れておくと二度手間になりません。

Linuxのディストリビューション（Ubuntu、Debian、AlmaLinuxなど）が配るパッケージでは、バージョン番号が上のものと一致しなくても、修正がバックポートされていることがあります。パッケージの更新履歴にCVE番号が載っているかを見てください。なお、公式のアドバイザリでは、rpms.remirepo.netはこのリリースに合わせた更新が出ないため、ディストリビューションのパッケージかソースビルドに切り替えるよう書かれています。

今日やること

自分でサーバーを管理しているか、ホスティング会社が更新してくれるのかで、やることが変わります。

まず、預かっているサイトのPHPバージョンを洗い出します。WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」→「サーバー」を開くと、そのサイトが実際に使っているPHPのバージョンが確認できます。確認の手順や、サーバーパネルとの表示の食い違いが起きたときの見方は、WordPressのPHPバージョンを確認・更新する方法に書いています。サイトが10件を超えるなら、サイト名・ドメイン・ホスティング・PHPバージョン・確認日を表にしておくと、後で「どこまで終わったか」を追えます。

洗い出したら、次のように分けて動きます。

• VPSや専用サーバーなど、自分で管理している環境: OSのパッケージを更新し、PHPのバージョンを確認して、PHP-FPMやApacheを再起動します。パッケージが修正済みかどうかは、更新履歴か、ディストリビューションのセキュリティ情報で確認します。
• レンタルサーバーやマネージドホスティング: サーバー会社のお知らせで、今回の脆弱性への対応状況を確認します。対応済みなのか、いつ反映するのか、自分でPHPのバージョンを切り替える必要があるのかが書かれていなければ、サポートに問い合わせます。サーバーパネルでPHPのバージョンを選べる環境なら、8.3系か8.4系の最新版に切り替えられるか確認します。
• PHP 8.1以前で動いているサイト: 公式の更新がないので、ホスティング会社が個別にバックポートしてくれるかを確認します。何も出ないようなら、PHPを8.3以降へ上げる計画を立てます。プラグインやテーマが新しいPHPで動くかの確認は、プラグイン更新前チェックリストの考え方がそのまま使えます。

PHPを上げるときは、まずステージング環境や、アクセスの少ない時間帯で、トップページ・ログイン・フォーム・決済など壊れると困るページを見てから本番に反映するのが安全です。今回は緊急度が高いので、「全サイトを今日中に」と無理に詰めず、アクセスが多いサイトと、ログインや決済があるサイトを先にします。

レンタルサーバー各社の対応状況（2026年10月22日朝時点）

2026年10月22日の朝に各社の告知を調べた範囲では、PHPの修正版を適用済みと明言しているレンタルサーバー会社は見つかりませんでした。多くの会社が緊急メンテナンスを実施または予告していて、メンテナンスの時期が修正版の公開前後に重なっているので、今回の件に関係している可能性はありますが、告知にPHPの件と書かれていない会社の分は推測になります。公式の告知本文で内容を確認できたものを、次の表にまとめました。

会社	告知で確認できる内容	PHPの件と明記	告知
さくらのレンタルサーバ／マネージドサーバ	10/21 13:00〜10/22 8:00頃、一部のホストで緊急メンテナンス	なし	お知らせ
ConoHa WING	10/21 19:00〜10/22 10:00、システム保守	なし	お知らせ
KAGOYA	脆弱性の影響を調査中。適用日と古いPHPの扱いは未記載	あり（CVE番号も記載）	お知らせ
バリューサーバー／コアサーバー	10/22 0:00以降、全サーバーを順次更新。約10分の再起動で接続が途切れる	なし	お知らせ

エックスサーバー、ロリポップ、お名前.com、カラフルボックス、mixhostについては、緊急メンテナンスの実施がまとめ記事などで伝えられていますが、公式の告知本文でPHPの件かどうかまでは確認できませんでした。ヘテムル、XREA、シン・レンタルサーバーは、この時点で該当する告知が見つかっていません。

どの会社も、PHP 8.1以前の扱いを書いていませんでした。担当サイトが古いPHPで動いている場合は、サーバー会社のサポートに、今回の脆弱性への対応予定と、古いPHPにも修正が入るかを問い合わせてください。この表は朝時点の状況なので、日中に更新される可能性があります。各社の告知で最新の状況を確認してください。

すぐに更新できない間にできること

更新できない間の部分対策は、PHPの公式アドバイザリにも書かれていますが、あくまで被害を減らす程度で、安全にはなりません。使うとしても、更新までのつなぎです。watchTowrは、ini設定の変更は有効な対策ではないとしていて、更新できないサーバーは、インターネットからの到達を制限するのが暫定措置だとしています。

; php.ini（リクエストの解析より前に効く設定）
session.upload_progress.enabled = 0
post_max_size = 8M          ; ファイルのアップロードが必要なら32M程度
; upload_max_filesize は post_max_size より小さくする
memory_limit = -1          ; FPMの php_admin_value など、上書きできない場所に書く

設定を変えた後は、PHPのワーカーを再起動します。ini_set() や .user.ini では効かないとされているので、レンタルサーバーで php.ini を自由に触れない場合は、この対策は取れません。PHP 8.5を使っているなら、fatal_error_backtraces = 0 も設定します。RLIMIT_AS や RLIMIT_DATA を使うと、今回の脆弱性が起きるメモリ確保の失敗を自分で作ってしまう可能性があるため、メモリの上限はコンテナやcgroupで決めるよう案内されています。

Cloudflareは、既知の攻撃方法に対するWAFルールを無料プランを含めて配信していると発表しています。Cloudflareを使っているサイトでは、WAFのルールが有効になっているかを確認しておくと、更新までの間の保険になります。ただし、WAFだけで直るわけではないので、PHPの更新は必要です。

更新した後に確認すること

PHPの更新後に、サイトヘルスでバージョンが期待どおりに変わったかを確認します。サーバーパネルでPHPを切り替えたのに、サイトヘルスの表示が変わらないときは、反映が遅れているか、別のドメインやサブドメインの設定を見ていることがあります。

そのうえで、PHPのエラーログに新しいエラーが出ていないか、トップページ・ログイン・フォームが動くかを確認します。PHP 8.1以前から上げた場合は、古いプラグインが新しいバージョンで動かなくなり、画面が真っ白になる「重大なエラー」が出ることがあります。その場合の見方はWordPressの致命的エラーの原因調査にまとめています。

攻撃を受けた疑いがあるときは、サーバーを隔離してログを残したうえで、Webの公開ディレクトリに身に覚えのない新しいファイル、不審なcron、知らない管理者アカウントがないかを調べます。PHPのワーカー（php-fpmやapache2）が、シェルやダウンロード用のコマンドを起動している形跡も、見るべき手がかりです。

参考にした公式情報

• PHP: News Archive 2026
• GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
• GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• watchTowr: PHP RCE FAQ
• PHP: Supported Versions

関連記事

• WordPressのPHPバージョンを確認・更新する方法
• PHP EOL対応を顧客に説明するときのポイント