PHP2Shellの対策方法｜WordPressでのPHP確認手順と実際に調べた結果

2026年10月30日時点の情報です。

結論から言うと、WordPressでPHP2Shellが気になったら、まずサーバーのPHPバージョンを確認してください。今回の修正版かどうかを判定し、未修正なら更新する。それとは別に、過去の不審なアクセスや設定変更の痕跡を確認する。この順番です。

PHPバージョンは、WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。

私も2026年10月に運営中のWordPressで調査しました。PHPは今回の修正版でしたが、そこで終わりにせず、アクセスログ、WordPressの管理者設定、ファイルの更新履歴を確認しました。その後、別の目的もあってサーバーを移行し、PHP 8.3.36で動作するところまで確認しています。

まず、自分のサイトで何をするべきか
WordPressのPHPバージョンはどこで確認する？
PHP2Shellとは？なぜWordPressの更新だけでは足りないのか
実際に効率家ラボで確認したこと
今回の修正だけで終わらない。PHPのサポート期限も確認する
PHPを使わない構成にすれば解決する？
まとめ：修正版の確認と、過去の侵害確認は分けて考える
参考にした公式資料

まず、自分のサイトで何をするべきか

PHPのバージョンやサーバーの管理方法によって、対応は変わります。WordPressを更新しただけで完了と判断しないことが大切です。

今回の修正版PHPを使っている場合

今回の2件の脆弱性については修正済みと判断できます。今すぐ別系列へ切り替えることより、WordPress本体・テーマ・プラグインの更新状況や、不審な管理者・ログ・ファイルの有無を確認します。ただし、修正版の利用は過去に侵入されなかった証明にはなりません。

未修正のPHPを使っている場合

最優先は修正版への更新です。自分でPHPを切り替えられるサーバーなら、更新前にファイルとデータベースをバックアップし、互換性を確認して切り替えます。その後、トップページ、記事、管理画面、問い合わせ、REST API、予約投稿などを代表テストします。

サーバー会社がPHPの更新を一括管理している場合は、対象プランの公式告知を確認します。事業者による修正と、ユーザーが管理画面で選択するPHP系列の変更は別の場合があります。自分で更新できないときは、事業者に対応済みか問い合わせるのが確実です。

PHP 8.1以前など、サポート終了の系列を使っている場合

今回の修正版が提供されない古い系列では、サポート中のPHPへ移行する必要があります。アプリケーションの互換性が原因ですぐ更新できないときは、サーバー会社に相談し、アクセス制限や一時停止も含めて暫定対応を判断してください。設定変更だけで今回の問題を完全に回避できるとは考えない方が安全です。

すでに侵入を疑う兆候がある場合

知らない管理者アカウント、不審なPHPファイル、覚えのない変更、ログ上の不自然な処理などがあれば、いきなりファイルを消さず、ログとバックアップを保全します。被害が疑われる場合は必要に応じてサイトの公開制限や専門家への相談を検討してください。

WordPressのPHPバージョンはどこで確認する？

WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」を開くと、稼働中のPHPバージョンを確認できます。サーバーの管理画面にPHP切替メニューがある場合は、そこでも利用中の系列を確認しておきます。

2026年10月21日に公表された、今回の2件（CVE-2026-109618／CVE-2026-109619）に対する修正版は次のとおりです。

PHP 8.2系：8.2.35以降
PHP 8.3系：8.3.36以降
PHP 8.4系：8.4.27以降
PHP 8.5系：8.5.12以降

これは「今回の2件に対応した最初の修正版」を示したものです。PHPのすべての脆弱性が解消するという意味ではありません。また、提供事業者が独自に修正をバックポートしている環境では、バージョン文字列だけで判定できないことがあります。

PHP2Shellとは？なぜWordPressの更新だけでは足りないのか

PHP2Shellは、PHPのメモリ不足時の処理に関するCVE-2026-109618と、リクエスト処理に関するCVE-2026-109619の組み合わせを指します。条件がそろうと、認証されていない外部の第三者にコードを実行される可能性があります。実際に悪用された脆弱性として、2026年10月26日（現地時間）に米国CISAのKEVカタログに掲載されました。

WordPressはPHPの上で動きます。WordPress本体を最新版にしていても、サーバー側のPHPが未修正なら、それだけではPHP2Shellへの対策になりません。一方、すべてのWordPressサイトで必ず攻撃が成功するという意味でもなく、影響はPHPの実行環境や構成によって異なります。

実際に効率家ラボで確認したこと

PHP 8.2.35を確認。修正済みでも調査は終わりではなかった

私が使っていたスター系のフリープランでは、2026年10月22日時点でPHP 8.2.35でした。今回の2件については修正済みのバージョンです。ただ、いつ修正されたのか、修正前に何が起きていたかは、バージョンだけでは分かりません。そこで、サーバーに保存されていたログを確認しました。

8日分のアクセスログには、不審なファイルを探す通信があった

2026年10月20〜27日のアクセスログを取得して調べると、.env、.git/config、xmlrpc.phpなどを探すアクセスがありました。WordPressのアップロード領域に、存在しないPHPファイルを探すようなリクエストもありました。インターネット上のサイトでは自動探索の通信自体は珍しくありませんが、自分のブログにも来ていることは確認できました。

応答が403（拒否）や404（見つからない）だったものも多く、そうした通信があったことだけで侵入成功とは判断できません。逆に200という応答があるだけでも、意図しない処理が成功したとは言い切れません。アクセス先、応答内容、前後の通信、ファイルの実体などを合わせて見る必要があります。

確認した期間のアクセス・エラーログでは、侵入に成功したと判断できる明確な証拠は見つかりませんでした。ただし、ログの保存期間外や記録されない通信まで調べたわけではありません。「証拠が見つからなかった」と「絶対に侵入されていない」は区別しています。

自分のサイトでも確認するなら、まず契約中のサーバー管理画面からアクセスログとエラーログを取得します。見覚えのないファイルへのアクセス、管理画面への不審な認証試行、応答ステータスや前後の通信を調べ、必要に応じて実際のファイルや管理者アカウントと照合します。ログのIPアドレスや認証情報をそのまま公開しないことにも注意してください。

管理者アカウントとWordPress本体も点検した

管理者アカウントは把握している1件だけで、一般ユーザーの登録も無効でした。WordPressのデバッグ設定も無効でした。プラグインには更新候補があったので、PHPとは別に保守が必要なことも分かりました。

WordPress本体のファイル整合性チェックでは、wp-includes/version.phpの1ファイルにチェックサム不一致が出ました。一方、ファイル更新日時が2026年10月7日のWordPress 7.1.3自動更新完了メールと一致することも確認できました。更新された経緯の手掛かりにはなりますが、チェックサム不一致の原因はまだ確定していません。日本語版など配布差異や検査方法の問題もあり得るため、改ざんとも正常とも決めつけず、ファイルを削除・修復しませんでした。

php.iniでは、実際に変更した2項目だけを記録する

私はPHP設定のdisplay_errorsをOff、error_reportingをE_ALLに設定しました。前者はPHPのエラー詳細を公開ページに表示しないため、後者は警告を含めた幅広いエラーを報告対象にするためです。E_ALLだけでログ記録が有効になるわけではなく、出力や保存はサーバー側の設定によります。

log_errorsやerror_logの値・保存先は、私自身では追加指定していません。サーバー側のエラーログ機能を利用しており、個別にログ保存先を設定する必要はありませんでした。

その後のサーバー移行でもphp.iniは新環境へ移しています。なお、こうした設定はエラー表示や調査のしやすさに関するもので、PHP2Shellそのものを修正する対策ではありません。E_ALLでは警告が増えることもあるため、エラーログの内容や容量は継続して確認します。

サーバー移行後はPHP 8.3.36へ

今回の点検を進める中で、容量やバックアップも考え、ドメイン特典サーバーへ移行しました。移行先はPHP 8.3.36で、今回の2件への修正が入っています。HTTPS、記事と画像、管理画面、REST API、ads.txtが正常に表示されることを確認しました。

ただし、サーバーを引っ越したこと自体が脆弱性対策なのではありません。移行先のPHPが修正版であること、WordPressの主要機能が動くことを分けて確かめました。サーバー移行の具体的な失敗や復元手順は、別の記事で扱う予定です。

今回の修正だけで終わらない。PHPのサポート期限も確認する

PHP公式によると、PHP 8.2のセキュリティサポートは2026年12月31日まで。8.3は2027年12月31日、8.4は2028年12月31日までです。今回のPHP2Shellが修正された8.2.35でも、系列のサポート終了後にそのまま使い続けるのは避けたいところです。

ただし、新しいPHPへの切替時にはWordPress、テーマ、プラグイン、自動投稿やフォームの互換性を確かめる必要があります。私は現在8.3.36で安定動作を優先し、8.4への切替は別の工程で検討することにしました。

PHPを使わない構成にすれば解決する？

PHP2Shellを見て、PHPを使わないブログにすればどうかとも考えました。ただ、WordPress自体はPHPで動くため、通常のWordPress運営からPHPだけを取り除くことはできません。

現実的な選択肢は3つあります。①WordPressを継続し、サポート中の修正版PHPを維持する。②WordPressで書いた記事を静的HTMLに変換し、公開側ではPHPを動かさない。③WordPressをやめ、AstroやHugoなどで静的サイトを運営する。

②は管理用のWordPressにはPHPが残ります。③はPHPを不要にできますが、問い合わせフォーム、サイト内検索、プラグイン、自動化などを作り直す手間があります。静的化しても別のセキュリティリスクまで消えるわけではありません。私は現在の自動化との兼ね合いから、WordPressを使い続ける方針です。