PHP2Shellとは？WordPressのPHP脆弱性と緊急対策【2026年10月】
2026年10月22日更新。PHP本体に、外部からの不正なリクエストをきっかけにサーバー上でコードを実行される恐れがある重大な脆弱性「PHP2Shell」が公表されました。WordPressを使うサイトも、サーバーでPHPが動く以上、確認が必要です。ただし、これはWordPress本体の欠陥ではありません。WordPressの更新ボタンを押すだけでは修正できず、PHPの修正版をサーバー側へ適用することが本筋です。
まずは「現在のPHP版」と「ホスティング会社の修正適用状況」を確認してください。影響の判断と更新を、以下の順に進めます。なお、本記事は2026年10月22日時点のPHP公式発表、WordPress公式案内、IPAの注意喚起に基づきます。
契約中のサーバーでどこを確認するか迷う場合は、レンタルサーバー4社別のPHP確認・更新手順も参照してください。エックスサーバー、ConoHa WING、ロリポップ！、さくらの管理画面とバックアップの確認点をまとめています。
目次
PHP2Shellとは？今回の原因とWordPressへの影響
PHP2Shellは、PHPの2件の脆弱性、CVE-2026-109618とCVE-2026-109619に関する呼び名です。前者はメモリ不足（OOM）時の例外処理、後者はリクエスト間で残った内部状態を次のリクエストが参照する問題です。条件がそろうと、認証されていない外部の攻撃者によるリモートコード実行につながります。
ただし、「すべてのWordPressサイトが同じ手順で攻撃できる」という意味ではありません。PHPの実行方式（Apacheのmod_php、PHP-FPMなど）、設定、アプリケーションの処理によって成立条件は変わります。一方、WordPressのプラグインやテーマだけを更新してもPHP本体の欠陥は直りません。サイトの土台であるPHPを修正する必要があります。
結論：サイト運営者はPHPの版を確認し、ホストの修正済みパッケージまたはPHP公式の修正版への更新を進めてください。攻撃の有無をログだけで断定せず、不審な兆候がある場合はホスティング会社・保守担当者に調査を依頼します。
2件の欠陥は、どこで発生するのか
WordPressを表示するとき、ブラウザーから届いたリクエストはWebサーバーを経てPHPへ渡されます。PHPはプログラムを実行し、記事や設定をデータベースから取り出して、HTMLを返します。今回問題になったのは、この処理の土台であるPHPの内部です。公開されたアドバイザリでは、メモリ不足の発生時に通常の後片付けが飛ばされる経路と、処理を終えたリクエストの内部状態が次のリクエストへ残る経路が説明されています。後者では、既に解放されたメモリを参照する「use-after-free」が起こり得ます。
通常、ある訪問者のリクエストが終われば、そのリクエストのために使った一時的なメモリは解放されます。しかし、長く動き続けるPHPのワーカーに古い参照が残り、次のリクエストでそれを使ってしまうと、プログラムの想定外の状態になります。攻撃者が入力と処理順序を制御できる環境では、単なるエラーにとどまらず、Webサーバーの権限で任意のコードを実行される可能性があります。これは記事の投稿権限を奪う問題とは性質が異なり、サーバー側への侵害につながり得る点が重大です。
PHP公式が特に強調しているのは、アプリケーションの通常のコードが動く前にも問題の経路へ到達し得ることです。そのため「WordPressのログイン画面を隠した」「管理者パスワードを強くした」だけでは今回の根本対策になりません。認証強化は別の攻撃への防御として有効ですが、PHPの修正パッチとは役割が違います。PHP公式のOOM処理のアドバイザリと内部状態のアドバイザリを、技術担当者が必要に応じて参照してください。
「WordPressの脆弱性」と呼ぶと、なぜ対策を誤るのか
WordPressには本体、テーマ、プラグインという更新対象があります。しかし、今回の修正対象はその下で動くPHPランタイムです。WordPress管理画面の「更新」にPHP本体のパッチが表示されるわけではありません。WordPressだけを最新版にして作業完了とすると、サーバー側の未修正状態が残る恐れがあります。逆に、今回のPHP修正を適用するためにWordPressの全プラグインを慌てて一斉更新する必要もありません。更新作業はそれぞれ別の目的と影響範囲を持ちます。
もっとも、PHP版を上げる際にはテーマやプラグインの互換性が問題になります。特に長期間保守していないテーマ、独自に改変したプラグイン、古い決済・予約の連携コードは、新しいPHPで警告やエラーを出すことがあります。ここを無視して本番環境だけ切り替えると、脆弱性は直っても問い合わせや購入の導線が止まるかもしれません。そこで、PHP修正とサイト動作確認を一つの変更作業として扱う必要があります。
ニュースの見出しに「WordPressも危険」とあっても、サイトごとの攻撃可能性はPHPの実行方式、サーバー設定、実際に到達できる処理によって異なります。脆弱性が公表された事実と、あなたのサイトが実際に侵害された事実は分けて考えてください。侵害を断定するにはログ、ファイル差分、アカウント変更、ホストの調査などの証拠が必要です。一方で、侵害が確認されていないことを理由に更新を先送りするのも危険です。
被害が起きた場合に想定する影響
リモートコード実行が成立すると、Webサーバーのワーカーに与えられた権限の範囲で、ファイルの読み書きや外部との通信が行われる可能性があります。たとえばサイトの内容改ざん、悪意あるリダイレクト、管理者用アカウントの追加、データの持ち出し、他サイトへの攻撃に使われることなどが考えられます。ただし、これは成立した場合の影響の例であり、今回公表された時点で個々のWordPressサイトにこれらが発生したと示すものではありません。
| サイトの性質 | 影響を考えるポイント | 最初の確認先 |
|---|---|---|
| 企業サイト・採用サイト | 問い合わせ情報、企業の信用、外部への不正誘導 | フォーム送信、改ざん、ホスト通知 |
| EC・予約サイト | 注文・予約の停止、顧客情報、決済連携への影響 | 注文のテスト、連携先通知、操作ログ |
| 会員サイト | ログイン機能、会員情報、認可設定 | 不審なアカウント、会員機能、アクセスログ |
| 個人ブログ | 記事改ざん、広告・検索結果の汚染 | 公開ページ、管理者一覧、ファイル差分 |
運営主体が複数のサイトを同じサーバーで管理している場合、一つのWordPressだけ確認しても不十分です。PHPの実行環境やコンテナがサイトごとに異なるか、同じホスト上で共有されているかを確かめ、影響範囲のリストを作ります。管理画面に入れない古いサイトや、閉鎖したつもりで公開されたテスト環境も対象に含めてください。
優先順位を決めるための実務判断
対応を急ぐべきなのは、外部からアクセスできる未修正のPHPを使い、個人情報や取引を扱うサイトです。ただし情報を扱わないブログでも、サーバーを踏み台にされる恐れがあるため放置はできません。まず全サイトのPHP版とホストの修正状況を一覧化し、未確認を「安全」と数えないことが重要です。次に、顧客情報や決済の有無、営業時間中に止められるか、すぐ復旧できるバックアップがあるかを整理します。
判断表の例として、修正済みとホストが明言しているサイトは公開ページの動作確認と証跡保存へ進みます。未修正でも当日更新できるサイトはバックアップと互換性確認の後に更新します。未修正で更新できないサイトは、ホストと一時的な公開制限・WAF・ネットワーク制限を相談し、期限付きの更新計画を設定します。侵害を疑う兆候があるサイトは、通常の更新作業だけで済ませず、調査と証拠保全を優先します。この四つを混同しないと、限られた時間で適切な担当者へ作業を振り分けられます。
影響するPHPバージョンと修正版
PHPプロジェクトが公表した修正版は次のとおりです。各系統で、この版より古い公式リリースは更新対象です。
| PHPの系統 | 修正版 | 確認の目安 |
|---|---|---|
| 8.2 | 8.2.35 | 8.2.34以前なら更新を確認 |
| 8.3 | 8.3.36 | 8.3.35以前なら更新を確認 |
| 8.4 | 8.4.27 | 8.4.26以前なら更新を確認 |
| 8.5 | 8.5.12 | 8.5.11以前なら更新を確認 |
PHP 8.1以前はPHPプロジェクトによるセキュリティサポートが終了しています。「表にないから安全」とは考えないでください。ホスティング会社やOSの長期サポート提供者が修正をバックポートする場合があります。その場合、画面に表示されるPHP番号だけで修正済みかどうかを断定できません。提供元の告知・適用済みパッケージ番号を確認してください。独自サーバーでサポートのない古いPHPを運用している場合は、公開停止を含む緊急のリスク低減を検討します。
版番号は「系統」と「修正番号」をセットで読む
たとえばPHP 8.4.26を使っているなら、同じ8.4系の修正版8.4.27へ更新するのが分かりやすい対処です。PHP 8.4.27以降の同系統なら、今回の2件の修正を含みます。PHP 8.3.35なら8.3.36以降、PHP 8.5.11なら8.5.12以降が目安です。「PHP 8」とだけ表示された資料では判定できません。必ず三つ目の数字まで確認してください。
ただし、ここで示す数字はPHPプロジェクトが提供する公式リリースの対応表です。レンタルサーバー、Linuxディストリビューション、商用の長期サポートサービスは、バージョン表示を大きく変えずに修正パッチだけを組み込むことがあります。例えば管理画面に8.3.35と表示されていても、ホストがCVE-2026-109618とCVE-2026-109619を修正済みの独自パッケージへ更新したと明示していれば、単純な版比較とは異なる判断になります。反対に「自動更新あり」という一般的な契約説明だけで、今回の修正適用を確認したことにはなりません。
版の照合は「現在の表示番号」「パッケージ提供元」「今回のCVEに対する修正状況」の三点で行います。外注先や複数のホストを使う企業では、サイトURLと契約プランを添えて問い合わせ、回答日時と担当窓口を記録してください。後日、別の担当者が同じ判断を再現できます。
PHP 8.1以前を使うサイトの考え方
PHP 8.1以前はPHPプロジェクトの通常のセキュリティサポートから外れています。古い系統にも影響が及ぶ可能性についてIPAが注意を促していますが、すべての古い環境についてこの表と同じ修正版番号が提供されるわけではありません。ホストやOSベンダーのサポート契約があるなら、該当する修正が提供されるか直接確認します。提供者がない独自ビルドや放置されたサーバーは、今回の件だけでなく将来の修正も受けられないため、移行計画を急ぐべきです。
「WordPressが表示されているからPHPも問題ない」という判断は成り立ちません。古いPHPでもサイトが一見動いていることと、セキュリティサポートがあることは別です。また、PHPを一度に大きく上げると、長年使ったプラグインや独自コードの互換性問題が顕在化することがあります。保守担当者は、まず現行環境を把握し、ステージングで移行先を検証し、必要なコード修正と公開切替を工程表に分けてください。移行に時間が掛かる場合は、公開範囲の制限を含む暫定策をホストと相談します。
どのPHP系統へ更新するべきか
セキュリティ修正だけを急ぐときは、現行系統に修正版があるなら、まず同じ系統内でパッチを適用できるか検討します。系統をまたぐ更新は互換性検証の範囲が広がりやすいためです。ただしPHP 8.2はPHP公式のサポート表によると2026年12月31日にサポート終了予定です。8.2.35へ更新したら永続的に安心ということではありません。WordPress本体と利用中のテーマ・プラグインの対応が確認できる、サポート中の新しい系統へ移る計画も立ててください。
「最新の8.5へ全サイトを即時切替」と機械的に決める必要もありません。まず利用中のWordPress版と重要なプラグインの公式対応状況を確認します。WordPress CoreのPHP互換性表は本体側の参考になりますが、それだけでは各プラグインや独自テーマの動作を保証しません。支払い、予約、会員管理など停止時の損失が大きい機能は実機で試します。更新先の選定は「今回の修正が入っている」「提供元のサポートが続く」「サイトの主要機能が動く」の三条件で決めます。
自社のサイト一覧を作るときの記入例
管理サイトが複数ある場合、情報を口頭だけで回すと漏れます。次の表を一行一サイトで埋め、未確認のものを明確に残します。外部公開していない管理画面やステージングも、インターネットから到達できるなら別行にします。
| 項目 | 記入する内容 | 判断に使う理由 |
|---|---|---|
| 対象URL・用途 | 企業サイト、EC、ステージングなど | 停止時の影響と公開範囲を把握 |
| ホスト・契約 | サーバー会社とプラン、保守窓口 | 誰がPHPを更新するかを特定 |
| PHP表示番号 | サイトヘルス、ホスト画面で見た値 | 公式リリース表との初期照合 |
| 修正状況 | 今回のCVEへの回答と確認日 | バックポートや自動更新を確認 |
| 更新・検証担当 | 作業者、承認者、実施時刻 | 責任の空白を防ぐ |
| 確認結果 | 更新後の版、テスト結果、残課題 | 完了と未完了を区別 |
特に「修正状況」の欄は、サイトヘルスの数字を写すだけで終えないでください。ホストから「適用済み」と回答があれば、その告知URLやサポート回答番号を残します。回答待ちなら「回答待ち」と書き、翌営業日など確認期限を決めます。表の空欄は調査漏れと扱うほうが、安全だと推測して先へ進むより確実です。
WordPress管理画面でPHPを確認する方法
WordPressにログインし、「ツール」→「サイトヘルス」→「情報」→「サーバー」を開くと、PHPのバージョンを確認できます。管理画面へ入れない場合は、レンタルサーバーの管理画面やホスティング会社のサポートで確認します。
確認結果をそのまま「脆弱／安全」と決めつけないことが重要です。例えば共有ホスティングでは、提供元が修正を先に適用していても、画面表示が元の系統番号に見える場合があります。次の3点をホスティング会社へ問い合わせると判断しやすくなります。
- 今回のCVE-2026-109618とCVE-2026-109619の修正は適用済みか
- 現在のサイトで使うPHP実行環境と、修正済みパッケージの番号は何か
- 未適用なら、適用予定と利用者側で必要な操作は何か
共有サーバー側で自動更新される場合もあります。逆に、自分でPHP版を切り替える契約なら、管理画面での操作が必要です。WordPress公式案内も、まずホストの通知を確かめるよう勧めています。
サイトヘルスの画面を、操作順に確認する
管理画面の左メニューから「ツール」を選び、「サイトヘルス」を開きます。上部の「情報」タブを押し、「サーバー」の項目を展開してください。「PHPバージョン」に表示された三つの数字をメモします。たとえば「8.3.35」と表示されたら、8.3系の修正版8.3.36と比較します。サイトヘルスに「PHPの更新をおすすめします」と出ていなくても、今回のCVEへの修正適用が確認できたことにはなりません。警告の有無とセキュリティパッチの状況は分けて見る必要があります。
管理者アカウントでもメニューが見えない場合は、権限が制限されている、WordPressの版が古い、またはホストや制作会社が管理画面をカスタマイズしている可能性があります。権限を無理に変更する前に、サイトの保守担当者へ確認してください。WordPress公式のサイトヘルスの説明も、この画面がPHPなどのサーバー情報を確認する入口だと案内しています。
同じ契約で複数のWordPressサイトを運用している場合、必ずサイトごとに表示を確認します。サブドメイン、別の公開ディレクトリ、検証サイトでPHPの切替設定が異なるケースがあるためです。反対に一つのPHP更新が複数サイトに同時に影響するホストもあります。「どのサイトが同じPHP設定を共有するか」は管理画面や契約情報だけでは分かりにくいので、ホストの設定単位を確認します。
レンタルサーバーの管理画面で追加確認する
PHPの版を切り替える場所は、WordPressではなくホスティングの管理画面です。会社によって「PHP設定」「PHPバージョン切替」「Webサイト設定」「アプリケーション設定」など名称が違います。現在値だけでなく、切替可能な候補、ドメインごとの適用範囲、反映までの時間、元へ戻せる条件も確認します。管理画面に修正版がまだ表示されていない場合、無理に未検証の別系統へ上げる前に、ホストがバックポートを配布する予定か問い合わせます。
マネージドWordPressでは、利用者にPHPの切替権限がないこともあります。その場合の作業者はホスティング会社です。「自動更新だから何もしなくてよい」と推測せず、今回の二つのCVEについて適用済みか、適用予定ならいつかを確認します。ホストから「WAFで対応」とだけ返ってきた場合は、PHPの修正が適用されたのか、攻撃を遮断する暫定策なのかを分けて質問してください。WordPress公式はWAFをパッチの代わりとみなしていません。
自社サーバーやVPSでの確認は担当者が行う
自社サーバーの場合、コマンドラインの php -v で確認できるのは、そのシェルで使うCLI版のPHPです。Webリクエストを処理するPHP-FPMやApache組み込み版と、必ずしも同じ実行ファイル・同じパッケージではありません。CLIの数字だけを見てサイトの実行環境を断定しないでください。サーバー管理者はWebサーバー設定、PHP-FPMのプールやサービス、OSのパッケージ履歴を照合します。コンテナ運用なら実際に稼働するイメージのタグとダイジェスト、デプロイ後のコンテナを確認します。
インターネットへ phpinfo() の画面を公開して確認する方法は勧めません。設定やパスが外部に見える恐れがあります。必要な診断は管理者だけが見られる環境で行い、作業後は診断用ファイルを残さないでください。アクセス権限がない編集担当者はサーバーコマンドを試さず、保守担当者へ確認を依頼します。
クラウドやコンテナでは、構築手順の設定ファイルを更新しただけで、実際の稼働環境が切り替わっていないことがあります。デプロイ後に新しいインスタンス・コンテナで起動しているか、古いワーカーが残っていないかまで確認します。ロードバランサー配下に複数台ある場合は、全台で修正の適用状況をそろえます。一台だけ未修正のままだと、サイトが正常に見えてもその台へ届くリクエストは保護されません。
ホスティング会社に送る確認文の例
問い合わせの目的は、単に「大丈夫ですか」と聞くことではありません。サイトURL、使用中のPHP表示番号、二つのCVE、必要な回答項目を一度に伝えます。次の文を契約内容に合わせて使ってください。パスワードや認証コードはメールや問い合わせ欄へ書かないでください。
当社のWordPressサイト（対象URL：○○）について、2026年10月公表のPHP2Shell（CVE-2026-109618、CVE-2026-109619）への対応状況を確認したいです。現在のPHP表示番号は○○です。貴社環境では当該2件の修正を適用済みでしょうか。バックポートの場合は、修正済みパッケージまたは告知の確認先を教えてください。未適用の場合、適用予定日、利用者側で必要な操作、暫定的なアクセス制限の選択肢を教えてください。
回答に「対応済み」とだけ書かれている場合は、対象のCVEが両方含まれるか、どのサイト・プランに適用されたかを確認します。回答を保存し、後日PHP版が変わったときも照合できるようにします。問い合わせ中で返答が来ない場合は、放置せず公開範囲と代替策を保守担当者と判断します。
確認結果の受け取り方と次の行動
| 確認結果 | 次にすること | 完了の証拠 |
|---|---|---|
| 公式修正版が適用済み | 公開ページと主要機能を点検する | 対象サイトのPHP版、点検日時 |
| ホストがバックポート済み | 対象CVEとサイト範囲を照合する | ホストの告知または回答 |
| 未修正で更新可能 | バックアップと互換性確認後に更新 | 更新後の版と機能テスト結果 |
| 未修正で更新不可 | ホストと制限策・停止を協議する | 責任者、期限、暫定策の記録 |
| 状態不明 | ホスト・保守会社へ再確認する | 回答が来るまで未完了として管理 |
特に「状態不明」を「とりあえず問題なし」に置き換えないでください。今回の問題はPHP内部で起こるため、サイトが普段どおり表示されていてもパッチ適用の証拠にはなりません。また、検証用サイトが外部公開されているなら、公開サイトと同じ緊急度で確認します。検証環境は更新が後回しになりやすく、古いプラグインが残っている場合もあります。
WordPressサイトを壊さずPHPを更新する具体的な手順
- バックアップを取る。データベースとファイル（特に
wp-content）の両方を保存し、復元手順と保存先を確認します。重要なサイトはステージング環境を用意します。WordPressのサイト移行手順でも、ファイルとDBの扱いを確認できます。 - 互換性を確かめる。WordPress本体、テーマ、重要なプラグインの対応PHP版を提供元の情報で確かめます。ステージング環境で新しいPHPへ切り替え、ログイン、投稿編集、問い合わせフォーム、決済・予約など業務に直結する画面を試します。
- サーバー側でPHPを修正版へ更新する。レンタルサーバーのPHP切替画面、マネージドホストのサポート、またはサーバー管理者に依頼します。WordPress管理画面の「更新」から行う作業ではありません。独自サーバーでは、OSベンダーの修正済みパッケージを含め、運用環境に合う更新を選びます。
- 公開サイトを検証する。トップページだけでなく、管理画面、記事、フォーム送信、メール通知、会員・EC機能、画像表示を確かめます。PHPエラーログとサーバーログも確認し、異常があれば事前のバックアップと切り戻し計画に従って対応します。
PHPの更新に伴ってテーマやプラグインが動かなくなった場合も、修正のないPHPに漫然と戻し続けないでください。互換性のないコンポーネントの更新・交換、保守担当者への相談を並行して進めます。更新後も、不審なファイルや管理者アカウント、予期せぬリダイレクトがないか確認します。パッチ適用は既に起きた侵害を自動で取り消すものではありません。
作業前に「誰が、どこを、いつ変更するか」を決める
更新はクリック一回に見えても、サイトの公開に関わる変更作業です。作業担当者はホストの管理画面を操作する人、確認担当者は問い合わせ・注文などの主要機能を試す人、承認者は一時停止や切り戻しを判断する人です。一人で兼ねる場合でも役割を明記します。対象は本番サイトだけか、同じPHP設定を共有する別ドメインにも及ぶかを事前に確認してください。繁忙時間帯のECや予約サイトなら、影響の少ない時間を選び、必要に応じて関係者へ短いメンテナンス告知を出します。
実施前の記録には、現在のPHP版、WordPress版、重要プラグイン、ホストのプラン、バックアップの保存先、切り戻し方法、連絡先を含めます。更新後に障害が出たとき「変更前は何だったか」を調べ始めると復旧が遅れます。期限を決め、たとえば公開後30分以内に管理画面とフォームの確認が終わらない場合は、担当者が切り戻しを検討する、という完了条件も設けます。これは万能な固定時間ではなく、自社の運用に合わせて決める判断基準です。
バックアップは「取った」だけでなく、戻せることを確認する
WordPressでは記事・設定・ユーザーなどの情報がデータベースにあり、テーマ・プラグイン・アップロード画像などは主にファイル側にあります。片方だけ保存しても、完全に元へ戻せないことがあります。WordPress公式のバックアップガイドに沿い、DBとファイルを同じ時点のセットとして保存してください。自動バックアップがある場合も、最後に成功した日時と復元可能な範囲を確かめます。バックアップの一覧画面を見ただけでは復元テストを済ませたことになりません。
ECや会員サイトでは、バックアップ取得後にも注文や登録が増えます。古いDBへ丸ごと戻すと、その間の注文や会員情報が消える可能性があります。切り戻すなら、どのデータを戻し、どのデータを保全するかを事前に決めます。更新作業中の新規注文を一時的に止める運用も選択肢です。バックアップをWeb公開ディレクトリへ置いたままにせず、アクセスを制限した安全な保存先へ移します。
少なくとも、保存されたファイルが存在し、サイズが極端に小さくないこと、DBのエクスポートが失敗していないことを確認します。可能ならステージングへ復元し、記事、画像、ログイン、重要機能が再現されるところまで試します。復元できないバックアップは障害時の保険になりません。外部の保守会社に依頼する場合も「DB・ファイル両方の保存」「復元手順」「復元に掛かる目安」を成果物として受け取ります。
互換性テストは、見た目より業務の導線を優先する
PHPを更新してトップページが開いても、運用が正常とは限りません。管理画面の投稿保存、画像アップロード、問い合わせメール、決済の折り返し通知、予約の確定処理など、PHPの処理を使う場所が止まることがあります。ステージング環境を本番と同じテーマ・プラグイン構成にし、対象PHP版で一連の操作を試します。テスト用注文やフォーム送信を使うときは、実在顧客へのメールや課金が発生しない設定か確認してください。
| 確認する機能 | 具体的な操作 | 正常の基準 |
|---|---|---|
| 公開表示 | トップ、記事、検索、スマートフォン表示を開く | 500エラー、白画面、主要な崩れがない |
| 管理機能 | ログイン、投稿の下書き保存、画像アップロード | 保存でき、権限エラーが出ない |
| 問い合わせ | テスト送信し、管理者宛・自動返信を確認 | 画面表示、保存、メール受信が一致 |
| EC・予約 | テスト注文・予約から通知まで通す | 重複処理や欠落がなく、連携先も正常 |
| 会員機能 | ログイン、登録、パスワード再設定を試す | 認証とメールが正常に動く |
| 運用処理 | 定期実行、外部API連携、バッチを確認 | 予定した処理が完了し、ログに異常がない |
すべてのサイトでこの表を同じように使う必要はありません。実際に使っている機能に絞って「入力」「期待する結果」「確認した人」を記録します。たとえば問い合わせフォームなら、空欄時のエラー、送信成功画面、管理者への通知、本文の保存まで確認します。「フォームが表示された」だけでは完了ではありません。PHPを切り替えることで拡張モジュールやライブラリの版も変わるホストでは、画像処理やメール送信の実動作が特に重要です。
契約形態ごとの更新方法を取り違えない
共有レンタルサーバー：ホストの管理画面でドメイン単位または契約単位のPHP版を切り替えることが多いです。画面で適用先を確認し、修正版へ変更します。設定反映までの時間や、古いワーカーの再起動をホストに確認します。ホストが自動適用しているなら、利用者が重複して切替操作をする必要はありませんが、適用済みの根拠は保存してください。
マネージドWordPress：ホストが更新を管理します。利用者側に版の選択肢がない場合、保守窓口へ今回のCVEを示して確認し、適用後の機能テストを自社で担当します。「ホストの作業」と「サイト運営者の確認」は別です。制作会社が保守を担当しているなら、双方の役割と報告の期限を決めます。
VPS・専用サーバー：管理者がOSベンダーの修正済みパッケージを確認して更新します。Webで使うPHP-FPMやApacheモジュール、関連サービスの再起動まで作業に含めます。サーバーを複数台使うなら全台の適用とヘルスチェックを行います。単にソースを配置したり、パッケージをダウンロードしたりしただけでは稼働中のプロセスが更新されたことになりません。
コンテナ・クラウド：修正済みのベースイメージやランタイムを採用してビルドし直し、全ての稼働インスタンスを置き換えます。デプロイ後、古いコンテナが残っていないか、スケーリングで旧イメージが再起動しないかを確認します。CI/CDの設定ファイルだけを変更しても、現在のサイトが変わったとは限りません。
本番更新後の受け入れテストと切り戻し
更新後は「バージョンが変わった」「画面が開いた」の二段階で止めず、ステージングで実施した主要機能テストを本番でも再実施します。画像配信やキャッシュの影響で一見成功しているように見えるため、フォーム送信や管理画面の保存など動的な処理を含めます。PHPエラーログで新しい致命的エラーや繰り返す警告がないか、ホストの稼働監視で5xxが増えていないか確認してください。テスト結果は時刻と担当者を記録します。
障害が出た場合、まずサイトへの影響を抑え、変更点とログから原因を切り分けます。古いPHPへ戻すと今回の脆弱性が再び残る可能性があるため、安易な恒久対応にしないでください。どうしても一時的に戻すなら、公開制限などのリスク低減策、復旧期限、互換性を直す担当者を決めます。停止できる機能だけ一時停止し、他のページは修正版PHPのまま運用できないかも検討します。切り戻しでDBを復元する場合は、更新後に入った注文・問い合わせデータを失わないよう個別に確認します。
完了と判定できるのは、対象サイトのPHPが修正済みである証拠があり、主要な業務機能が動き、エラーログに新たな重大障害がなく、関係者へ結果を共有したときです。ホストがバックポートした場合は適用済みの回答を証拠にします。「後で確認する」と残ったものは、担当者と期限を付けた未完了項目として管理します。
すぐ更新できない場合の暫定対応とよくある疑問
更新できない事情がある場合は、ホスティング会社に修正の適用予定と一時的なアクセス制限を相談してください。リスクが高く、適切な制限を掛けられない環境では、公開停止も選択肢です。WAFや通信制限は被害を抑える補助策であり、PHPの修正パッチの代わりにはなりません。PHP公式も、設定変更だけで全経路を守る一般的な方法はないとしています。
暫定策は「残る危険」と「終了日」をセットで決める
古いテーマやプラグインのためPHP版を切り替えられない場合、まずホストに修正のバックポートが可能かを聞きます。次に、対象サイトを公開し続ける必要があるかを判断します。社内向け管理サイトならVPNや許可済みIPからだけアクセスさせる方法があります。一般公開が必要でも、使っていない検証サイト、古いサブドメイン、閉鎖予定のフォームは先に停止できます。アクセス制限の実装と効果判定はサーバー構成で異なるため、ホストまたは保守担当者へ依頼してください。
WAFを有効にする、リクエストサイズを制限する、不要な公開経路を減らすといった対策はリスクを下げる可能性があります。ただしPHP公式アドバイザリは、設定で確認済みの攻撃経路を一部塞いでも、他の経路まで完全に防げるとはしていません。WAFの「検知した攻撃がゼロ」という表示も、安全の証明にはなりません。暫定策を採ったら、対象URL、設定内容、設定者、開始時刻、残るリスク、PHP修正の予定日を一枚の記録にまとめます。期限のない暫定策は、そのまま放置されやすいからです。
サイトが単なる告知ページで、更新まで一時停止しても事業上の影響が小さいなら、公開停止が最も分かりやすい選択肢になる場合があります。一方、ECや会員サービスを急に止めれば利用者に損害が生じることもあります。技術担当だけで決めず、事業責任者と停止時の影響を比較します。停止する場合も、WebサーバーがPHPへリクエストを渡さない構成であることを担当者が確認し、告知用の静的ページなどを使います。見た目だけメンテナンス表示に変えて、裏で同じPHP処理を実行していたら目的を達成できません。
「攻撃されたかもしれない」ときは通常の更新作業と分ける
見覚えのない管理者アカウント、勝手な記事の追加、検索結果からの不審な転送、サーバーに置いた覚えのないPHPファイル、メールの大量送信、ホストからの侵害通知などがあれば、単なる更新作業では終えられません。まず関係者に連絡し、必要なログやファイルの状態を保存します。証拠を消してしまう恐れがあるため、理由が分からないまま全ファイルを削除したり、バックアップへ即座に丸ごと戻したりしないでください。サイトが他者に被害を広げる恐れがある場合は、ホストと公開制限・隔離を協議します。
調査では、どのURLがいつ影響を受けたか、管理者アカウントやプラグインが変わっていないか、WordPress以外のファイルが書き換えられていないかを確認します。アクセスログ、PHPエラーログ、Webサーバーログ、ホストの監視通知は有用ですが、ログに記録がないことだけで攻撃がなかったとは言えません。PHP公式アドバイザリも、問題の経路は通常のログに分かりやすい痕跡を残すとは限らないと説明しています。顧客情報を扱うサイトは、データへのアクセス可能性、契約上の報告義務、関係法令に応じた連絡を専門家と検討します。
侵害が確認された場合、PHPを更新することは再侵入防止の一部です。しかし、既に置かれた不正なファイルや追加されたアカウントを消す作業、信用できるバックアップからの再構築、必要な認証情報の変更、外部連携の確認は別に必要です。侵害された可能性のある環境から取得したバックアップを、そのまま「安全な復元元」と決めつけないでください。WordPress公式の侵害対応ガイドも、状況の記録と計画的な復旧を案内しています。
今日中に終えるための時系列チェックリスト
最初の30分：対象サイトと担当者を決めます。WordPressのサイトヘルスまたはホスト管理画面でPHP版を確認し、公開URL、ホスト、修正状況を記録します。ホストの告知で今回の二つのCVEの扱いを確認し、不明なら問い合わせます。侵害の兆候がある場合は更新とは別に調査担当者へ共有します。
次の1〜2時間：未修正で更新可能なサイトのDBとファイルをバックアップします。重要なテーマ・プラグインのPHP対応を確認し、可能ならステージングで動作テストをします。問い合わせや注文などの主要導線と担当者を決め、切り戻し条件を記録します。複数のサイトで同じホストを使う場合は、共通設定の変更範囲を確認します。
更新後：修正版の適用を確かめ、公開サイトの主要機能を試します。画像や記事だけでなく、フォーム送信、通知メール、管理画面の保存などを確認します。ログに新たな致命的エラーがないか見て、結果を関係者へ共有します。更新できなかったサイトは、暫定策と次の確認時刻を明記します。すべてを当日完了できない場合も、未確認と未修正を可視化することが大切です。
| 状態 | 責任者が決めること | 終了条件 |
|---|---|---|
| 修正済み | 主要機能を誰が検査するか | 修正の証拠とテスト記録がある |
| 未修正・更新可能 | 更新時刻、バックアップ、切り戻し | 修正版適用と本番テストが終わる |
| 未修正・更新不可 | 暫定制限、停止可否、期限 | 修正版へ移行するまで管理を続ける |
| 侵害の疑い | 証拠保全、隔離、専門家への連絡 | 原因調査と安全な復旧が完了する |
状況別の具体例：三つのサイトで判断を変える
例1・一般的な企業サイト：サイトヘルスにはPHP 8.4.26と表示されています。ホストの告知は未確認、問い合わせフォームを運用中です。まずホストに今回のCVEの修正状況を確認します。未修正で8.4.27へ切替可能なら、DBとファイルのバックアップを取得し、フォームを含むテスト後に切り替えます。ホストがバックポート済みと回答したら、その根拠を残し、フォームの動作を確認します。表示番号だけでどちらかを決めないのが要点です。
例2・長年運用したECサイト：PHP 8.1で古い決済プラグインを使っており、現時点で新しいPHPへ切り替えると注文が止まります。ホストの長期サポートに今回の修正があるか確認し、なければ事業責任者と公開制限・決済停止などを検討します。同時にプラグイン提供元へ対応版を確認し、ステージングで移行を試します。「数週間後に考える」ではなく、更新期限と担当者を決めます。
例3・複数サイトを持つ制作会社：同じサーバー内に企業サイト、採用サイト、検証サイトがあります。PHPを一契約単位で切り替える構成なら、三つ全てで互換性を確認する必要があります。検証サイトだけ古いPHP設定が残る構成なら、そのURLも対象に入れます。クライアントには修正適用の有無だけでなく、対象サイト、完了時刻、主要機能のテスト結果を個別に報告します。これらは架空の例であり、実際のホスト設定に合わせて判断してください。
よくある質問と、判断を間違えやすい点
Q. WordPress本体を最新版にすれば解決しますか？
いいえ。今回の欠陥はPHP本体にあります。WordPress本体を安全な状態に保つことは大切ですが、今回の根本対策はPHP側の修正です。
Q. PHP番号が表の修正版より古いと、必ず未修正ですか？
いいえ。OSやホストが修正をバックポートすることがあります。提供元にCVE番号を示し、実際の適用状況を確認してください。
Q. 更新後に画面が白くなったら？
まずエラーログを確認し、テーマ・プラグインの互換性を切り分けます。業務影響が大きい場合は切り戻し計画に従い復旧し、保守担当者と安全な更新方法を決めてください。
Q. セキュリティプラグインを入れればPHP更新は不要ですか？
不要にはなりません。プラグインはWordPress上の操作や通信を監視・制限できますが、PHP内部のメモリ処理を修正するものではありません。PHPの欠陥はWordPressの通常の処理が始まる前に関わる可能性もあります。プラグインは別の脅威への補助策として考え、今回の修正はサーバー側で実施します。
Q. WAFが攻撃を遮断すると通知したら、もう安全ですか？
WAFが一部の不正な通信を防ぐことはあります。しかし、すべての攻撃経路を把握し、常に遮断できる保証にはなりません。PHP公式は修正版への更新を唯一の信頼できる根本対策としています。ホストがWAFだけを案内する場合は、パッチ適用予定も合わせて確認してください。
Q. 公開サイトが正常なら更新を後回しにできますか？
できません。脆弱性は、通常の閲覧では分からない場合があります。エラー表示がないことやサイトヘルスに赤い警告がないことは、今回の修正適用を証明しません。更新を実施できない事情があれば、ホストへ修正状況を確認し、アクセス制限などの暫定策と期限を決めます。
Q. PHP版を上げるとWordPressのSEOが下がりますか？
PHPの版を変更したこと自体で検索順位が下がると決めつける根拠はありません。ただし更新後にページが500エラーになったり、表示内容が欠けたり、サイトが長時間停止したりすれば、利用者や検索エンジンへの影響があります。公開ページと重要な導線をテストし、障害を早く直すことが重要です。順位変動を今回の修正だけに帰属させず、Search Consoleやサーバーログで原因を分けて確認してください。
Q. WordPress.comや完全管理型のサービスでは何をしますか？
利用者がサーバーのPHPを直接切り替えられない契約では、提供事業者が更新を担当することがあります。サービス名だけで安全を断定せず、今回のCVEへの対応告知と、自分の契約プラン・サイトへの適用を確認してください。利用者側は、更新後にフォームや独自機能が正常かを確認します。
Q. PHPを更新した時点で、侵害されていないと判断できますか？
判断できません。更新は今後の攻撃経路を塞ぐための作業であり、過去のアクセスや既に置かれた不正なファイルを消すものではありません。侵害の兆候があれば別途調査します。ログに不審な記録が見つからない場合も、それだけで安全を証明するものではありません。
Q. どのCVE番号をホストへ伝えればよいですか？
CVE-2026-109618とCVE-2026-109619の両方です。通称の「PHP2Shell」だけではホストの告知やパッケージ情報で照合しにくい場合があります。二つの番号を明記し、修正済みか、バックポートならどのパッケージで適用したか尋ねてください。
今後のために残す運用記録
今回の対応を終えたら、次の脆弱性でも同じ混乱を繰り返さないよう記録を残します。最低限、管理サイト一覧、PHP版と提供元、ホスト連絡先、バックアップの保存先と復元担当者、テーマ・プラグインの保守担当者、変更時のテスト項目を一か所で管理します。担当者が退職したときにも引き継げるよう、個人のメモだけに置かないことが大切です。ただし管理表へログインIDやパスワード、秘密鍵を書き込まないでください。
定期的な確認では、PHPのサポート終了日とホストの提供予定を見直します。今回8.2系で修正したサイトは、2026年12月末のPHP公式サポート終了を見据え、より新しいサポート中の系統へ移る時期を決めます。月ごとに、PHP・WordPress本体・テーマ・プラグインの更新状況を確認し、更新できないものには代替や撤去の判断を付けます。古いプラグインを「動いているから」と放置すると、次回もPHPを上げられない原因になります。
監視は「サイトが開くか」だけでなく、主要機能の実行とログの変化を見ることが有効です。フォームのテスト送信、注文のテスト、管理画面の保存などを、業務に合う周期で行います。設定変更時には更新前後のエラー率を比べます。監視の通知先が退職者のメールのままになっていないかも確認してください。技術的に正しいパッチを適用しても、異常が誰にも届かなければ復旧が遅れます。
外部制作会社へ運用を任せる場合は、「PHPの更新を誰が判断するか」「ホストへの問い合わせは誰がするか」「重大脆弱性が出たとき何時間以内に連絡するか」「緊急停止を誰が承認するか」を契約や運用手順で明確にしておくと動きやすくなります。サイト制作時の納品だけでなく、保守の責任範囲と期限が決まっているかを確認してください。今回のようにWordPress本体ではなく基盤に問題が出ると、担当の境界が曖昧なまま対応が遅れがちです。
公開後の1週間は、更新結果を追跡する
更新直後の点検を通過しても、毎日動くバッチや週に一度だけ使う機能の問題はすぐに見つからないことがあります。更新後の数日は、PHPエラー、500系の応答、フォームの失敗、注文・予約の途中離脱がいつもより増えていないかを見ます。具体的には更新前と更新後の同じ曜日・時間帯で比較し、アクセス数の違いも考慮します。アクセスが急増したニュース直後なら、単なる件数だけでなくエラー率も見てください。
公開した記事や画像が消えていないかだけでなく、検索・ログイン・パスワード再設定・管理者への通知も順に確認します。キャッシュによって古いページが表示されるサイトでは、キャッシュを更新し、シークレットウィンドウや別端末でも主要ページを開きます。サイトマップやRSS、API連携を使うサイトなら、機械的に取得する側の処理も点検します。外部サービスから届く通知が一時的に遅れる場合もあるため、事業側の記録と照合します。
利用者から「問い合わせを送ったのに返信がない」と報告された場合、PHP更新との因果関係を決めつけず、フォームの送信記録、メール配送状況、スパム判定、ホストのエラーログを確認します。原因がPHPの互換性ならテーマやプラグインの修正を手配し、別の障害ならその担当者へ引き継ぎます。更新作業を完了扱いにする条件は、技術担当だけでなく実際にサイトを使う部署とも共有してください。
情報が更新されたとき、記事や社内手順をどう直すか
脆弱性の公表直後は、攻撃の成立条件や各ホストの適用状況に追加情報が出ることがあります。SNS上の「これを入れれば防げる」「全WordPressが侵害済み」といった断定を、そのまま社内の判断材料にしないでください。まずPHPプロジェクト、WordPress、IPA、契約するホストの告知を確認します。公表された事実、専門家の推測、自社サイトの調査結果を分けて記録します。更新情報が出たら確認日を追記し、古い指示を残さないよう運用メモも直します。
技術担当者がPHP公式アドバイザリにある一時的な設定変更を読む場合も、適用範囲と副作用を理解する必要があります。例えば特定の機能を無効にする対策は、確認済みの一つの攻撃経路を減らすもので、全ての経路を塞ぐとは書かれていません。メモリ制限の変更もサービスの安定性に影響し得ます。一般のWordPress運営者が記事の一行だけを見て php.ini を変更することは避け、サーバー管理者に判断を任せてください。根本対策は修正済みPHPの適用です。
このページの版番号と手順は2026年10月22日に確認した情報です。後日読む人は、ホストの現在の修正状況とPHP公式の更新情報を改めて確認してください。脆弱性への対応は一回のニュース記事を読むことでは終わりません。「対象かを確かめる」「修正する」「動くことを確認する」「結果を記録する」までを一つの作業として扱うと、次の緊急更新にも対応しやすくなります。
社内・クライアントへ伝える報告例
報告では「対応しました」の一言だけで終えず、事実と未確認事項を分けます。たとえば「対象の企業サイトと採用サイトでPHP版を確認。ホストからCVE-2026-109618とCVE-2026-109619の修正適用済みとの回答を受領。10月22日に両サイトの公開表示、管理画面、問い合わせ送信を確認し、異常なし。検証サイトは確認中で、明日までに結果を共有」と書けば、対象範囲と残作業が分かります。実際に確認していない項目まで「異常なし」と書かないでください。
更新を自分たちで実施した場合は、更新前後のPHP版、変更時刻、作業者、テストした機能、エラーの有無、切り戻しを行ったかも添えます。ホストのバックポートで版番号が変わらなかった場合は、その旨とホストの告知・回答を記載します。侵害の兆候を調査していないなら「侵害なし」とは報告せず、「今回の作業では修正適用と動作確認を実施。侵害調査は別途」と書き分けます。責任者が次の判断をできる報告が、長い技術説明より役立ちます。
顧客に向けて説明が必要なサイトでは、利用者に直接関係する事実だけを正確に伝えます。脆弱性が発表されたこと、修正の適用状況、サービスへの影響、問い合わせ先を整理し、確認できない被害を断定しないでください。個人情報の流出が疑われる場合は通常の更新完了報告とは分け、調査担当者と法務・契約担当者の確認を経て連絡します。公表の速さと事実の正確さを両立させることが大切です。
目的別の詳しい手順
状況に合わせ、必要な手順から確認してください。いずれもPHP公式・WordPress公式の発表を踏まえ、対象サイトのホスト情報と合わせて判断します。
- 自サイトが対象か、PHP版とホストの修正状況を確かめる
- WordPressのPHPをバックアップから動作確認まで安全に更新する
- PHPをすぐ更新できない場合の暫定対策と公開判断
- 侵害を疑う場合の封じ込め・証拠保全・復旧
要点：「PHP版の確認 → ホストの修正状況の確認 → バックアップと互換性テスト → 修正版への更新 → 公開サイトの動作確認」の順に動いてください。
最初の判断で迷ったら、サイトヘルスに表示された番号を控え、ホストへ二つのCVE番号を示して適用状況を聞くことから始めてください。運営者自身にサーバー管理の権限がなくても、この確認と主要機能のテストは進められます。ホストが修正済みと答えた場合は回答を保存し、未修正なら更新可能な版と予定日を決めます。更新不可なら暫定策と公開停止の可否を判断します。侵害を疑う兆候があれば通常のアップデート作業とは別の調査へ切り替えます。「見た目が正常」「WAFがある」「WordPressは最新版」という理由だけで完了扱いにしないことが、今回の対応で最も重要です。
参考資料（2026年10月22日確認）：PHP公式セキュリティリリース／WordPress.org日本語版／IPA／PHP公式アドバイザリ1／PHP公式アドバイザリ2
AIスキルで、未来の自分をアップデート！
今なら完全無料でAIを学べる！
WithAIには、目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースがあります。動画や実践を通して、スマホ・PCから自分のペースで学べます。WithAIはPHP2Shellの修正や緊急対応の窓口ではありません。サイトの安全確認は契約ホストと保守担当へ依頼し、AIスキルも身につけたい方はWithAIの無料学習案内をご覧ください。
