PHP2Shellへの対応｜WordPress・業務システムのPHP更新確認表

1. 今回の問題と修正版を確認する

今回扱うのは、PHP2Shellと呼ばれるCVE-2026-109618とCVE-2026-109619です。PHP公式は、認証されていない相手によるリモートコード実行につながり得る重大な脆弱性として、2026年10月21日に修正版を公表しました。案内された修正版は8.5.12、8.4.27、8.3.36、8.2.35です。これは公開時点の修正版一覧であり、今後もこの番号だけを固定して使うという意味ではありません。[1]

公式は、Webリクエストを処理するPHP環境をリスクの対象に挙げ、特にApacheのmod_phpを高リスクとしています。PHP-FPMなら無条件に対象外、ログイン画面があるから安全、とは判断しないでください。WordPress固有の不具合としてではなく、Webサイトや業務システムを動かす実行基盤の問題として確認します。[1]

以下の確認表や業務テストは、本稿が提案する運用手順です。個別のサイトで侵害が起きたことを示すものではありません。ニュースの公開時刻、修正版の公開時刻、自社環境への適用時刻を別に記録すると、『パッチは出たが自分たちのサーバーにはまだ入っていない』状態を見落としにくくなります。

2. まず保守会社と埋める影響確認表

最初に、サイト名やURLと管理する会社を一対一で結び付けます。例えば企業サイト、採用サイト、会員向け画面、問い合わせフォームが別々の契約なら、一つの回答で全体を対処済みにしません。フォームだけ外部サービスという場合も、対象の切り分けを残します。担当者が分からないサイトは『対象外』ではなく『確認先未定』として一覧に入れます。

WordPressでは管理画面の『ツール→サイトヘルス→情報→サーバー』からPHPバージョンを確認できます。ただし今回の対応は、一般的な推奨メジャーバージョンの条件だけで判定せず、PHPの個別告知と提供元の修正情報で判断してください。PHPの切替や更新方法はホスティング環境によって異なるため、管理会社の回答と合わせて記録します。[2]

保守会社には『更新できますか』だけでなく、『このサイトで動くPHPに、今回の二つのCVEの修正が適用されているか。根拠となる告知やパッケージ情報は何か』と質問します。回答がサーバー全体の説明なのか、対象サイトまで確認した結果なのかを区別します。返答待ちの間も、確認予定時刻と連絡先を決めておけば、誰かが対応しているはずという空白を減らせます。

3. PHP更新とWordPress更新を分けて準備する

PHPはサーバー上で動き、WordPress本体、テーマ、プラグインはその上で動く構成です。WordPress公式も、PHPとこれらを継続して更新すること、バックアップと互換性確認を行うことを案内しています。管理画面の更新件数がゼロでも、サーバー側のPHPの修正適用を確認したことにはなりません。[2]

作業前には、データベース、アップロードファイル、設定、アプリケーションの復元に必要なものを担当者に確認します。保存場所、取得時刻、復元権限を記録し、バックアップファイルがあるだけで復旧できると決めつけないことが大切です。個人情報を含むデータを検証に使う場合は、持ち出し先と閲覧者を限定し、必要に応じて匿名化したデータで代替します。

緊急対応である一方、目的の異なる変更を一度に増やすと、不具合の切り分けが難しくなります。担当者には今回の修正を適用する方法と、そのために必要な互換性対応を整理してもらいます。デザイン変更や新機能追加は別の作業に分け、確認に必要な時間、サービスを止める判断、問題が出た場合の連絡先を先に決めます。

• 復元対象と保存場所を確認し、個人情報へのアクセスを制限する
• 更新する範囲と実施担当、作業中の代替受付を決める
• 更新前の正常な操作結果を控え、更新後と比較できるようにする

4. 古いPHPや更新待ちの環境を取り残さない

PHP公式によると、8.1以前は通常のサポート対象外です。一部の配布元には修正を取り込んだ提供があり、今回に限る古い系列向けの最小限のソース修正も案内されています。しかし、それを古いPHPの通常サポート再開と解釈しないでください。提供元に今回の修正と今後の保守方針をそれぞれ確認します。[1]

そのため、画面に表示された番号が古いという理由だけで未対処と断定することも、保守契約があるという理由だけで対処済みとすることも避けます。例えば事業者独自のパッケージなら、対象CVEの修正を含むという告知と、そのパッケージが実環境に適用された記録を組み合わせます。回答が曖昧な場合は、『確認中』のまま期限を決めて追跡します。

コンテナを使うシステムでも、配布元に新しいイメージがあることと、稼働中の環境が切り替わったことは分けて扱うのが実務上のポイントです。保守担当に更新対象の一覧と切替結果を求め、本番だけでなくインターネットからアクセスできる検証環境、使わなくなった旧サイトなど、管理表から漏れやすいものも棚卸しします。

5. すぐ更新できないときの判断を残す

PHP公式は、完全な解決は更新であり、設定による暫定措置だけでは安全にならないとしています。掲載された緩和策にも適用条件と限界があります。記事やSNSに書かれた設定値を一つだけコピーし、これで対処完了と扱わないでください。特にメモリーやリクエストの制限は、業務機能や可用性にも関わるため、構成を把握した担当者による確認が必要です。[1]

更新まで時間が必要なら、公開範囲を狭める、対象機能を一時停止する、別の受付窓口へ案内するなど、取れる選択肢を管理者に整理してもらいます。これは個別構成に応じた運用判断であり、どの制限も今回の修正そのものに置き換わるという意味ではありません。継続利用を選ぶ場合も、その理由と見直す時刻を記録します。

例えば採用応募を受け付けるサイトでは、停止による応募者の困りごとも考える必要があります。代替窓口には、必要な情報、受付終了後の扱い、担当者の確認方法を簡潔に示します。ただし緊急だからといって、履歴書などを誰でも閲覧できる共有場所へ集めないようにします。安全対策によって別の情報管理上の問題を作らないためです。

6. 更新後は『表示・保存・通知』を別々に確認する

トップページが開くだけで、全機能が動くとは限りません。本稿では実務の確認を、画面表示、入力結果の保存、通知や連携先への反映に分ける方法を提案します。問い合わせフォームなら送信完了画面だけで終わらず、テストデータが管理画面に一度だけ登録され、担当者に通知されたかを確認します。テストには識別できるダミー情報を使います。

会員サイトならログインとログアウト、権限ごとの表示、ファイル添付など、実際に利用する機能を対象にします。外部API連携や定期処理がある場合は、それらの実行結果も担当者に確認してもらいます。決済や外部への実送信を伴うテストは、テスト用環境や安全な確認方法を先に選び、本番の二重注文や不要な通知を発生させないようにします。

結果は『正常でした』の一言ではなく、対象の操作、確認日時、期待結果、実際の結果を組にして残します。試せなかった操作には未確認と書き、担当者と確認期限を付けます。もし異常が出たら、更新前の状態へ無条件に戻して公開を続けるのではなく、脆弱な状態へ戻るリスクも含めて公開制限や別の復旧方法を検討します。

7. 更新完了と、侵害の有無の確認を区別する

修正を適用できたことは、その環境で過去に不正な操作がなかったことの証明ではありません。見覚えのない管理者、身に覚えのないファイル変更、異常な外部通信などが見つかった場合は、単なる更新作業とは別に、保守・セキュリティ担当へ状況を引き継ぎます。痕跡らしきものをすぐ削除して原因が分からなくならないよう、保存と取り扱いを相談します。

経営側への報告では、修正適用、業務の動作確認、気になる兆候の確認を分けて記載すると、残っている判断が見えます。例えば『本番の修正適用済み、フォーム確認済み、夜間処理は次回実行後に確認』という報告なら、今できたことと次に必要なことが明確です。未確認を合格として扱わず、担当と次の報告時刻を決めます。

今回の対応を終えたら、サイト一覧、保守窓口、更新時の確認項目を次回も使える形で残します。古い環境を継続して使う事情がある場合は、今回の緊急修正とは別に、保守できる構成へ移る計画を立てます。毎回その場で管理会社を探す状態をなくすことが、次の脆弱性情報を受け取ったときの初動を支えます。

よくある質問

保守会社から返事がない場合、何を先に進めればよいですか？

契約書や請求情報から管理先を確認し、別の連絡経路を探します。同時に、対象URL、確認できたPHP情報、停止すると困る業務を整理します。権限や構成が分からないまま変更を試すのではなく、社内の判断者を決め、回答を待てる期限と公開制限などの判断時刻を明確にしてください。

WordPressに詳しくない担当者でも確認できますか？

管理画面に入れる場合は、サイトヘルスでPHP情報を確認し、その画面と対象URLを管理会社へ渡せます。操作権限がない場合は取得を依頼してください。管理画面のパスワードを通常のメールに貼る必要はありません。修正の適用や切替そのものは、環境を管理する担当者に任せます。

検証環境がないとき、更新をずっと見送ってよいですか？

検証環境がないことは安全を意味しません。担当者に、一時的な複製で確認できるか、限られた時間で重要機能を確認できるかを相談します。確認できる範囲と残る不確実性を整理し、バックアップ、作業時間帯、代替受付、異常時の対応を決めて、実施方法を判断します。

複数の制作会社に依頼している場合、誰が完了を判断しますか？

社内に集約担当を一人置き、各社の報告を同じ確認表に揃える方法を提案します。一社の完了報告を全サイトの完了へ広げず、サイトごとに修正適用と動作確認の結果を記録します。担当が分かれる連携機能は、受け渡し先も含めて確認し、最終的な利用再開の判断者を決めます。

参考・関連資料

• [1] PHP公式：Critical remote code execution vulnerabilities, update now（2026-10-21） ↗
• [2] WordPress公式：Get a faster, more secure website: update PHP today ↗

公式資料の確認日：2026-10-22。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。