PHP2Shell対策｜WordPressで今やる3ステップと自社の対応記録

PHP2Shellを放置すると、外から勝手にサーバー上のプログラムを動かされるおそれがあります。サイトを書き換えられる、問い合わせフォームの個人情報を持ち出される、ほかの会社への攻撃の中継に使われる、といった被害につながります。しかも、WordPressの管理画面で「更新」を押しても直りません。

やることは3つです。

• 契約先のサーバー会社の修正状況を、公式のお知らせで確かめる
• 未修正なら、サーバー会社や制作会社に依頼するか、自社で修正版へ更新する
• 修正の反映と、侵入の痕跡が無いことを確かめる

この3つを終えれば、PHP2Shellで外から操作される穴を塞ぎ、万一入られていても早く気づけます。この記事では、レンタルサーバー・自社管理のサーバー・制作会社に任せている場合の3通りに分けて、どの画面で何を見るかまで示します。

Saixも自社サイト（WordPress）で、10月21日から23日にこの対応をしました。修正版の公開前に防御を固め、公開の翌日に契約先のお知らせで修正の完了を確かめています。点検した範囲で侵害の痕跡はなく、被害は出ていません。

この記事では、その対応を判断の経緯ごと公開します。自社のサーバーの版や構成は、攻撃の手がかりになるので伏せています。

PHP2Shellとは｜WordPressを動かすPHP本体の、外から操作されうる脆弱性

PHP2Shellとは

PHP2Shellは、2026年10月21日（日本時間の夜）に修正版が公開された、PHP本体の重大な脆弱性2件の通称です。PHPは、WordPressを動かしている土台のプログラムです。

識別番号はCVE-2026-109618とCVE-2026-109619です。CVEは、世界共通で脆弱性に振られる管理番号です。PHP公式は「PHP2Shell」という呼び名を使っておらず、発見した研究チームが付けた名前です。

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35の4つです。深刻度はPHP公式の評価（CVSS v4.0＝脆弱性の深刻さを10点満点で表す世界共通の物差し）で9.2と、最高に近い値です。出典はPHP公式の告知とIPA（情報処理推進機構）の注意喚起です。

確認が必要なのは、PHPで動いているすべてのサイトやシステムです。会社のホームページがWordPressなら、全部が確認の対象です。ただし「対象」と「未修正」は別で、サーバー会社が修正済みなら利用者の作業はありません。

関連資料：「Claude Code 事故防止プロンプト集」（PDF・無料）を配布しています。

PHP2Shellの仕組み：細工した通信で、サーバー上のプログラムが動く

PHP公式の告知によると、2件はどちらも、ログインしていない相手から遠隔でプログラムを実行されうる脆弱性です。中身を平たく言うと、次のとおりです。

攻撃者は、こうした状態を狙った細工した通信をサイトに送ります。対象は、Webの通信を受けて動くすべてのPHPで、PHP-FPM（PHPを動かす方式の1つ）や、Apache（Webサーバーのソフト）に組み込んだmod_phpなど、動かし方を問いません。

mod_phpでは、WordPressのプログラムが動き始める前に攻撃が成立する実証があると、PHP公式は書いています。WordPressやプラグインの守りが働く前の段階で起きるので、サイト側の設定では防げません。

対策しないと起きる被害：改ざん・情報の持ち出し・ほかへの攻撃の踏み台

サーバー上で命令を実行されると、サイトの持ち主と同じことが外からできてしまいます。起こりうる被害は次の3つです。

一度入られると、どこまで書き換えられたかを調べ切るのが難しく、復旧の手間は修正の手間を大きく上回ります。だから、修正の確認を先に終わらせます。

WordPressの「更新」やプラグインでは直らない理由

WordPressの管理画面にある「更新」は、WordPress本体・プラグイン・テーマを新しくする機能です。PHPはその下で動く土台なので、ここからは触れません。だから何度「更新」を押しても、PHP2Shellは直りません。

WordPress公式の告知も、この件でWordPress本体の更新は不要で予定もないと明記し、ホスティング会社の更新を確認するよう案内しています。

セキュリティ系のプラグインを入れても同じです。プラグインはWordPressの中で動くので、PHP本体の穴は塞げません。WAF（不正な通信を途中で止める防護壁）を提供するCloudflareの公式解説も、PHP本体の更新が必要だと述べています。

PHP2Shell対策はサーバーの種類で3通り｜誰が直し、自分は何をするか

PHPを更新できるのは、サーバーを管理している側です。自社がどれに当たるかで、次の手順が分かれます。

分からないときは、請求書と管理画面で見分けます。サーバー会社の管理画面に「PHPの版を選ぶ」設定があればレンタルサーバー、コマンドでPHPを入れていればVPS・クラウド、サーバーの請求が制作会社から来ていれば制作会社に任せている形です。

レンタルサーバー：直すのはサーバー会社、自分はお知らせを確認する

サーバー会社がPHP本体を直します。利用者がやるのは、契約先の公式お知らせで「完了」を確かめることです。

ただし会社によっては、古い版のPHPを使っている利用者に、版の切り替えをお願いしています。作業が要るかどうかは会社ごとに違うので、ステップ1の表で必ず確かめます。

この内容を自社に当てはめたい方は、無料のAI活用セッションで相談することもできます。

VPS・クラウドの自社管理：自分で修正版へ更新して再起動する

VPS（自分で管理する貸しサーバー）やクラウドに自分でPHPを入れている場合は、自社の担当者が修正版へ更新し、PHPを再起動します。

PHP公式によると、Linuxの配布元（OSを配る会社や団体）には修正が事前に届いています。OSの更新の仕組みで入れる場合は、配布元のお知らせで修正済みのパッケージを確かめます。具体的な手順はステップ2です。

制作会社・管理会社に任せている：3つの質問で状況を聞く

サイトを制作会社や管理会社に任せている場合は、3つを聞きます。修正が適用済みか、未完了なら予定はいつか、自社側でやることはあるかです。

「PHPのバージョンはいくつですか」と聞くより、「PHP2Shellの修正は適用済みですか」と聞くほうが、答えが明確に返ってきます。そのまま使える問い合わせ文は、ステップ2に載せています。

PHP2Shell対策のステップ1｜自社のPHPと契約先の修正状況を確認する

サイトヘルスで使っているPHPの版を見る

WordPressの管理画面で「ツール」→「サイトヘルス」を開き、「情報」タブの「サーバー」を開くと、使っているPHPの版が表示されます。サイトヘルスは、サイトの状態を診断するWordPressの標準の画面です（WordPress公式のサイトヘルスの説明）。

ここで見るのは、版の系列です。8.2以上ならサポート中の系列で、修正の対象です。8.1以下なら、サポート中の版への移行を計画します。急ぐかどうかは契約先のお知らせに従います（版を変えずに修正を入れ、急いで変える必要はないとしている会社もあります）。

古い番号のままでも、未修正とは限りません。修正版の番号（8.5.12など）が出ていれば修正済みの目安になりますが、番号を変えずに修正を入れる会社もあるからです。詳しくは、この章の最後の見出しで説明します。

関連資料：「Claude Code 事故防止プロンプト集」（PDF・無料）を配布しています。

レンタルサーバー主要5社の対応状況

公式のお知らせを確認できた主要5社は、修正版の公開から1日ほどで対応を終えています。方式は会社ごとに違い、版番号を据え置いて修正だけ入れる会社と、版の系列で扱いを分ける会社があります。

表は、各社の公式お知らせを2026年10月24日から25日に開き、日時・方式・利用者の作業を文言どおりに照合した5社です。利用者の作業が要るかどうかは会社ごとに違うので、表の右の列を必ず見てください。ほかの会社と契約している場合は、契約先の公式お知らせを自分の目で見てください。

お知らせで読む3点と、版番号が変わらない会社の見方

お知らせを読むときに見るのは3点です。どの範囲に適用したか、いつ完了したか、利用者側の作業が要るかです。「対応中」と「完了」は別の状態なので、完了の文言を探します。

ここで一番つまずくのが版番号です。ConoHa WINGや、エックスサーバーの5.6〜8.1のように、版番号を変えずに修正だけを取り込む会社があります。その場合、サイトヘルスに表示される番号は、修正版の8.5.12などにはなりません。

古い番号のままでも未修正とは限らないので、版番号だけで「古いから危ない」とは判断できません。迷ったときの根拠は、サーバー会社のお知らせに置きます。

ゴール：契約先の公式お知らせで「完了」と、利用者作業の要否が読めている状態になっていればOKです

PHP2Shell対策のステップ2｜未修正なら更新を依頼・適用する

サーバー会社・制作会社への問い合わせ文（コピペ用）

契約先のお知らせが見つからない、または「対応中」のままなら、サポート窓口に聞きます。そのまま使える文面です。会社名・名前・サイトのURLを書き換えてください。

件名：PHPの脆弱性（PHP2Shell）への対応状況のご確認

いつもお世話になっております。〇〇株式会社の〇〇です。
契約中のサイト（https://example.com）について、3点お教えください。

1. 10月21日に公開されたPHPの修正（CVE-2026-109618／CVE-2026-109619）は、当サイトのサーバーに適用済みでしょうか
2. 未適用の場合、適用の予定日をお教えください
3. 当方で行う作業（PHPの版の切り替え、動作確認など）があればお知らせください

あわせて、10月23日にPHP公式が出した追加の告知（CVE-2026-115560）への対応予定も、分かればお教えください。
よろしくお願いいたします。

問い合わせる前に、もう一度お知らせを見直します。確かめている間に、完了のお知らせが出ることもあるからです。

この内容を自社に当てはめたい方は、無料のAI活用セッションで相談することもできます。

自社管理のサーバーで修正版を入れて再起動する（8.1までの版は移行）

VPSやクラウドでPHPを自分で入れている場合は、修正版（8.5.12、8.4.27、8.3.36、8.2.35のいずれか）へ更新し、PHPを再起動します。再起動しないと古いプログラムが動き続けるので、更新だけで終わらせません。

# いま動いているPHPの版を確かめる（コマンドで使う版）
php -v

# 修正版へ更新したあと、PHPを再起動する（PHP-FPMの例。8.3の部分は使っている版に合わせる）
sudo systemctl restart php8.3-fpm

# ApacheにPHPを組み込んでいる（mod_php）場合は、Apacheを再起動する
sudo systemctl restart apache2

コマンドで表示される版と、Webで使われる版が違うことがあるので、再起動の後にサイトヘルスでも確かめます。配布元のパッケージで入れた場合は、版番号が修正版と同じにならないことがあります。配布元のセキュリティ情報で、修正済みのパッケージの版を確かめます。

PHP 8.1までの版は公式のサポートが終わっており、正式な修正版は出ていません。PHPの開発チームは、自分でPHPを組み立てて使う人向けに、7.4から8.1用の最小限の修正だけを公開しています。古い版のまま動かしているサイトは、修正を待つのではなく、サポート中の版へ移ることが対応になります。

移行の前に、テーマとプラグインが新しい版で動くかを確かめます。本番で一気に切り替えず、複製した環境で先に試します。制作会社に頼むなら「修正版への更新と再起動、8.1までの版なら移行の見積もり」と具体的に伝えると早く進みます。

10月23日の追加告知への対応を確かめる

2026年10月23日、PHP公式は関連する別の問題について追加の告知を出しました（CVE-2026-115560）。次の定期の更新で直す予定で、それまでは、ファイルのアップロードの進み具合を記録する機能を切るよう勧めています。

起きるのは、セッション（利用者ごとの一時的な記録）の保存形式を、プログラムの実行中に切り替える珍しい組み合わせに限られます。この設定は10月21日の告知でも緩和策の1つとして挙がっており、そのときに入れていれば追加の作業は要りません。

レンタルサーバーなら、この追加告知への対応がお知らせに出るかを見ます。自社管理なら、php.ini（PHPの設定ファイル）に次の1行を入れて再起動します。切る前に、サイトでアップロードの進み具合を表示する機能を使っていないかを確かめます。

session.upload_progress.enabled=0

修正を待つ間の緩和策と、WAFの限界

修正が適用されるまでの間にできるのは、PHP2Shellを直すことではなく、被害を受けにくくする暫定の緩和策です。

PHP公式は、すぐに更新できない環境向けに、メモリやアップロードの上限に関する設定と、ファイルのアップロードの進み具合を記録する機能を切る設定（前の見出しの1行）を案内しています。ただし、更新だけが完全な解決で、緩和策は特定の攻撃の経路を減らすだけで安全にはならないと明記しています。

あわせて、サイト全体の入口を減らす一般的な防御も効きます。管理者アカウントの棚卸し、2段階認証、自動更新の有効化、テーマやプラグインのファイル編集の禁止などです。Saixは修正版の公開前の数時間に、この種の防御を6項目点検・強化しました（実例の章）。

WAFは、攻撃の形を覚えて止める仕組みです。WAFの提供会社が今回の脆弱性向けの検知ルールを配ることもありますが、WAF各社もPHP本体の更新との併用を前提にしています。WAFは常時オンのまま、修正版の適用を優先します。

ゴール：契約先の修正が適用済み、または自社で修正版へ更新して再起動が済んでいる状態になっていればOKです

PHP2Shell対策のステップ3｜修正の反映と侵害の痕跡を確認する

修正が反映されたことの確かめ方と、サイトの動作確認

反映の根拠は、レンタルサーバーなら完了のお知らせ、自社管理なら更新したパッケージの版と再起動の記録です。

そのうえで、サイトが普通に動いているかを見ます。トップページ、会社概要、問い合わせページなど主要なページを開き、表示とフォームの送信を確かめます。記事を1本下書きで保存できるかも見ておくと安心です。

Saixは主要なページの表示と、ページのデータ量が更新前の控えと同じかを比べました。データ量が同じなら、中身が書き換えられていない目安になります。難しければ、見た目と問い合わせフォームの送信だけでも確かめます。

関連資料：「Claude Code 事故防止プロンプト集」（PDF・無料）を配布しています。

管理者・プラグイン・テーマ・ログイン履歴の点検

次に、見覚えのないものが増えていないかを見ます。侵入された場合、ここに痕跡が残ることが多いからです。見る場所は次の5つです。

画像の置き場にプログラムのファイルがあるのは、外から操作するための仕掛けを置かれたときの典型的な痕跡です。Saixではログインの通知に見慣れないものが2件あり、他のサービスのログイン通知と突き合わせて、自社の回線からの作業だと確認しました。

点検の結果は、日時と見た項目をメモに残します。次に同じことが起きたとき、何を見ればよいかの手順書になります。

痕跡を見つけたときの記録保全と相談先

知らない管理者やプラグインが見つかったら、すぐ消さずに、まず画面を保存します。削除すると原因を調べる材料が消えます。保存したうえで、管理者のパスワードを変え、不審なアカウントを無効にします。

相談先は、サーバー会社のサポート、サイトを作った制作会社、必要ならIPAの情報セキュリティ安心相談窓口です。被害の範囲が分からないときは、一人で判断せず相談先に状況を伝えます。

ゴール：主要ページとフォームが動き、管理者・プラグイン・テーマ・画像の置き場に見覚えのないものが無いと確認できていればOKです

PHP2Shell対策の実例｜自社サイトで修正・点検した範囲と結果

修正版の公開前に点検・強化した6項目

始まりは10月21日の昼、社内メンバーからの「PHPを使っている製品はあるか」という確認でした。調べると、PHPが動いているのは会社ホームページのWordPressだけでした。対象を1台に絞れたことが、その後の判断を速くしました。

修正版が公開されるまでPHP自体は直せないので、入口を減らす防御を次の6項目で点検し、足りないものはその場で設定しました。どれも一般的な防御強化で、PHP2Shellそのものを塞ぐものではありません。自社のサイトの点検表としても、そのまま使えます。

• 全プラグイン・全テーマの自動更新が有効になっているか
• 管理者アカウントに、知らない利用者がいないか
• 管理者のログインに2段階認証があるか
• 管理画面からテーマやプラグインのファイルを編集できないようになっているか
• プログラムのエラーの内容が、画面に出ない設定になっているか
• 公式配布のプラグインが、すべて最新版と一致しているか

あわせて、外から見える面も点検しました。外部から投稿を受け付ける古い仕組みが閉じていること、利用者一覧が外から取れないこと、WordPressの版が表示されていないことです。ここまでで21時過ぎでした。

関連資料：「Claude Code 事故防止プロンプト集」（PDF・無料）を配布しています。

完了を確かめた方法：お知らせを根拠にした

翌22日は、修正が入ったかを契約先の公式のお知らせで追いました。問い合わせ文も用意しましたが、送る前に完了のお知らせが出て、適用した範囲と利用者側の作業の要否が書かれていたので、問い合わせは送らずに終えました。

版番号の出方は会社ごとに違うので、最初から契約先のお知らせを根拠にすると決めて動きました。完了の知らせも、どの範囲に適用したかを書いた文言のとおりに読み、書いていないことを読み替えないようにしました。

点検した範囲と結果：侵害の痕跡は無く、被害は出ていない

完了を確かめた後、ステップ3の点検を自社サイトで行いました。点検したのは次の範囲です。

• 管理者アカウントに、知らない利用者が増えていないこと
• 公式配布のプラグインが最新版と一致し、知らないプラグインやテーマが無いこと
• 主要なページの表示と、ページのデータ量が更新前の控えと同じこと
• サーバー会社のログイン通知に、自社以外からのログインが無いこと

点検した範囲で侵害の痕跡はなく、被害は出ていません。修正版の公開前に入口を減らし、公開の翌日に修正の完了を確かめたことで、狙われやすい期間を短くできました。

取引先への注意喚起で書いたこと

修正の完了を確かめた後、取引中のお客様へ注意喚起を送りました。送る前に、修正版の番号、深刻度、サポート終了版の扱い、各社の対応状況を公式発表で照合しています。

文面に書いたのは、WordPress本体やプラグインの更新では直らないこと、レンタルサーバーなら対応完了のお知らせを確認すること、番号を変えずに修正を入れる会社があること、自社管理なら修正版へ更新して再起動することです。

加えて、見覚えのない管理者やプラグインが増えていないかの確認、2段階認証、パスワードの使い回しをやめることを添えました。送る前に全社とも二重送付の検査を通し、送った後に全件を読み戻して文面が一致することを確認しています。

PHP2Shell対策後の点検｜次の脆弱性に備えて、誰が何を見るか

対象一覧・公式情報の受け取り・月1回の点検の担当を決める

今回いちばん効いたのは、最初に「PHPが動いているのはどこか」を数えられたことでした。会社が使っているサイトやシステムの一覧を1枚持っておくと、次の脆弱性のときに対象の洗い出しが数分で終わります。

一覧には、サイト名、置いている場所（サーバー会社か自社管理か）、管理している人、使っている主要な部品（WordPress・テーマ・主要プラグイン）を書きます。版番号は変わるので、確認した日付とセットで書きます。

次に、公式の情報を受け取れる状態にします。見る先は、契約しているサーバー会社のお知らせ、IPAの重要なセキュリティ情報、PHP公式のニュースの3つです。担当者を1人決め、月1回決まった日に開き、点検の結果を同じメモに追記していきます。

点検の一部は、AIエージェント（指示を受けて自分で調べて動くAI）に任せることもできます。公式のお知らせの確認や、プラグイン一覧の照合のような決まった作業です。その場合も、判断するのは人で、AIに渡す権限は読むことだけに絞ります。

PHP2Shell対策でよくある質問

Q. PHP2Shell対策の費用は誰が負担しますか

レンタルサーバーの修正適用は、サーバー会社が行う作業です。費用の扱いは契約によるので、気になる場合は契約先のお知らせかサポートで確かめます。

自社管理のサーバーで制作会社に更新や移行を頼む場合は、保守契約に含まれるかを先に確かめます。契約外なら見積もりを取り、8.1までの版からの移行は別の作業として分けて考えます。

Q. 外部の無料診断だけで安全性を判断できますか

外から見える範囲の点検は役に立ちますが、PHP2Shellの修正が入ったかどうかは外部からは分かりません。版番号が据え置かれるサーバーもあるためです。判断の根拠はステップ1のサーバー会社のお知らせに置き、ステップ3の管理者やプラグインの棚卸しまで自分で確かめます。

Q. サイトの管理を制作会社に任せている場合、自分は何をすればいいですか

ステップ2の問い合わせ文で、修正が適用済みか、未完了なら予定はいつか、自社側でやることはあるかの3つを聞きます。答えをもらったら、ステップ3の動作確認と、管理者・プラグインの点検を制作会社と分担して進めます。

PHP2Shell対策のまとめ｜今日やることと完了条件

PHP2Shellは、WordPressの更新では直らないPHP本体の脆弱性です。レンタルサーバーなら、サーバー会社の「対応完了」のお知らせを根拠にします。版番号を変えずに修正を入れる会社があるため、管理画面の番号が古いままでも未修正とは限りません。

自社でサーバーを管理しているなら、修正版へ更新して再起動し、8.1までの版は移行を計画します。どちらの場合も、主要ページの動作、管理者・プラグイン・テーマ・画像の置き場の棚卸しまで終えて完了です。

次の脆弱性に備えて、対象一覧・公式情報の受け取り・点検の担当の3つを今日決めてください。サイトとAIの守りをまとめて見直したいときは、無料の個別相談で一緒に整理できます。