今回の対策は、サイトで使っているPHPを修正済みの状態にすることです。WordPress本体やプラグインを更新するだけでは解決しません。
まずは、次の3点を確認してください。
・PHPのバージョン：WordPressなら、管理画面の「サイトヘルス」で分かります
・PHPの修正を適用する担当：共用のレンタルサーバーなら通常はサーバー会社です。VPSなど自社で管理する環境なら、社内の管理者か委託先に確認します
・サーバー会社の告知：契約中のプランで対応が完了しているか、利用者にも操作や動作確認が求められているかを見ます

修正版は、8.2系が8.2.35、8.3系が8.3.36、8.4系が8.4.27、8.5系が8.5.12です。ただし、番号を変えずに修正しているサーバー会社もあるため、表示された番号だけでは判断できません。

PHP 8.1以前は公式のサポートが終わっています。サーバー会社の独自の修正で今回の分が済んでいても、今後も独自の修正が出る保証はないため、8.3以上への移行を早めに計画してください。PHP 8.2も、今回の修正版は出ていますが、2026年12月31日でサポートが終わります。修正の状況を確認したうえで、年内に8.3以上へ移る日程を、管理者や制作会社と決めておいてください。

php2shell（PHP2Shell）は、2026年10月21日にPHP公式（php.net）が修正版を公開した、PHP本体の重大な脆弱性（セキュリティ上の欠陥）2件の通称です。どちらもメモリの扱いに関する欠陥で、ログインしなくても外部から任意のプログラムを動かされる「リモートコード実行」につながるおそれがあります。識別番号はCVE-2026-109618とCVE-2026-109619です。

PHPは、Webサイトの裏側でプログラムを動かす言語で、WordPressもPHPで動いています。深刻度を示すCVSSは、PHP側の評価で9.2、米国の脆弱性データベースNVDの評価で9.8と、どちらも最も深刻な区分です。

PHP公式が影響ありとしているのは、8.2系では8.2.35未満、8.3系では8.3.36未満、8.4系では8.4.27未満、8.5系では8.5.12未満です。8.1以前はサポートが終わっており、そのまま使える公式の修正版は出ません。IPA（情報処理推進機構）は、セキュリティ企業Wizの見解として、PHP 5.4以降の古いバージョンも影響を受けると紹介しています。

名前の似た「wp2shell」は、7月に公表されたWordPress本体の脆弱性で、対策はWordPressの更新でした。今回のphp2shellとは別の問題です。

攻撃の「試み」はすでに観測されていますが、侵害に成功したという確かな報告は、10月23日未明の時点で、公的機関の発表や報道には見当たりません。

米CISA（サイバーセキュリティ・インフラストラクチャ安全保障庁）は、21日の公表時点で悪用は観測していないとし、23日未明の時点でも、実際に悪用された脆弱性の一覧（KEV）に載せていません。一方、Cloudflareは攻撃の通信を観測したと公表し、報道では数百万件規模の攻撃の試みが伝えられています。これは試みの数で、成功した数ではありません。

国内では、IPAとJPCERTコーディネーションセンター（JPCERT/CC）が22日に注意喚起を公開しました。21日夜には国家サイバー統括室や首相がXで早急な対応を呼びかけ、一部のWebサービスは一時停止や緊急メンテナンスを行いました。

報告がないことと、被害がないことは同じではありません。修正の適用は急いでください。

修正前に攻撃を受けていないかを調べる手がかりとして、JPCERT/CCは、サーバーの記録に残る不審な通信やエラー、PHPの異常な停止・再起動などを挙げています。社内に調べられる人がいなければ、サーバー会社や制作会社に確認を依頼してください。

WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。管理者の権限がなければ、制作会社や保守会社に確認を頼みます。WordPress以外のサイトは、サーバー会社の管理画面のPHP設定で分かることがあります。表示された番号は、次のように読みます。
・系列ごとに8.2.35、8.3.36、8.4.27、8.5.12以上（例：8.4系なら8.4.27以上）：修正版です
・8.2〜8.5で、上の番号より小さい：修正前か、サーバー会社が番号を変えずに修正した状態です。告知を見て判断します
・8.1以前：公式の修正版がないバージョンです。サーバー会社の告知で独自の修正が済んでいるかを確認し、済んでいても8.3以上への移行を計画します

(2026年10月22日時点）

※PHPの番号が小さくても修正済みの場合があります。サーバー会社の告知で確認してください。

出典：PHP公式（php.net）

サイトヘルスの番号だけでは、今回の修正が済んでいるか判断できない場合があります。契約先の告知で、契約中のプランと使っているバージョンが修正の対象に入っているかを見てください。分からなければ、契約先か制作会社に問い合わせます。

共用のレンタルサーバーで、契約中のプランと使っているPHPのバージョンについて「対応完了・操作不要」と告知されていれば、今回の修正のために利用者がPHPを操作する必要はありません。動作確認の案内があれば、それに従ってください。主なレンタルサーバーの告知は、10月23日0時20分ごろの時点で次のとおりです。

・さくらのレンタルサーバ：選べるすべてのPHPバージョンで対応完了、操作不要
・エックスサーバー：PHP 5.6〜8.5に修正を適用済み（5.5以下は検証中）
・ロリポップ！：対応完了。一部の機能を無効にしたため、サイトの動作確認を案内
・ConoHa WING：対応完了。PHPバージョンの変更は不要
・ヘテムル：8.2〜8.5は公式の修正版、それより古いバージョンは公式の修正内容や独自の修正で対応。一部の機能を無効にしたため、動作確認を案内
・お名前.com レンタルサーバー：現在のバージョンのまま、修正を順次適用中
・KAGOYA：レンタルサーバーは22日24時までの完了を見込むと告知（完了の告知はまだ）。その他のプランは方針を調整中

告知で今回の修正を確認できない場合は、次のように進めます。
・共用のレンタルサーバーで、契約中のプランや使っているバージョンの修正が告知に見当たらない、または対応中：契約先に、修正が済んでいるか、まだならいつ対応するかを問い合わせます。確認が取れるまでは、対応済みと判断しないでください
・VPSや自社サーバーなど、PHPの管理を自社で担う環境：社内のサーバー管理者か委託先に、修正の適用状況と、まだの場合の対応予定を確認します

修正がまだ当たっていない8.1以前のサイトについて、米CISAは、修正か更新ができるまでオフラインにするよう勧めています。IPAも、すぐに修正できない場合は、サポート状況の確認、アクセス制限や一時停止を含む暫定対策、今後の移行や廃止の方針などを整理して判断するよう求めています。サイトの一時停止は問い合わせや集客も止めるため、制作会社と相談して、止める条件と再開の条件を決めます。

PHP 8.1以前でも、契約中のプランと使っているバージョンの修正が済んでいれば、今回の脆弱性への対応は完了しています。そのために急いでバージョンを切り替える必要はありません。ただし公式のサポートは終わっており、今後も独自の修正が出る保証はないため、8.3以上への移行は計画して進めてください。

7.4や8.1から8.3へのように大きく上げると、表示や機能に不具合が出ることがあります。新しいバージョンでは古い書き方が使えなくなるため、テーマやプラグイン、フォームが動かない、画面が真っ白になるといったことが起こりえます。元に戻せるかは事前の準備しだいで、切り替える前にバックアップを取り、戻す手順を決めておくことが前提です。8.3系の中で8.3.36へ上げるような同じ系列の中での修正は不具合が出にくい更新ですが、一部の機能を止めたサーバー会社もあるため、表示とフォームは確認してください。大きく上げるときは、次の順で進めます。

1.バックアップ：ファイルとデータベースを保存し、実際に戻せるかも確かめます 　

2.戻し方を決める：PHPの設定を元のバージョンに戻すのか、バックアップから復元するのかを決めます。バックアップから復元すると、バックアップを取った後に受け付けた問い合わせや注文の記録、更新した内容は消えるため、その扱いも決めておきます。元のバージョンに戻すなら、戻す先にも修正が当たっているかを告知などで先に確かめます。8.1以前に戻すのは、修正が当たっている場合に限った、不具合を直すまでの一時的な措置です 　

3.テスト環境で切り替える：本番と同じ内容の確認用サイトで、WordPress本体・テーマ・プラグインを最新にしてから、サーバー会社の管理画面のPHP設定で切り替えます 　

4.動作確認：主要ページの表示（スマートフォンを含む）、管理画面のログイン、フォームの送信と通知メールの到着、予約や決済などの機能を確かめます 　

5.本番への反映：アクセスの少ない時間帯に、テスト環境と同じ順でWordPress本体・テーマ・プラグインの更新とPHPの切り替えを行い、直後に4と同じ項目を確認します

互換性チェックでよく紹介されるプラグイン「PHP Compatibility Checker」は更新が止まっており、PHP 8.0までしか判定できません。8.3以上への移行は、テスト環境で実際に動かして確かめます。

サイトを持つ会社が委託先に確認するのは、次の3点です。

・PHPのバージョンと、修正済みと判断した日時・根拠
・誰が、いつまでに対応するか（8.1以前や8.2なら、8.3以上へ移す時期も）
・PHPの更新や動作確認が、保守契約に含まれるか


制作会社・保守会社の側は、管理するサイトが多いほど、思い出した順の確認では漏れが出ます。まず、サイトごとに次の項目を一覧にします。

・サイトのURL（同じ顧客の別ドメインやキャンペーンサイトも含む）
・サーバー会社・プラン・種類と、契約者・ログインできる人 ・PHPのバージョン（ドメインごとに設定できるサーバーもあるため、ドメイン単位で）
・WordPress以外のPHPのプログラム（独自のフォームなど）
・保守契約の範囲と、対応を確認した日時・根拠

優先するのは、8.1以前のサイトと、VPSなど自分たちでPHPを更新するサイトです。顧客には「対応完了を確認済み」「確認中」「お客様の判断が必要」の3つに分けて伝えます。完了なら確認した日時と根拠を、確認中なら次の連絡日を、判断が必要なら決めてほしいこと（バージョンの移行や一時停止など）を添えます。

保守契約にPHPの更新や検証が含まれない場合は、作業内容と費用を着手前に合意し、記録に残します。サイトごとのPHPのバージョンとサポート期限を台帳にしておくと、次も慌てずに済みます。

PHP 8.2のセキュリティサポート（公式が脆弱性の修正を出す期間）は、2026年12月31日で終わります。サポートが終わってもサイトがすぐに止まるわけではありませんが、今回8.2.35に更新したサイトも、サポート終了後に見つかる脆弱性には公式の修正を受けられません。PHP公式が示す各系列のサポート終了日は次のとおりです。

・PHP 8.1：2025年12月31日（終了済み）
・PHP 8.2：2026年12月31日
・PHP 8.3：2027年12月31日
・PHP 8.4：2028年12月31日
・PHP 8.5：2029年12月31日

WordPress.orgが推奨するPHPも8.3以上です。8.1以前から上げるなら、2か月あまりで再び移行が要る8.2ではなく、8.3以上を選びます。テーマやプラグインが対応していれば、期限の長い8.4・8.5も候補です。8.2のサイトは、いまは同じ系列内の修正で守り、年内に8.3以上へ切り替える2段階で進めます。

・WordPressやプラグインの更新、WAFやセキュリティプラグインで足りると考える
・PHPの番号だけで、修正済みかどうかを判断する
・8.1以前で今回の修正が済んだことに安心して、移行の計画を立てない
・確認用のphpinfo（PHPの設定を表示するファイル）を公開場所に残し、サーバーの情報を外から見える状態にする
・バックアップや戻し方を決めないまま、バージョンを大きく上げる
・8.2.35にしたので、年明け以降も安心だと考える

・PHP 8.5.12・8.4.27・8.3.36・8.2.35のリリース（PHP公式・2026年10月21日）
・PHPのサポート期間（PHP公式）
・CVE-2026-109618のセキュリティアドバイザリ（PHP・2026年10月21日）
・CVE-2026-109619のセキュリティアドバイザリ（PHP・2026年10月21日）
・CVE-2026-109618の評価（米NVD・2026年10月21日）
・PHPの脆弱性対策について：PHP2shell（IPA・2026年10月22日）
・PHPにおける複数の脆弱性に関する注意喚起 JPCERT-AT-2026-0033（JPCERT/CC・2026年10月22日）
・Critical Vulnerabilities in PHP Require Immediate Patching（米CISA・2026年10月21日）
・PHP の重大なセキュリティリリース（WordPress.org・2026年10月21日）
・WordPressの動作環境（WordPress.org）
・Cloudflare deploys protections against php2shell vulnerability（Cloudflare・2026年10月21日）
・PHP「緊急」脆弱性悪用の試み、数百万件に（ITmedia NEWS・2026年10月22日）
・WordPressの脆弱性対策について：wp2shell（IPA・2026年7月22日）

ホームページ保守契約は必要？中小企業が確認すべき対応範囲と費用の考え方
古いホームページはリニューアルすべき？部分改修で対応できるケースとの違い
ホームページ制作会社を乗り換えるときの引き継ぎ｜ドメイン・サーバー・管理画面の権限を確認する方法
ホームページ運用担当者の引き継ぎ｜異動・退職で止めないためのマニュアルと権限整理