PHP2Shellなどの脆弱性通知が来たら｜サイト担当者の確認メモと対応の分担

PHPの脆弱性通知を受けたら、対象サイト、利用するサーバー、修正の適用状況と担当者を確認してください。「対象の可能性がある」「修正を適用した」「被害の有無を調査した」は、それぞれ別の状態です。分からない項目を残したまま「安全です」と答えず、次に誰が何を確認するかを決めます。

この記事は、専門のサーバー担当者がいない企業と、顧客サイトの相談を受ける制作会社に向けた初動の案内です。更新ボタンの操作や侵害調査の技術手順ではなく、通知を読んで確認事項と作業範囲を整理するところまでを扱います。確認日は2026年10月29日です。

1．通知の発行元と対象を確認する

通知にある脆弱性名、CVE番号、公表日、対象製品とバージョン、対策の案内を確認します。CVE番号は、どの弱点について話しているかをそろえる識別子です。転送された文章やSNSの見出しだけで判断せず、開発元や利用するサービス提供元の案内へたどります。

今回のPHP2Shellについては、IPAの注意喚起がCVE-2026-109618とCVE-2026-109619を扱い、修正版への移行を案内しています。記事の閲覧日と通知の更新日を分けて記録し、追加情報が出ていないかも確認してください。

脆弱性の名称を、個別の事件や攻撃者の目的と混同しないことも大切です。「サイバーテロ対策」という広い言葉だけでは、対象と必要な作業が分かりません。通知にある製品・弱点・環境を具体化すると、確認すべき担当者へ話を渡せます。

2．PHP・WordPress・サーバーの違いを整理する

PHPは、WordPressなどのプログラムを実行するために使われる言語・実行環境です。WordPress本体、テーマ、プラグインと、サーバーで動くPHPは別に管理されることがあります。WordPress管理画面で更新したという記録だけでは、PHP側の修正適用は確認できません。

一つの更新で、すべて直ったと考えない

WordPress公式も、利用できるPHPのバージョンはホスティング会社によって決まると説明しています。PHP更新についてのWordPress公式案内は役割や更新準備の参考になりますが、一般的な推奨バージョンの説明を、今回の脆弱性への修正適用済み判定には使いません。

同じ「更新」という言葉でも、PHPの修正、WordPress本体の更新、独自コードの改修では作業する場所と担当が違います。通知への返信では、何の更新を指しているかを省略しないでください。

3．誰が修正し、誰が動作を確認するかを決める

共用サーバーでは、提供会社がPHPの修正を適用し、利用者側には動作確認や個別の切り替えが求められる場合があります。自社管理のサーバーでは、管理担当者が更新パッケージや反映方法を確認する必要があります。実際の分担は契約と提供元の案内に照らして決めます。

企業が依頼する場合は、契約先や社内の連絡担当を整理します。制作会社が顧客へ回答する場合は、顧客確認、サーバー操作、WordPress修正、公開後試験の境界をそろえます。契約外の調査や緊急対応まで、通常保守に含まれると推測しないでください。

4．修正済みの根拠と、未確認を分ける

提供元から「対応済み」と回答があったら、どの契約・サーバー・PHPの処理に適用されたかと、確認した日時を記録します。サイトが表示できた、ログインできた、バージョンの先頭が新しい、といった情報だけでは、今回の修正適用を証明できません。

バージョン番号だけで安全判定しない

PHP公式の緊急案内が10月21日に挙げた、この2件への修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12です。ただし、この一覧を現在の全脆弱性への対応済み保証には使いません。追加の告知と、利用する提供元の対応情報も確認します。

公式は、ディストリビューション等の提供元による更新パッケージの確認も案内しています。修正の取り込み方が異なる場合があるため、外部から見える番号だけで判定せず、その環境の提供元の説明と照合します。

PHPを確認する画面や実行場所が食い違う場合は、公開サイト・管理画面・コマンドのPHP表示を読み分ける方法を参照してください。確認のためだけに、詳細なサーバー情報を公開するファイルを増やす必要はありません。

今回の公式案内は、暫定策で一部の経路への露出を減らせても、更新の完全な代替にはならないとしています。WAFの有無や設定変更だけで「修正済み」とは記録しません。追加の別CVEや製品固有の注意も、同じ話としてまとめず対象を分けて読みます。

5．管理会社へ渡す確認メモを作る

最初にすべての技術情報を集める必要はありません。対象URL、サーバー契約先、受け取った通知、現在の現象から始めます。次の文面は架空の記入例で、顧客事例やAcquaの標準契約を示すものではありません。

「当社サイトについてPHPの脆弱性通知を受け取りました。対象URLは○○、契約先は○○です。当該環境への修正適用状況と確認時点、利用者側で必要な作業、作業担当をご確認ください。更新後のWordPress動作確認が必要な場合は、対象機能と進め方も相談したいです。現在確認している不審な動作はありませんが、侵害の有無を調査済みという意味ではありません。」

初回の問い合わせにパスワードや顧客データを貼る必要はありません。操作権限が必要になった段階で、依頼範囲と受け渡し方法を決めます。分からない欄には未確認と記し、推測値で埋めないでください。

6．更新と動作確認を一組で進める

更新が必要なら、実施する変更、影響する機能、バックアップ、検証方法、戻す判断を担当者と確認します。急ぐべき修正を、通常の月次作業の順番待ちとして無期限に放置しないよう、期限と業務影響も共有します。

技術作業の詳細は、対象サイトから決める

具体的な進め方はPHP更新の準備・検証・復旧判断へつなげて確認できます。利用する本体・テーマ・プラグインと独自機能によって、必要な試験は異なります。旧バージョンへ戻すことで脆弱な状態へ戻る場合もあるため、不具合時は単純に戻して通常営業へ復帰するのではなく、公開制限や別環境での修正を含めて判断します。

画面表示だけでなく、実際に使うフォーム、予約、決済、会員機能、管理画面などを試験項目にします。メールや決済を伴う試験は、送信先・内容・影響を決めてから行います。作業完了と試験合格を別々に記録し、未試験の機能も残します。

7．侵害が疑われるときは、通常更新と切り分ける

修正版を適用したことと、過去に侵害されていないことを確認したことは別です。見覚えのない転送、管理者、ファイル変更、外部からの指摘などがあれば、日時と現象を記録して管理担当へ伝えます。

安易な削除・上書きで調査材料を失わない

不審な動作があるときは、WordPress改ざんが疑われる場合の初動を参照し、保全・封じ込め・調査・復旧の担当を整理します。証拠を残すことだけで対応を止めず、被害拡大を防ぐための制限や停止の判断も、サーバー会社や専門の対応先と進めます。

「更新したので完全に安全」「バックアップを戻せば原因もなくなる」という説明はできません。復旧後に再び同じ問題を起こさないため、原因、残る入口、認証情報、他の影響範囲も必要に応じて調べます。自分で扱えない調査を、通常の更新代行として引き受けないことも大切です。

8．確認結果と次の担当を、依頼者へ返す

回答には、確認できた事実、まだ不明なこと、実施した作業、次の担当と予定を含めます。「大丈夫でした」という一言より、何を根拠にどこまで確認したかが分かる報告が役立ちます。

たとえば「提供元の回答で対象サーバーへの修正適用を確認しました。WordPress側では主要ページと問い合わせの所定の試験を確認しました。会員機能は未試験のため担当者と日程を調整します。侵害調査は今回の作業には含みません」という形です。これは架空の報告例であり、実際の作業記録を示すものではありません。

Acquaの企業向けWeb支援では、対象環境と困る状態から必要な仕事を整理します。制作会社の方はWordPress実装・保守の受託で、仕様確認、改修、試験、公開補助のうち任せる工程を確認してください。高度な侵害調査・完全駆除・常時緊急対応を、未確認のまま約束するものではありません。

相談窓口には、対象URL、通知、現在の現象、既存担当、希望する状態を分かる範囲で伝えられます。費用と対応範囲は作業前に確認します。支援後に目指すのは、修正適用と必要な動作確認の結果が分かり、未確認の範囲と次の担当が引き継げる状態です。