【10/23最新】PHP脆弱性、WordPressの対応方法｜会社のサイトで確かめる7つのこと（php2shell）

2026年10月21日、PHPの開発元が、ログインなしで外からサーバーを乗っ取られるおそれのある脆弱性2件（通称 php2shell、CVE-2026-109618・CVE-2026-109619）を修正した版を公開しました。WordPress は PHP で動いているので、会社のサイトを WordPress で作っているなら、ほぼ確実に関係があります。

ただし、やるべきことは「WordPress を最新にする」ではありません。WordPress.org は、WordPress 本体の更新は不要で、サイトを動かしている PHP を更新するよう呼びかけています（WordPress.org）。

この記事は、WordPress で会社のサイトを持つ担当者の方に向けて、何を・どこで・誰に確かめればよいかを7つにまとめたものです。エンジニアでなくても確かめられることから順に並べ、技術者に任せる部分は「頼み方」まで書きました。脆弱性の仕組みやサーバーでの緩和策は、php2shell の解説記事をご覧ください。

結論：確かめるのは WordPress ではなく、その下で動いている PHP です。 管理画面に出る PHP の番号だけでは「修正済み」と判断できないので、サーバー会社の告知か、サイトを管理している会社の回答で確かめてください。PHP 8.1 以前で動いているなら、8.3 以上への切り替えが必要です。

【10月23日時点】WordPressのサイトに関わる最新の状況

• 国内では少なくとも246の組織がサイトやサービスを止めた：piyolog の集計では、10月21日〜22日にサービスやサイトを止めた組織は246にのぼります（10月23日昼までに各組織の告知で確かめられた範囲。piyolog）
• 国内の主なレンタルサーバーは修正をほぼ当て終えた：エックスサーバー・ロリポップ・さくらのレンタルサーバなどが、サポートの切れた古い PHP も含めて修正を当てたと告知しています（サーバー会社別の状況）。ただし、VPS やクラウドで動かしているサイトは、自社か管理会社が更新しない限り直りません
• WordPress のサイトへの攻撃は続いている：WordPress 向けのセキュリティ企業 Wordfence は、自社のファイアウォールで 7.4万件以上の攻撃や探りを止めたと発表しました（10月22日）。10月22日時点で侵害が確定した例はまだ無いとしつつ、WordPress のログに残らない形で起きている可能性もあるとしています（Wordfence）
• 狙われているのは wp-config.php の中身：同社によると、攻撃者はサーバーを調べたあと、データベースのパスワードなどが入った wp-config.php や環境変数を盗み、アップロード用のフォルダなどに Web シェル（遠隔操作用のファイル）を置こうとしています
• 侵害の確認は10月17日以降が対象：AWS は、公表の4日前の10月17日に悪用の試みを観測しています（AWS）。JPCERT/CC も10月22日に注意喚起を出し、ログで確かめる観点を示しました（JPCERT/CC）

まず押さえておきたい3つのこと

1. WordPress本体やプラグインを更新しても直らない

今回の脆弱性は、WordPress ではなくPHP そのものにあります。WordPress.org は、WordPress 本体の更新は不要で予定もないとしたうえで、ホスティング会社に確かめ、必要なら PHP を早急に更新するよう求めています（WordPress.org）。

なお、2026年7月に話題になった wp2shell は、名前は似ていますが別の問題です。こちらは WordPress 本体の脆弱性で、本体を 6.8.6・6.9.5・7.0.2 以降に更新すれば直ります。php2shell は PHP の更新、wp2shell は WordPress 本体の更新と覚えておきましょう。ついでに、本体が最新（10月23日時点で 7.1.3）になっているかも確かめておくと安心です。

2. セキュリティプラグインやWAFだけでは防ぎきれない

Wordfence などのセキュリティプラグインは、WordPress の中で動いて攻撃を選り分けます。Wordfence 自身も、自社のファイアウォールが守るのは WordPress のアプリの層で、今回は WordPress が動き出す前に始まる攻撃もあるため、PHP の更新とサーバーの再起動が欠かせないとしています（Wordfence）。PHP 公式も、Apache の mod_php ではアプリのコードが動く前に攻撃が成り立つとしています（PHP公式）。

国内でよく使われる SiteGuard WP Plugin は、主にログインや管理画面を守るプラグインで、今回のような PHP への攻撃を防ぐためのものではありません。

Cloudflare などの WAF（Webアプリケーションファイアウォール）は、更新までの時間を稼ぐのに役立ちます。ただし、Patchstack や Sucuri は、サーバーに WAF を通らずに直接届く道が残っていると回り込まれると注意しています（Patchstack、Sucuri）。どれも PHP の更新の代わりにはなりません。

3. サイトヘルスに警告が出なくても、安全とは限らない

WordPress の「サイトヘルス」は、PHP が古すぎると警告を出します。ところが、この判定は 8.3 や 8.4 といった系列しか見ておらず、末尾の番号は見ていません。私たちが10月23日に WordPress.org の判定の仕組み（API）で確かめたところ、修正されていない 8.3.1 も、修正版の 8.3.36 も、同じ「問題なし」の判定でした（判定の API）。

逆に、番号が古くても修正済みのこともあります。サーバー会社によっては、番号を変えずに修正だけを当てているからです（後述）。つまり、サイトヘルスの表示だけでは、修正済みかどうかは分かりません。

WordPressのサイトで確かめる7つのこと

① PHPのバージョンを見る

WordPress の管理画面に管理者でログインし、次の順に開きます（WordPress.org）。

1. 左のメニューの「ツール」→「サイトヘルス」
2. 上の「情報」タブ
3. 「サーバー」の欄を開く
4. 「PHP バージョン」の数字を控える

同じ欄の「PHP SAPI」も控えておくと、技術者に状況を伝えやすくなります。apache2handler と出ていれば Apache の mod_php で、PHP 公式が最もリスクが高いとしている環境です。fpm-fcgi なら PHP-FPM、litespeed なら LiteSpeed です。

レンタルサーバーなら、サーバーの管理画面の「PHP のバージョンの設定」のような画面でも、サイトごとの版を確かめられます。なお、確かめるために phpinfo() を書いたファイルを公開の場所に置くのはやめましょう。サーバーの設定が外から丸見えになります。

② 修正済みかどうかを確かめる

控えた番号を、上の表に当てはめてください。PHP 公式の修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です（PHP公式）。これ以上なら修正済みです。

これより小さい番号でも、サーバー会社が番号を変えずに修正を当てていることがあります。たとえばエックスサーバーは PHP 5.6〜8.1 の修正をバージョン番号を変えずに当て、ConoHa WING はすべての版で番号を変えずに修正したと告知しています。この場合は、サーバー会社の告知で、自分のサーバーと PHP の版が修正済みかを確かめます。

技術者に確かめてもらう場合は、PHP のビルドの日付（Build Date）が10月21日以降かを見てもらうのが確実です。番号が変わらない修正でも、ビルドの日付は新しくなるためです。

PHP 8.1 以前（7.4・8.0・8.1 など）で動いている場合は、PHP 公式の修正は出ません。IPA も、調査に関わった Wiz 社の情報として、PHP 5.4 以降の版は少なくとも1つの脆弱性の影響を受けるとしています（IPA）。サーバー会社が独自に修正を当てていても、その版はもうサポートが終わっています。8.3 以上へ切り替える前提で準備しましょう（⑤）。

③ どこで動いているかを確かめる

PHP を直すのが誰かは、サイトがどこで動いているかで決まります。サーバーの契約書や請求書を見て、サーバー会社の名前とプランの名前を確かめましょう。

• 共有のレンタルサーバー（エックスサーバー、ConoHa WING、さくらのレンタルサーバ、ロリポップ! など）：PHP の修正はサーバー会社が当てます。自社で確かめるのは、告知の内容と、管理画面で古い PHP を選んだままになっていないかです
• VPS・クラウド・専用サーバー（プラン名に「VPS」「クラウド」「専用」と入っているもの、AWS の Lightsail や EC2 など）：PHP の更新は利用者の仕事です。サーバー会社は直してくれません。更新したあとに Web サーバー（Apache や PHP-FPM）を再起動しないと、古い PHP が動き続ける点にも注意が必要です
• 社内のサーバー：情報システムの部門か、構築した会社に確かめます

④ 誰が管理しているかを確かめる

サイトを制作会社や保守会社に任せている場合は、すぐに状況を問い合わせましょう。聞くことが漏れないよう、次の文面をそのまま使ってください。

制作会社と連絡が取れない、もう会社が無いという場合は、次の順に確かめます。

1. サーバーの契約者：請求書やクレジットカードの明細で、サーバー代を誰が払っているかを確かめます。自社の名義なら、サーバー会社のサポートに直接問い合わせられます
2. WordPress の管理者のアカウント：自社で管理者としてログインできるかを確かめます。できれば、①〜②の確認は自社でできます
3. サーバーの管理画面に入れるか：入れれば、PHP のバージョンの切り替えも自社でできます

どれも分からない場合や、制作会社の名義でサーバーを契約している場合は、権利関係の整理も含めて専門の会社に相談するのが近道です。エンハンスドでも、管理者が分からなくなったサイトの調査と引き継ぎを承っています。

⑤ PHPを上げる前に準備し、上げたあとに確かめる

PHP 8.1 以前で動いているサイトや、8.2 のサイトは、この機会に 8.3 以上へ切り替えましょう。WordPress も PHP 8.3 以上を推奨しています（WordPress.org）。PHP 8.2 は2026年12月31日でサポートが終わります。

注意したいのは、古いテーマやプラグインが、新しい PHP で動かなくなることがある点です。プラグインの説明にある「必要な PHP のバージョン」は下限しか示しておらず、新しい PHP で動くかどうかは分かりません。互換性を調べるプラグインとして知られる PHP Compatibility Checker も、すでに保守が終わっています（WordPress.org）。確実なのは、テスト環境で実際に切り替えて動かしてみることです。

切り替えたあとは、少なくとも次を確かめます。

• トップページと、下の階層のページが崩れずに表示されるか（スマホでも）
• 問い合わせフォームを実際に送れて、自動返信のメールが届くか
• 管理画面にログインでき、記事の保存と画像のアップロードができるか
• 会員の機能や決済があれば、それも動くか

画面に「このサイトで重大なエラーが発生しました」と出たら、原因はたいていテーマかプラグインです。WordPress は、管理者のメールアドレスに「リカバリーモード」でログインするためのリンクを送ります。そこから原因のプラグインを止めて直せます（WordPress.org）。メールが届かないこともあるので、すぐに直せない場合は、サーバーの管理画面で PHP を元の版に戻します。戻すのは、その版にもサーバー会社の修正が当たっている場合に限り、原因を直すまでの一時的な措置にしてください。

⑥ 乗っ取られていないかを確かめる

PHP を修正しても、修正の前に入り込まれていたら、その被害は消えません。10月17日以降について、2段に分けて確かめましょう。

担当者が管理画面でできる確認は次のとおりです。

• 「ユーザー」の一覧で、権限が「管理者」の人に見覚えのない人がいないか
• 「プラグイン」の一覧に、入れた覚えのないものがないか
• Google Search Console の「セキュリティの問題」に何か出ていないか
• Google で site:自社のドメイン と検索し、見覚えのないページ（外国語の広告など）が出ないか
• サーバー会社から、不正アクセスやファイルの改ざんの連絡が来ていないか

サーバーに入れる技術者に頼む確認は次のとおりです。JPCERT/CC は、ログで次の3点を確かめるよう示しています（JPCERT/CC）。

• 応答の PHPSESSID の Cookie に、異常に長い値や形のおかしい値が入っていないか
• 不審な multipart/form-data のリクエストと、その前後のメモリ上限のエラーや HTTP 500 のエラーがないか
• PHP のワーカーが予期せず落ちたり、頻繁に再起動したりしていないか

WordPress に特有の確認としては、Wordfence が公表した痕跡（wp2s.php・php2shell.php・axiom_*.php という名前のファイル、P2S_OK などの文字列）を探すことや、本体のファイルが書き換えられていないかの照合があります。WP-CLI が使えるなら、次のコマンドが役立ちます（WP-CLI）。

wp core verify-checksums                     # 本体のファイルの改ざん・余分なファイル
wp plugin verify-checksums --all             # 公式ディレクトリのプラグインの改ざん
wp user list --role=administrator            # 管理者の一覧（登録日つき）
wp plugin list --status=must-use             # 自動で読み込まれるプラグイン（mu-plugins）
wp cron event list                           # 予定された処理
find wp-content/uploads -type f -iname '*.php'   # アップロード用のフォルダに PHP がないか

ただし、JPCERT/CC も、痕跡が見つからなくても攻撃を受けていないとは言い切れないとしています。疑わしい点が見つかったら、次の対応をとります。

• サイトを止め、調査が終わるまで公開しない
• WordPress の全員のパスワード、サーバーと FTP・SFTP のパスワード、データベースのパスワードを変える
• wp-config.php の認証用キー（ソルト）を作り直し、全員をログアウトさせる（WordPress.org）
• サイトにつないでいる外部サービスの API キーも変える（メモリの中身が漏れたおそれがあるため。Patchstack）
• 問い合わせフォームなどの個人情報が漏れたおそれがある場合は、個人情報保護委員会への報告が必要になることがあります。専門家に調査を頼みましょう

⑦ 忘れているサイトがないかを確かめる

見落としやすいのが、メインのサイト以外の WordPress です。

• キャンペーンサイト、採用サイト、ブランドサイト、イベントのサイト
• テスト環境（ステージング）や、リニューアル前の旧サイト
• 何年も前に作って、今はほとんど更新していないサイト

使っていないサイトは、この機会に閉じるのがいちばん安全です。残す必要があるなら、PHP を使わない静的なページに置き換える方法もあります。Sucuri も、WAF を通らない古いホスト名やステージングを閉じるよう勧めています。

サーバー会社別の状況と確認のしかた（10月23日時点）

国内の主なサーバー会社の告知を、10月23日の夕方時点でまとめました。会社の名前のリンクから、各社の告知を開けます。状況は変わるので、最新の情報は必ず告知で確かめてください。

表の「番号は変わらない」に注目してください。番号を変えずに修正を当てた会社が多く、たとえば ConoHa WING は、修正済みでもサイトヘルスに修正版の番号（例：8.5.12）ではなく、これまでの番号（例：8.5.11）が出ることがあると告知しています。

共有のレンタルサーバー

各社とも、10月22日までに修正の作業を進めました（KAGOYA の一部のプランを除く）。

自分でPHPを更新する必要があるもの

次のような、サーバーを自分で管理する形のサービスでは、サーバー会社は PHP を直してくれません。

• KUSANAGI：PHP 8.2〜8.5 の修正済みのパッケージが公開されています。自分で更新して、PHP を再起動します。8.1 以前の修正は出ないので、移行が必要です（KUSANAGI）
• AWS Lightsail の WordPress：AWS は、動いているインスタンスの中身は更新できないとしています。更新済みのイメージから新しいインスタンスを作り、サイトを移すよう案内しています
• 各社の VPS・クラウド・専用サーバー（ConoHa VPS、さくらの VPS、AWS の EC2 など）：OS のパッケージを更新し、Apache や PHP-FPM を再起動します。手順はphp2shell の解説記事にまとめています

よくある質問

サイトヘルスで「8.4.27」と出ました。もう何もしなくていいですか？

PHP の修正は済んでいます。ただし、修正の前に入り込まれていないかは別の話です。10月17日以降について、⑥の確認をしてください。

サーバー会社が「対応済み」と発表しています。自社では何もしなくていいですか？

共有のレンタルサーバーなら、PHP の修正はサーバー会社の仕事なので、多くの場合は済んでいます。それでも、管理画面でサポートの切れた古い PHP を選んだままになっていないかと、侵害がないかは自社で確かめる必要があります。VPS やクラウドで動かしているなら、サーバー会社は PHP を直さないので、自社か管理会社が更新します。

小さな会社のサイトや、ほとんど見られていないサイトでも狙われますか？

狙われます。攻撃は、インターネット上のサーバーを機械で片っ端から探る形で行われています。公表から2日足らずで、Wordfence のファイアウォールだけでも7.4万件以上の攻撃や探りを止めています。サイトの規模や知名度は関係ありません。

WordPressのメンテナンスモードにすれば安全ですか？

安全とは言えません。メンテナンスモードのプラグインは、WordPress が動き出してから表示を切り替える仕組みなので、その手前で起きる PHP への攻撃は防げません。止めるなら、サーバーの管理画面でサイトの公開を止めるなど、サーバーの側で止めます。

Cloudflareを使っています。大丈夫ですか？

Cloudflare は、無料のプランも含めて WAF で防御を当てたと発表しています。ただし、サーバーに Cloudflare を通らずに直接届く道が残っていると、回り込まれます（Patchstack）。WAF は時間稼ぎで、PHP の更新は別に必要です。

PHPを上げたら「重大なエラー」が出ました。どうすればいいですか？

管理者のメールに届くリカバリーモードのリンクから入り、原因のプラグインやテーマを止めます。すぐに直せなければ、サーバーの管理画面で PHP を元の版に戻し（その版にも修正が当たっている場合に限ります）、テスト環境で原因を調べてから、もう一度切り替えます。

サーバーで php -v と打った番号と、サイトヘルスの番号が違います

よくあることです。php -v はコマンドラインの PHP の版で、Web サイトを動かしている PHP とは別のことがあります。サイトに効いているのは、サイトヘルスに出る版（Web の側の PHP）です。

7月の wp2shell と何が違いますか？

wp2shell は WordPress 本体の脆弱性で、本体を 6.8.6・6.9.5・7.0.2 以降に更新すれば直ります。今回の php2shell は PHP の脆弱性で、WordPress をいくら更新しても直らず、PHP の更新が必要です。

PHP 7.4 のまま使い続けるとどうなりますか？

PHP 7.4 には PHP 公式の修正が出ません。サーバー会社が独自に修正を当てていても、今後また見つかる脆弱性が直る保証はありません。WordPress の統計では、いまも WordPress のサイトの約35%が PHP 8.1 以前で動いています（WordPress.org）。古いまま放っておくほど、切り替えの手間も大きくなります。

年内にやっておきたいこと

今回をしのいでも、次の締め切りがすぐに来ます。PHP 8.2 は2026年12月31日でサポートが終わります。年内に、次の3つを済ませておきましょう。

1. すべてのサイトを PHP 8.3 以上にする（8.1 以前と 8.2 のサイト）
2. サイトの一覧を作る：どのサイトが、どのサーバーで、どの PHP と WordPress で動いていて、誰が管理しているか
3. 更新の担当と頻度を決める：WordPress 本体・プラグイン・PHP を、誰が、いつ更新するか。保守の契約に何が含まれるか

まとめ

• php2shell は PHP の脆弱性。WordPress 本体やプラグインを更新しても直らない
• サイトヘルスの番号だけでは修正済みか分からない。サーバー会社の告知か、管理会社の回答で確かめる
• 共有のレンタルサーバーはサーバー会社が修正を当てた。VPS・クラウドは自社か管理会社が更新する
• PHP 8.1 以前・8.2 のサイトは、年内に 8.3 以上へ。切り替えの前にバックアップ、あとに動作の確認
• 修正のあとも、10月17日以降に入り込まれていないかを確かめる

WordPress のサイトは、作ったあと誰も PHP を気にしないまま何年も動き続けていることが少なくありません。今回をきっかけに、自社のサイトを誰が守っているのかを確かめておきましょう。

参考資料

• PHP の重大なセキュリティリリース - WordPress.org 日本語（原文：Critical PHP Security Release）
• PHP公式ニュース（セキュリティアドバイザリ・各修正版のリリース告知）
• PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起 - JPCERT/CC
• PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）- IPA
• PHP2Shell の公表前の悪用を MadPot で特定 - AWS
• Why It’s Urgent to Update PHP on Your WordPress Site - Wordfence
• Attacks on PHP2Shell Continue, But No Known Compromises as a Result Yet - Wordfence
• PHPの重大な脆弱性についての告知 - Patchstack
• PHPの2件のRCEの脆弱性についての解説 - Sucuri
• WordPress の動作環境 - WordPress.org
• Recovery Mode - WordPress.org
• FAQ My site was hacked - WordPress.org
• wp core verify-checksums - WP-CLI
• 各サーバー会社の告知（サーバー会社別の状況の表のリンク先）