最終更新:2026年10月28日
2026年10月21日、PHP公式から2件の重大な脆弱性(通称「PHP2Shell」)が公表されました。CVE-2026-109618とCVE-2026-109619で、いずれも条件がそろうと、認証していない第三者によるリモートコード実行につながる可能性があります。
Amazon Threat Intelligenceは、公開前の2026年10月17日からPHP2Shellの悪用の試みを観測しています。公開当日には複数の試行が確認され、その後は広範な悪用の試みが見られると報告しています。また、CISAは2026年10月26日に両CVEを既知の悪用された脆弱性(KEV)カタログへ追加しました。インターネットに公開しているサイトでは、対応の優先度を上げてください。
PHP2ShellはWordPress固有の問題ではありません。WordPressを動かしている土台であるPHP本体の問題です。そのため、WordPress本体やプラグインを最新版にしていても、PHP側の確認が必要です。
この記事では、WordPressサイトの運営者が最初に確認したいポイントを5つに整理します。
1.現在のPHPバージョンを確認する
WordPressでは、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPバージョンを確認できます。表示名や配置はWordPressのバージョンにより異なる場合があります。
PHP公式が案内している修正版は、次のバージョンです。
・PHP 8.2.35
・PHP 8.3.36
・PHP 8.4.27
・PHP 8.5.12
これより前のバージョンを利用している場合は、更新状況を確認してください。PHP 8.1以前はPHP公式の通常サポート対象外ですが、OSやレンタルサーバー事業者が修正をバックポートしている場合があります。
そのため、管理画面に表示されたバージョン番号だけで「未対応」と断定するのも、「問題ない」と判断するのも早計です。
PHP 8.2は2026年12月31日にサポート終了予定です。今後の運用を考える場合は、テーマやプラグインの互換性を確認したうえでPHP 8.3以降への移行も検討してください。
2.レンタルサーバーの公式告知を確認する
共有レンタルサーバーでは、PHP本体の修正を利用者ではなくサーバー会社が実施することがあります。まず、利用中の事業者が今回の脆弱性について告知しているか確認しましょう。
確認したい内容は、次の3点です。
・利用中のPHPが影響を受けるか
・修正版またはバックポートが適用済みか
・利用者側でPHPバージョンの変更が必要か
VPSや専用サーバーの場合は、自分または管理会社がOSの更新パッケージを適用する必要があります。
3.バックアップを取ってから更新する
脆弱性対応は急ぐ必要がありますが、バックアップなしでPHPを切り替えると、古いテーマやプラグインが動かなくなる可能性があります。
少なくとも、次のものを保存してから作業します。
・Webサイトのファイル
・データベース
・現在のPHPバージョンと設定
・有効化しているテーマ、プラグインの一覧
可能であれば、本番環境の前にテスト環境で動作を確認します。
4.WordPressとの互換性を確認する
PHPを更新した後は、トップページが表示されるかだけで判断しないことが大切です。
・管理画面にログインできるか
・お問い合わせフォームを送信できるか
・画像アップロードや記事編集ができるか
・決済や会員機能が動作するか
・PHPエラーログに新しいエラーが出ていないか
なお、PHPを更新しても、それ以前に設置された不正なファイルは残ります。攻撃の試みは公開前の10月17日から観測されているため、この日以降のアクセスログに不審な記録がないか、見覚えのないPHPファイルが追加されていないかも確認してください。
特に、長期間更新されていないテーマや独自プラグインがある場合は注意が必要です。
5.「一時対策だけで安全」と判断しない
PHP公式は、今回の問題について完全な代替策はなく、更新が安全な解決策だと案内しています。設定変更やWAFなどで一部の攻撃経路を減らせる場合はありますが、それだけで脆弱性が解消されるわけではありません。
サーバーの設定変更は、サイト停止やアップロード機能への影響を伴うことがあります。内容が分からないまま設定値を変更するより、まず利用環境とサーバー会社の対応状況を確認してください。
追記:CVE-2026-115560について
2026年10月23日、PHP公式はセッションのアップロード進捗機能に関する別のRCE経路(CVE-2026-115560)を案内しました。これは、設定でsession.serialize_handlerをphp_binaryまたはphp_serializeにし、アプリケーションがsession_start()の前にini_set()でphpへ切り替え、さらにsession.upload_progress.enabledが有効という珍しい組み合わせで発生します。
PHP公式は、この条件に当てはまる可能性を確認できない場合、次回の通常バグ修正リリースまでsession.upload_progress.enabled=0にすることを提案しています。一方、実行時にserialize handlerを変更しないアプリケーションは、この機能を有効のまま利用できます。設定変更はアップロード進捗機能に影響するため、不明な場合はサーバー会社や管理担当者へ確認してください。
まとめ
「PHPの数字は分かるけれど対象か判断できない」「更新するとWordPressが壊れないか不安」という場合は、PHPのバージョンだけでなく、提供環境やサーバー会社の修正状況まで含めて確認する必要があります。
RE:Miraiでは、現在の環境が今回の脆弱性の影響を受ける可能性と、必要な対応方針を調査しています。基本サービスは調査と報告までで、PHP更新やサイト修正が必要な場合は、調査後に別途お見積もりします。
ご自身の環境が対象か判断できない場合は、PHP・WordPress環境の脆弱性確認サービスをご利用ください。現在のPHPバージョンやサーバー会社の対応状況を確認し、必要な対応方針をご報告します。
参考情報:PHP公式セキュリティアドバイザリ/PHP公式「Supported Versions」/AWS Security Blog/NVD(CVE-2026-109618・CVE-2026-109619・CVE-2026-115560)
※本記事は2026年10月28日時点の公開情報に基づく一般的な解説です。個別環境の安全性を保証するものではありません。