WordPress侵害の疑いがあるときの初動対応｜証拠保全から復旧まで

2026年10月22日確認。PHP2Shellのニュースを見て「もう侵害されたかもしれない」と感じても、画面の不具合だけで侵害を断定しないでください。一方で、管理者が覚えのないユーザー、未知のPHPファイル、不審な外部通信を見つけたなら、通常の更新作業より先に封じ込め、証拠保全、調査、復旧を進めます。まず自サイトの修正状況を調べる場合は影響確認の記事、原因と対策の全体像はPHP2Shellの緊急解説を参照してください。

インシデント対応と並行して契約先のPHP修正状況を確認する場合は、レンタルサーバー別のPHP脆弱性対応手順を参照してください。パッチの有無と侵害調査の完了は別々に判断します。

疑わしい兆候を記録し、影響を広げない

兆候として、管理者アカウントの増加、通常使わない時間帯のログイン、不明なプラグインやテーマ、書き換わったトップページ、公開ディレクトリ内の不明なPHPファイル、ホストの不審な通信・プロセス通知などがあります。これらは調査の入口であり、今回の二つのCVEが原因だと証明するものではありません。プラグインの既知の脆弱性や認証情報流出など、別の原因もあり得ます。

最初に検知時刻、症状、対象URL、発見者、直近の更新履歴を記録します。ホストと保守担当へ緊急連絡し、影響が疑われるサイトの公開制限やメンテナンス表示を検討します。大量の不審な外部通信や改ざんが進行中なら、単にページを閉じるだけでなく、ホストへ通信の遮断・隔離方法を確認してください。復旧のつもりでファイルを大量削除すると調査に必要な痕跡が消えるため、先に証拠の扱いを決めます。

連絡先が複数ある場合は、最初に連絡を受けた人が時刻と内容を共有できる一本の記録を作ります。制作者、ホスト、社内システム担当が別々に作業すると、誰がファイルを変えたのか後で分からなくなります。作業者、操作時刻、変更対象、判断理由を記録し、対外的な案内を出す担当も決めます。顧客が見る画面を一時停止する場合は、障害の詳細を断定する文章ではなく、確認中であることと次の更新時刻を示します。

最初の15分で決めること

最初の目的は「原因を言い当てること」ではなく、追加被害を防ぎながら調査可能な状態を残すことです。発見者は症状を一文で記録し、いつ、どの画面、どの利用者で確認したかを保存します。画面のスクリーンショットだけでなく、対象URL、ブラウザの時刻、エラー通知の原文、ホストからの連絡の受信日時も残します。緊急連絡を受けた責任者は、サービスをそのまま動かすリスクと停止の影響を比較し、誰が隔離を指示するかを決めます。ここで担当が曖昧だと、制作者が復旧を始めた一方で、ホストはログを保全中という衝突が起こります。

会員登録、注文、問い合わせなどで個人情報を受け取るサイトは、画面の改ざんだけでなく送信先のすり替えにも注意します。正規ページが表示されていても、フォームの送信先や埋め込みスクリプトが変わっている可能性があります。検知後の新規入力を止めるべきか、決済事業者へ連絡すべきかを事業責任者と決めます。停止が必要なら、感染が疑われるWordPress自体で作ったメンテナンスページだけに頼らず、ホストやCDNが提供する外側の制御を検討します。ただし設定変更の前に現状と時刻を記録し、変更後のログの保存方法も確認します。

改ざんが見えている、未知の管理者が作られた、外部への不審な送信が継続しているなど、強い兆候がある場合は緊急度を上げます。一方、PHP更新直後の500エラーや、正規担当者が作成したアカウントは誤認の可能性もあります。誤判定を避けるには、直近の変更申請、デプロイ履歴、保守業者の作業予定、CDNやホストの障害情報を同じ時間軸に並べます。「疑いはあるが未確認」「不正操作を確認」「原因まで特定」の三段階を分けて記録すると、報告文の精度が上がります。

何を侵害の兆候として扱うか

WordPress公式の侵害時ガイドは、検索サービスによる危険サイト判定、ホストによる停止、訪問者の警告、承認していないユーザー作成などを兆候として挙げています。しかし、単独の兆候で侵入経路は決まりません。たとえば検索結果に古いスパムページが残っていても、現在のサーバーがまだ改ざん中とは限りません。逆に、外観が正常でも管理者権限やファイルが変更されている場合は調査が必要です。

管理画面で見える兆候には、知らない管理者、本人が実行していないパスワードリセット、プラグインの無断追加、サイトURLや管理者メールの変更、公開済み記事への不審な外部リンクの挿入があります。画面だけでなく、データベース上のユーザー権限や設定を確認し、監査ログがある場合は作成者と時刻を突き合わせます。ただし共有アカウント運用では操作者を特定しにくいため、アカウント名だけで特定個人の操作だと決めつけないでください。

サーバー側では、正規の配布物にないPHPファイル、アップロード領域内の実行可能ファイル、予定外のcron処理、通常と違う外部送信、急なCPU負荷、メール送信量の増加を確認します。正規のキャッシュや画像変換でも一時ファイルが作られるため、「見慣れない名前」だけで悪性と判断せず、作成元、配置場所、ハッシュ、実行履歴をまとめます。マルウェア検査の陰性は安全証明ではなく、陽性も誤検知を含みます。ホストの検知通知と複数の証拠を合わせて判断します。

PHP2Shellに関連するかを調べる際は、実行中のPHP系列とホストが今回の修正を適用したか、問題となる条件に該当したかを別々に確認します。WordPressのバージョン番号だけでは判断できません。影響を受け得るPHPだった事実は「調査対象」という意味であり、実際に攻撃を受けた事実ではありません。アクセスログに攻撃らしいリクエストがあっても成功したとは限らず、逆にログが短期間で消えていれば、証拠がないことをもって未侵害とは言えません。WordPress公式の注意喚起とホストの個別案内を照合します。

封じ込めはサイト停止だけでは終わらない

侵害を疑うサーバーが第三者へ通信し続けているなら、閲覧停止よりネットワーク制御が重要になる場合があります。どの層で止めるかは構成次第です。ホスト管理下の共有サーバーでは利用者がOSへ直接触れられないため、ホストに停止、隔離、ログ保全を同時に依頼します。VPSやクラウドで自社が管理する場合は、ロードバランサー、セキュリティグループ、WAFなどの変更が選択肢ですが、操作自体が証拠に影響します。外部調査が必要な規模なら、作業前に専門家と手順を決めてください。

「全サービスを即座に電源断すれば安全」という固定手順はありません。稼働中のメモリやプロセス情報が必要な調査では、電源断で失うものがあります。一方、継続する情報流出のリスクが高ければ、保全より隔離を先にする判断もあり得ます。誰が何を優先したか、残ったリスクは何かを対応記録に残します。まず感染が疑われる環境から新しいバックアップを安全な場所へ取得する場合も、それをそのまま復旧元として信頼しないことが重要です。

管理者画面だけアクセス制限しても、公開側の脆弱なPHP実行経路が残ることがあります。WAFルールを入れても、既に侵入された後のバックドアや漏えい済み認証情報は解決しません。プラグインをすべて無効化する一括操作も、今回のようにPHP側が原因なら根治策ではなく、調査資料を変えてしまう可能性があります。封じ込め策ごとに「止めたい経路」「残る経路」「業務影響」「解除条件」を書き出し、ホスト・保守担当・事業責任者の合意を得ます。

対応記録を一本にまとめる

インシデント記録には、発見時刻、最後に正常と確認した時刻、症状、対象ドメインとサーバー、連絡先、判断者、操作履歴、保全済み資料、未確認の範囲を記します。時刻はJSTかUTCかを必ず添えます。アクセスログはUTC、WordPressの画面はサイト設定の時刻で表示されることがあるため、時刻帯の取り違えで順序が逆に見えるからです。ログ行を引用するときは元データを編集せず、分析用のコピーに注釈を付けます。

複数の業者が関わるなら、ホストにサーバー操作、制作会社にWordPress・テーマ・プラグイン、社内に顧客連絡と契約確認というように役割を置きます。ただし調査範囲は契約で異なるため、「保守契約だからフォレンジックも含む」と決めつけず、ログ取得、証拠の保管、夜間対応、復旧作業の担当を明文化します。定例連絡では、確認済み事実、新たな仮説、実施済み操作、次の判断時刻、顧客影響の五点を短く共有します。推測を事実の欄に混ぜないだけで誤った対外発表を減らせます。

停止か継続かを決める基準

サイトを止めるか迷ったら、機能ごとにリスクを分けます。記事閲覧だけの媒体なら、キャッシュされた静的ページの配信を残し、WordPressの管理画面と投稿機能を一時停止できる構成もあります。一方、会員ログインや問い合わせフォームが侵害環境を通るなら、新しい個人情報の入力を続けるリスクを重く見ます。ECサイトでは停止による注文損失と継続による顧客被害を比較しますが、売上だけでなく顧客への二次被害、決済契約、法的対応も判断材料です。技術担当がリスクを説明し、事業責任者が停止範囲を承認します。

選択肢は「全停止」と「通常公開」の二択ではありません。公開側をメンテナンス画面にする、ログインだけ止める、フォームを別の信頼できるシステムへ切り替える、注文受付を停止して既存注文の確認だけ残す、といった段階があります。ただし急造の代替フォームへ顧客情報を移すと、新しい管理リスクを生みます。代替手段のデータ保存先、アクセス権、利用者への案内、後で削除する方法まで確認します。どの機能を停止したか、利用者が誤解しない表示も必要です。

障害案内を侵害されたWordPress内に投稿しても、攻撃者が書き換えたり、CMSが停止して表示されなかったりする可能性があります。ホストやCDNの外側で表示するメンテナンス画面、公式SNS、既存のメール配信など、信頼できる連絡経路を選びます。複数の経路を使う場合は更新時刻と文面をそろえ、古い案内が残らないよう担当を決めます。調査途中では攻撃者に詳細な防御状況を知らせない配慮も必要ですが、利用者の安全に必要な行動まで隠してはいけません。

管理端末と連絡手段も確認する

WordPress公式ガイドは、サイトだけでなく管理者が使うローカル端末の確認にも触れています。攻撃者が端末の情報窃取型マルウェアからSFTPや管理画面の認証情報を得た場合、サーバーだけ修復しても再侵入する可能性があります。管理に使った端末、ブラウザ拡張、パスワード管理の状態を確認し、必要なら端末管理者に検査を依頼します。検査前に同じ端末で新しいパスワードを入力すると、変更後の秘密も漏れるおそれがあります。信頼できる別端末から作業する理由はここにあります。

侵害が疑われるメールアカウントやチャットだけで復旧作業を調整すると、攻撃者へ対応内容が伝わる可能性があります。メールが乗っ取られた兆候、転送設定の変更、不審なログインがあれば、電話など独立した連絡手段で本人確認をします。ホストから届いた緊急メールも、本文のリンクを急いで踏む前に、契約時から知っている管理画面や公式サポート窓口で真偽を確かめます。混乱時ほどフィッシングが入りやすくなります。

アカウントと情報の扱い

侵害範囲が分からないうちは、同じ端末や同じ管理画面から漫然と操作を続けないでください。信頼できる端末を使い、ホストやセキュリティ担当の指示に沿って管理者パスワード、ホストのログイン情報、必要に応じて関連APIキーや秘密情報を変更します。ただし変更のタイミングによってログや調査が難しくなる場合があるため、緊急封じ込めと証拠保全の順番を担当者と相談します。チャットやメールへ認証情報を平文で貼らないでください。

証拠を保全し、原因と被害範囲を切り分ける

ホストへ、アクセス・エラーログ、WAFログ、管理操作ログ、サーバーのプロセス・通信の記録の保管と保持期間を確認します。現在のファイルとデータベースのコピーを隔離して取得し、取得日時と担当者を残します。個人情報が含まれるため、保管先へのアクセスを制限します。ログの保全前にサイトを初期化すると、何が起きたか追えなくなることがあります。

調査では、いつから何が変わったかを並べます。新規ユーザー、権限変更、プラグイン・テーマ・コアの変更、不審なファイルの作成時刻、想定外の外部送信、WebサーバーとPHPのエラーを比較します。バックアップとの差分は手がかりですが、バックアップ自体が侵害後に取得された可能性にも注意します。PHP2Shellに起因するかどうかは、該当するPHP環境、ホストの修正状況、ログ、ファイルの痕跡を合わせて判断します。画面上の見た目だけで決めません。

複数のサーバーやサイトで同じ認証情報を使っているなら、調査対象を一つのWordPressだけに限定しません。ホストの管理画面、バックアップ保管先、関連サブドメイン、管理者のメールアカウントにも影響がないか確認します。証拠のコピーは上書きされない場所へ保存し、誰が取得したかを残します。長期のログがない場合は、「侵害なし」ではなく「確認できる期間が限られる」と記録してください。

保存する対象を先に決める

証拠保全の基本は、現状を再現・説明できる資料を、改変されにくい状態で確保することです。WordPressのファイル一式とデータベースだけでは、サーバーへの入口や攻撃後の通信が分からないことがあります。Webサーバーのアクセス・エラーログ、PHPログ、WAF/CDNログ、SSHや管理パネルの認証ログ、メール送信記録、クラウドの操作履歴、バックアップの世代情報まで、入手できる範囲をリスト化します。取得できない資料と理由も書きます。専門家へ渡すときに「何がないか」が分かると調査計画を立てやすくなります。

保存対象は元データと分析用コピーを分けます。元データには取得日時、取得者、取得元、保存先、ファイルサイズ、ハッシュ値などを記録し、アクセス権を必要な人に限定します。ハッシュは取得後の改変検知に役立ちますが、取得時点で既に侵害されていない証明にはなりません。機密情報や個人情報が含まれるログを、一般的なファイル共有リンクや公開チケットにそのまま載せないでください。受け渡し方法、保持期間、削除時の責任者を事前に決めます。

ホストへ依頼する際は「ログをください」だけでは不足します。対象ドメイン、対象サーバー、対象期間、必要なログの種類、時刻帯、保持期限、提供形式、料金、提供までの目安を確認します。Webアクセスログの保持期間が短い場合、数日後には消えることがあります。問い合わせでは、保全の依頼を先に出し、詳細な調査範囲は後から詰めるとよい場合があります。ただしホストごとに利用規約とサポート範囲が違うため、実施可能な手段を確認してください。

ファイルとWordPress設定の差分を見る

サーバー内のファイル調査では、いきなり見知らぬPHPを削除せず、隔離コピーを取って配置場所と更新日時を記録します。WordPressコアは正規の配布物と照合し、テーマ・プラグインは配布元、版、改変許可の有無を確認します。自社独自のテーマやカスタムプラグインを「公式配布物と違う」という理由だけで消してはいけません。比較対象として、管理されたソースコード、直近の正規バックアップ、デプロイ記録を利用します。

侵入者は目立つファイルだけでなく、既存のファイル末尾、設定ファイル、サーバーの起動処理、予約実行、プラグインの自動読み込み箇所へ変更を残すことがあります。だからこそ、トップページが直っただけで調査完了にしません。公開ディレクトリ以外の同一アカウントで読める領域、同じホスト上の別サイト、共有された設定ファイルも確認候補です。ホストが管理する領域へ勝手に手を入れず、担当範囲を分けて調べます。

WordPress側では、管理者一覧、権限を持つユーザー、サイトURL、管理者メール、プラグイン・テーマ一覧、公開記事の不審リンク、リダイレクト設定、フォームの送信先を比較します。データベースのテーブル名には標準の接頭辞以外が使われる場合があり、検索する場所を固定しないようにします。メールアドレスの変更は正規の運用でも起こるため、変更依頼や保守記録と照合します。監査ログプラグインが入っていても、そのログ自体が削除・改変される可能性を考え、ホスト側の記録と突き合わせます。

ログを一つの時系列に並べる

調査の起点は、最後に正常だった時刻と最初に異常を見た時刻の間です。そこから前後へ対象期間を広げます。アクセスログの異常なリクエスト、管理者ログイン、ファイル作成、プラグイン更新、外部通信、顧客からの通報を一つの表に並べます。時刻帯、記録精度、CDNとオリジンサーバーの差に注意してください。CDN経由ではオリジンに記録されるIPがCDNのものになり、元の接続元は別のログやヘッダーに残る場合があります。ヘッダーを信頼できる経路か分からないまま攻撃者のIPと断定しません。

たとえば午前9時に改ざんを発見し、前夜に未知のPHPが作られ、その直前に管理画面へのログインがあった場合、まずそのログインの正規性を確認します。同時に、PHPファイル作成がデプロイ作業やキャッシュ生成で説明できるかを調べます。もしアクセスログがその前日に途切れていれば、侵入の最初の時刻は特定できません。調査記録には「確認できた最も早い異常」と「侵入時刻の推定」を分けて書きます。推定の幅があればその理由も示します。

ログに機微なURLパラメータ、メールアドレス、セッショントークンが含まれることがあります。分析担当に必要な範囲を絞って渡し、報告書や顧客向け文面には不要な秘密を載せません。一方で元ログを無断で加工すると調査上の価値が下がるため、元データは保全し、共有用コピーでマスキングします。保全とプライバシー保護は両立できます。

PHP2Shellとの因果関係を慎重に判断する

今回のPHPの脆弱性が公表された直後は、ネット上のスキャンや脆弱性を探すアクセスが増える可能性があります。しかし、自サイトにそうしたアクセスが見えたことと、実際にサーバー内で処理が成功したことは別です。まずホストの修正状況、該当した実行構成、外部から問題の条件に到達できたかを確認します。次に、不審な操作やファイル作成が同じ時系列にあるかを調べます。どの条件が必要かは、PHP公式のCVE-2026-109618の情報とCVE-2026-109619の情報、ホストの説明を参照します。

外部の攻撃解説をそのまま本番サイトで試すのは避けてください。調査のためでも、サイトの状態を変えたり追加の危険を生んだりします。特に第三者管理の共有ホストでは、利用規約に抵触する可能性もあります。必要な検証はホストまたは許可を受けた専門家が、分離した検証環境で行います。記事やSNSで広まった単一の文字列だけをログ検索して「痕跡なし」と結論付けないことも大切です。攻撃手法、ログの記録範囲、プロキシ設定で見える情報が変わります。

データベースと情報流出の調査を分ける

データベースの改変調査では、管理者権限の付与、サイト設定、投稿本文のリンク、フォーム設定、注文や会員レコードの不自然な変更を調べます。内容が更新されていないことと、読み出されていないことは別問題です。個人情報の漏えい可能性を評価するなら、攻撃者がどの権限を得た可能性があるか、DB接続情報へ到達できたか、外部送信の記録があるか、ログがどこまで残るかを整理します。「画面の見た目が無事」は漏えい否定の根拠にはなりません。

WordPress本体のユーザー情報以外にも、ECの注文、問い合わせフォーム、会員制プラグイン、バックアップアーカイブ、添付ファイルに個人情報が入ります。契約や支払いに関わる情報が第三者のサービスで管理されている場合は、WordPress側の侵害だけでカード情報が漏れたと断定できませんが、決済ページの改ざんやAPIキーの露出は確認が必要です。どのサービスにどのデータが保存され、どの認証情報でつながっているかを「データの流れ」として図にすると、調査漏れを減らせます。

調査期間の終点も明示します。たとえば「10月20日から22日のサーバーログを確認し、不審なダウンロードは確認できなかった」と「個人情報の流出はなかった」では意味が大きく違います。前者は限られた範囲の観測結果です。ログが残っていない期間、別サーバー、暗号化された外部通信の内容は未確認と記録します。法的評価や利用者への通知判断は、調査担当だけで決めず、法務・個人情報保護担当者と行います。

ホストへ送る問い合わせのひな型

ホストへの連絡では、漠然と「PHP2Shellに対応していますか」と聞くより、判断に使える回答を依頼します。対象ドメインと契約IDを示したうえで、①該当サーバーのPHP実行方式と稼働系列、②CVE-2026-109618とCVE-2026-109619の修正適用状況、バックポートならその根拠、③適用日時、④問題の条件に外部から到達できた可能性、⑤関連するアクセス・エラー・WAF・プロセス・通信ログの保存期間、⑥ログ保全やサーバー隔離の可否、⑦実施済みの対策と利用者側で必要な操作、を尋ねます。問題の再現方法や攻撃コードを求める必要はありません。

ホストから「対応済み」と返ってきたら、いつ、何を、どのサーバーへ適用したかを確認します。WordPressの更新完了とPHPの修正完了が混ざっている回答なら、層を分けて聞き直します。「影響なし」の回答には、非該当の構成なのか、修正済みなのか、特定の機能が外部公開されていないのか、理由を確認します。利用者側でPHP版を切り替えられる場合でも、ホスト独自パッチの有無や全契約に適用済みかは画面だけで分かりません。回答は日時と担当者名を添えて作業記録に保存します。

調査依頼では、インシデントの断定を急がず、「10月22日に未知の管理者を確認した。作成時刻は不明。アクセスログの保全と、同時刻帯のホスト操作履歴の提供をお願いしたい」と観測事実を記載します。相手に求める作業が保全、分析、復旧のどれかを明示し、見積もりや提供期限も確認します。共有ホストでは他利用者の情報を含むログを提供できない場合があります。そのときはホスト自身による調査結果の報告方法を相談します。

調査対象を選ぶ優先順位

短い保持期間のログ、現在進行中の通信、顧客が使い続けるフォームは優先度が高いです。逆に古い公開記事の見た目や検索結果のキャッシュは、まず現行サイトが安全か確認してから追うこともできます。優先順位は「消えやすさ」「被害の拡大速度」「顧客への影響」「取得に必要な権限」で決めます。保全担当は、期限が迫る資料を先に取得するよう依頼し、調査担当は取得済み資料の分析を並行して進めます。少人数の体制でも順番を明確にすれば、重要なログの消失を防ぎやすくなります。

別のサイトやサービスへの横展開を考えるときは、共通のホストアカウント、SFTP認証情報、データベースユーザー、メールアカウント、CI/CDのデプロイキーがないか確認します。同じテーマやプラグインを使っているだけで、すべて侵害されたとは言えません。しかし共通の秘密情報を使い回していたなら、最初のサイト以外も調査対象です。関係図を作り、「共有されたもの」「共有されていないもの」を書くと、調査範囲を広げ過ぎず、漏らし過ぎずに済みます。

外部スキャンで見えるのは公開面だけです。管理画面の裏側や非公開ファイルを調べるには、ホストや管理者の協力が要ります。一方で管理画面へ入って手動で設定を見る操作は、侵害された環境上の記録を変える可能性があります。症状が重い場合は、まずホストがスナップショットを取り、分析用のコピーで調べる方法を検討します。解析ツールを本番へ入れる前に、そのツールがログやファイルをどう変更するかも確認します。

作業記録の例

時刻	確認・操作	担当と根拠	次の判断
10:05 JST	未知の管理者を発見。画面・URLを記録	運用担当。アカウント台帳と不一致	正規の保守依頼を照合
10:18 JST	ホストへログ保全と隔離可否を依頼	システム担当。保持期限が短い	ホスト回答を待つ間に顧客機能を評価
10:36 JST	問い合わせフォームを外側の設定で停止	事業責任者。新規入力の保護を優先	停止画面と問い合わせ窓口を確認
11:20 JST	ファイル・DBの保全コピーを取得	ホスト。取得範囲と保存先を記録	調査用コピーで権限変更と時系列を分析

これは架空の記録例です。実際の対応では、最後に正常を確認した時刻、調査資料の識別子、保全したログの時刻帯、作業で発生したサービス停止も追記します。表を関係者の共有資料とし、後から追記した人と日時が分かるようにします。発見時刻より前に侵害が始まっていた可能性を残し、事実が変わったら上書きで消さず、訂正履歴として残します。

見る場所	確認すること	注意
WordPressユーザー	未知の管理者、権限変更、ログイン時刻	正規の保守作業と照合
ファイル	未知のPHP、改ざん、アップロード先の実行ファイル	削除前にコピーと時刻を保存
ホストのログ	不審なアクセス、エラー、外部通信	保持期限と時刻帯を確認
データベース	不審な管理者や設定、投稿の変更	個人情報の扱いに注意

クリーンな環境で復旧し、再発を防ぐ

原因と影響範囲が見えたら、正規のWordPress、テーマ、プラグイン、確認済みのバックアップから復旧します。未知のコードだけを一行消して運用再開すると、別の侵入口や残存ファイルが残る可能性があります。ホストと保守担当に、サーバー・CMS・拡張機能・認証情報を含めた復旧範囲を確認してください。必要なら検証環境を作り、公開前に動作とログを確かめます。

PHP2Shellの対象環境だった場合は、ホストが今回の二つのCVEを修正したことを確認します。単にWordPress本体やプラグインを最新にしても、PHPの修正にはなりません。PHPの切り替えは安全な更新手順に沿って実施します。再開前には、トップページと主要記事だけでなく、問い合わせ、ログイン、購入・予約など重要機能をテストします。復旧後しばらくはアクセス、エラー、アカウント変更の監視を続けます。

復旧前に決める合格条件

サービス再開の基準を「ページが表示された」だけにすると、侵入口や不審なアカウントを残したまま公開するおそれがあります。最低限、侵入に利用された可能性のある経路が閉じていること、ホストのPHP修正が確認できたこと、正規のファイルと設定へ戻したこと、管理者権限と秘密情報を見直したこと、主要な業務機能が動くこと、再開後の監視担当がいることを確認します。何を確認できないまま再開するかも経営判断として記録します。調査完了を待つとサービス停止が長期化する場合には、限定公開や機能停止を伴う段階的再開も選択肢です。

復旧元のバックアップは「取得日が古いから安全」とは言えません。侵害前後の時系列と、バックアップ内のファイル・DBの状態を確かめます。たとえば不審な管理者が先月作られたのに、一週間前のバックアップを戻せばそのアカウントも復元されます。また、最新のバックアップだけを戻すと注文や問い合わせの一部が失われるかもしれません。データを戻す範囲と、欠損が起き得る期間を事業責任者に示して判断します。バックアップの「存在」ではなく、隔離環境で「復元できる」ことを確認します。

構築し直す場合、クリーンなPHP環境、正規のWordPress、信頼できる入手元のテーマとプラグインを準備し、検証済みのデータだけ移す方法があります。感染が疑われるサイトからディレクトリを丸ごとコピーすると、未知のファイルまで再投入しかねません。ただし独自開発のテーマや特殊な設定は一律に捨てられないため、ソース管理上の正規版と差分をレビューします。WordPress公式の侵害時ガイドも、ファイルの置き換えやパスワード・秘密鍵の更新を案内しています。実作業はサイト構成と保全方針に合わせてください。

秘密情報をどこまで更新するか

侵害された可能性のあるWordPress管理者パスワードだけを変えても、ホスト管理画面、SFTP/SSH、データベース、メール配信、CDN、外部APIの認証情報が残れば再侵入の経路になり得ます。まず「そのサーバーから読めた秘密情報」「共用していた秘密情報」「同じ管理端末で使った秘密情報」を整理し、影響の大きいものから変更します。すべてを一度に変更するとフォームや決済連携が止まる可能性があるため、連携先、担当者、変更の順番、失敗時の戻し方を表にします。

WordPressの認証キーとソルトを入れ替えると、既存のログイン状態を無効化できます。ただしそれだけで盗まれた外部サービスのAPIキーを無効にすることはできません。管理者のメールアドレスが乗っ取られていれば、パスワードを再設定しても攻撃者が回復できる可能性があるため、メール側も確認します。共有アカウントを廃止し、個人ごとの権限を最小限に分け、多要素認証が利用できる箇所では導入を検討します。変更済みの秘密をチャット、メール、公開チケットへ貼らず、管理された保管先を使います。

パスワード変更の時期には二つの目的があります。進行中の侵害を止めるための緊急変更と、クリーンな環境へ移した後の最終変更です。前者だけで終えると、侵害された環境で新しい認証情報も読まれる危険があります。可能なら安全な端末から変更し、復旧後に再度ローテーションする計画を立てます。どのアカウントを失効させたか、残るセッションやアプリケーションパスワードがないかも確認します。

段階的な動作確認と監視

検証環境では、トップページ、記事、管理画面、検索、問い合わせ、会員登録、ログイン、購入、予約、メール通知、外部API連携など、サイトが実際に担う機能を確認します。すべての機能を機械的に並べるのではなく、売上と顧客影響が大きいものから優先します。PHP更新後は拡張機能との互換性問題が起きる場合があるため、PHPのエラーログとアプリケーションのログを確認します。機能が壊れたからといって修正前のPHPへ無条件で戻すと、脆弱な状態を再公開するリスクがあります。代替構成や一部機能の停止をホストと相談します。

公開前の点検では、不審な管理者がない、不要なプラグインがない、ファイルの整合性を確認した、秘密情報を更新した、PHP修正済みである、フォーム送信先が正しい、改ざんされたページや検索結果への誘導が残っていない、監視通知が届く、という観点を使います。これらは絶対的な安全保証ではありません。どの範囲を誰が確認したか、実施日、未確認事項を記録し、再開後に追加調査の予定を置きます。

再開後は、管理者追加、プラグインの新規インストール、予期せぬファイル作成、外部通信、WAFの検知、エラー率、問い合わせや注文の異常を一定期間確認します。監視の頻度と終了条件を決めておかないと、「監視中」という言葉だけで実際には誰も見ない状態になります。初日の頻繁な確認、数日間の日次確認、その後の通常監視へ戻す例はありますが、対象の重要度と調査結果で調整します。異常が再発した場合に、どの条件で再隔離するかを事前に決めます。

顧客と取引先へ伝える内容

対外説明は早さと正確さの両方が要ります。調査初期に「流出はありません」と言い切ると、後で事実が変わったときの信頼を損ねます。確認できた範囲で、発見日時、現在のサービス状態、影響が疑われる機能、実施済みの封じ込め、利用者が取るべき行動、次回更新予定、問い合わせ窓口を伝えます。原因が未確定なら未確定と書きます。PHP2Shellが話題だからという理由だけで、それが原因と発表しないでください。

顧客へパスワード変更をお願いする場合、対象サービス、変更先の正規URL、偽メールへの注意、二要素認証の案内を明確にします。メールにパスワードを返信するよう求めてはいけません。事故を装ったフィッシングが出る可能性もあるため、同じ内容を公式サイトや既存の連絡チャネルにも掲示します。利用者が既に被害を受けた疑いがある場合は、問い合わせ内容を収集する窓口と社内のエスカレーション先を決めます。

制作会社やホストから顧客へ直接説明する場合は、どこまでが技術上確認された事実か、誰が事業者として通知を出すかを整理します。業者名を並べた責任の押し付け合いは、利用者に必要な行動を分かりにくくします。契約上の報告先、保険会社、委託元、決済事業者へ連絡が必要な場合もあり、契約と調査結果を確認します。広報文は法務・個人情報保護担当と技術担当が同じ版をレビューし、更新履歴を残します。

再発防止は原因の層ごとに考える

今回の侵入口がPHPなら、PHPの修正適用と更新期限の管理が中心です。しかし、同時に共有管理者パスワードや古いプラグインが見つかったなら、その弱点も放置しません。再発防止策を「ソフトウェアの更新」「権限と認証」「公開範囲とネットワーク」「ログと検知」「バックアップと復旧訓練」「連絡体制」に分け、各対策に担当者と完了期限を付けます。すべての対策を一度に完璧にするより、侵入口の封鎖と検知能力の回復を優先します。

PHPの版を切り替える責任がホスト側か利用者側か、SLAや契約で明確にします。テーマやプラグインの更新は制作会社、重要機能の受入確認は事業部、秘密情報の管理はシステム担当という具合に、作業と承認を分けます。WordPressのセキュリティ強化ガイドは権限や設定を考える参考になります。ただし推奨設定を無条件に一括適用すると既存機能が止まることもあるため、検証環境で影響を見ます。

定期バックアップは、保管場所が本番サーバーと同じ権限で消せるなら事故時に同時に失われる可能性があります。別の権限、別の場所、複数世代で管理し、復元テストの結果を記録します。ログの保持期間も、調査で必要だった期間を振り返って見直します。運用改善の指標は「再発ゼロ」といった達成を証明しにくい表現ではなく、修正通知から適用までの時間、バックアップの復元成功率、管理者権限の棚卸し実施率、重大アラートの初動時間など、測定できるものにします。

復旧会議で確認する四つの問い

復旧後の振り返りでは、個人を責める会議にせず、同じ状況で次回は何を変えるかを決めます。第一に「どの通知で気付いたか、気付けなかった時間はどれくらいか」。ホストの警告、利用者の通報、Search Consoleの異常、監視アラートのどれが最初だったかを確認します。検知から担当者へ届くまでに時間がかかったなら、通知先と休日・夜間の連絡方法を直します。

第二に「封じ込めに何が必要だったか」。ホストに隔離権限があるのか、CDNの設定担当は誰か、緊急停止の承認者は誰かを明確にします。停止判断が遅れた理由が契約や権限の曖昧さなら、技術設定より先に運用ルールを整える必要があります。ホストのサポート範囲と契約時間外の窓口を確認し、連絡先を平時から保管します。

第三に「調査できなかったことは何か」。ログ保持が短い、ファイルの変更履歴がない、管理者アカウントを共有している、バックアップの世代が足りないなど、今回の不明点を次の改善課題にします。「証拠がなかった」という結果は、今後の監視設計に価値があります。ログを無期限に保存すればよいわけではなく、費用と個人情報保護を考慮して必要な期間とアクセス権を決めます。

第四に「本当に復旧できるか」。バックアップからの復元手順、DNSやCDNの切り替え、主要機能の受入テスト、顧客連絡を、担当者が不在でも実行できるか試します。机上の手順書だけでは、認証情報が期限切れ、復元先の容量不足、メール送信が止まるなどの問題を見落とします。年に一度など運用に合わせた訓練を行い、作業時間と失敗箇所を記録します。

再発防止策の優先表

課題	先に行う対策	完了を示すもの
PHP修正状況が分からなかった	ホストの適用通知先と確認担当を固定する	両CVEの適用記録、担当者、確認日
管理者が共有アカウントだった	個人別アカウントと権限の棚卸し	不要権限の削除と次回棚卸し日
ログが消えていた	保持期間と外部保存を設計	取得できるログの種類と復元テスト結果
バックアップの安全性が不明だった	複数世代を隔離して保管し復元を試す	復元日時、対象、結果、所要時間
顧客案内が遅れた	第一報の承認者とひな型を整備	連絡訓練と更新担当の記録

優先表の各行に、所有者、期限、確認者、予算、業務への影響を追加すると実行計画になります。たとえばPHPの確認を「毎月」だけにすると、緊急リリースに追いつけない可能性があります。通常更新の周期と、重大な注意喚起を受けたときの臨時対応を分けます。ホスト任せにする場合でも、ホストの適用範囲を確認する責任まで外注できるとは限りません。契約の責任分界を明確にします。

利用者へ最終報告するときの構成

最終報告では、発覚と対応の時系列、対象サービス、確認された影響、確認できなかった範囲、原因と判断した根拠、復旧と再発防止、利用者へお願いする行動、問い合わせ先をそろえます。技術的な詳細をすべて公開する必要はありませんが、利用者の判断に必要な情報は省かないでください。原因がPHP2Shellと特定できなかった場合は、話題性に合わせて名称を使わず、「調査の結果、特定に至っていない」と示します。後で新事実が分かる可能性があるなら、更新方針も書きます。

顧客にパスワード変更を促す場合、事故との関係があるアカウントを限定して説明します。影響しないサービスまで一斉変更を求めると混乱しますが、同じパスワードを他サービスで使っていた人への注意は必要かもしれません。どの人に何をしてほしいか、締切があるか、支援窓口があるかを明示します。被害を申告する人の情報は調査に必要な範囲だけ集め、通報内容を新たな漏えい源にしないよう保護します。

情報漏えいの可能性は別途判断する

顧客情報や会員情報を扱うサイトでは、閲覧・持ち出し・改ざんの可能性を調査します。「不審ファイルがあった」だけで情報漏えいを断定できず、「持ち出しの証拠が見つからない」だけで否定もできません。法律や契約に基づく通知・報告が必要かは、対象データ、影響範囲、調査結果を踏まえ、法務・個人情報保護担当と判断してください。顧客への案内では、確認済みの事実、未確認の事項、利用者が取るべき行動を分けて伝えます。

日本の個人情報保護委員会は、個人データの漏えい等またはそのおそれについて、一定の要件に該当する場合の報告や本人通知を案内しています。判断に必要なのは、単にWordPressが改ざんされたかではなく、扱っていたデータの種類、攻撃者がアクセスできた可能性、影響する人数や経路、実際に確認できた事実です。委員会の「漏えい等の対応」を確認し、必要なら法律専門家へ相談してください。記事だけで個別案件の報告義務や期限を決めないでください。事業分野や委託契約によっても連絡先と対応が変わります。

調査が続く間は、暫定的な影響範囲と確定した影響範囲を分けます。たとえば「会員DBへアクセスし得る権限が使われた可能性」は、会員情報が実際に持ち出されたことと同じではありません。しかし、持ち出しの確証がないから何もしなくてよいとも限りません。相談のために、対象データの種類、対象期間、サーバー構成、ログの有無、確認済みの侵害操作、既に行った封じ込めを一枚の資料にまとめます。これにより法務、事業責任者、技術担当が同じ事実を見て判断できます。

判断例：三つの典型的な状況

例1：更新後に画面が真っ白になった。 これは侵害の可能性を直ちに意味しません。PHPの版変更と同じ時刻に起き、エラーログが古いテーマの互換性問題を示すなら、まず検証環境で再現します。ただし不審な管理者やファイルの追加も同時に見つかれば、別のインシデントとして扱います。白画面だから「攻撃された」、または更新直後だから「攻撃ではない」と決めつけないのがポイントです。

例2：知らない管理者が一つ増えた。 正規の外注担当者でないことを確認し、作成時刻、作成者、ログイン履歴、権限、実施操作を調べます。進行中の不正操作が疑われるなら、ホストと封じ込めを進めます。アカウントを消す前に、ユーザーIDやメール、ログ、関連するデータベースの状態を記録します。削除だけでは利用された侵入口が残るため、認証情報の流出か脆弱性の悪用かを切り分け、他のアカウントも調べます。

例3：ホストが外部通信を検知した。 通信先、時刻、送信量、プロセス、関連するリクエストを確認します。正規のバックアップ、解析、メール連携でも外部通信は起きます。運用台帳にない通信で、管理者の操作やファイル作成と重なるなら緊急度を上げます。個人情報の持ち出しの可能性は通信量だけで確定しませんが、通信内容が残らない場合は否定も困難です。ホストの保全資料を確保し、顧客データの所在を調べます。

FAQ：管理者がすぐ判断したいこと

Q. PHP2Shellの対象版を使っていたら、もう侵害されていますか。
A. いいえ。影響を受け得る版だったことは調査が必要な理由にはなりますが、侵害の事実ではありません。ホストによる修正のバックポートもあるため、表示される版だけで判断できません。ホストの適用状況とログ・ファイルの状況を合わせて確認します。

Q. WordPressの更新ボタンを押せば直りますか。
A. PHPの脆弱性はWordPressコアの更新だけでは修正されません。ホストまたはサーバー管理者がPHP側の修正を適用する必要があります。WordPress本体、テーマ、プラグインにも別の既知の問題がないか点検しますが、対策の層を混同しないでください。

Q. セキュリティプラグインが「問題なし」と表示しました。
A. 参考になりますが、侵害の否定には足りません。検査できるファイルやシグネチャには限界があり、ホスト側のプロセスや過去の通信までは見えない場合があります。強い兆候があれば、ログと権限、正規ファイルとの差分を確認します。

Q. 不審なファイルを見つけました。すぐ削除すべきですか。
A. 不審な実行が続くなら封じ込めを優先しますが、削除前にホストまたは専門家と証拠保全を相談します。パス、ハッシュ、作成・更新時刻、ファイルのコピーを残さず消すと、侵入口や被害範囲の調査が難しくなります。確認していないファイルを開いたり実行したりしないでください。

Q. サイトを非公開にすれば情報流出は止まりますか。
A. 閲覧側のリスクは下げられても、サーバーからの外部通信、盗まれた認証情報、バックドアが残る可能性があります。公開停止だけで安全になったと考えず、ホストと隔離範囲を確認します。

Q. バックアップを戻した後ならパスワード変更は不要ですか。
A. 不要とは言えません。バックアップに不審なアカウントやコードが含まれている場合もあり、侵害中に認証情報が読まれた可能性もあります。復旧元の検証、秘密情報の更新、セッションの失効を一緒に進めます。

Q. ログに攻撃らしいアクセスが見えません。
A. 保存期間や記録範囲、CDNの経路を確認します。ログがない、短い、上書きされた場合は、観測できない期間が残ります。「確認した範囲で該当痕跡なし」と書き、未確認の範囲を示します。

Q. 顧客にはいつ、何を伝えればよいですか。
A. 契約・法令・影響状況により判断が変わります。少なくとも、担当者を決め、確認済み事実と未確認事項、利用者が取るべき行動、次の更新時刻を整理します。個人情報の漏えい等が疑われる場合は、個人情報保護委員会の公式情報と法務担当の判断を確認します。

運用に使えるチェックリスト

検知・初動：発見者、時刻、症状、対象URL、最後に正常だった時刻を記録したか。ホストと社内責任者へ連絡したか。個人情報を受ける機能への影響を確認したか。封じ込めの判断者と次回判断時刻を決めたか。操作記録の共有場所を一本化したか。

保全・調査：ログの保持期限を確認し、保全を依頼したか。現状のファイルとDB、ホストのログ、管理操作を取得したか。元資料と分析コピーを分けたか。WordPress、PHP、ホストの修正状況を区別して確認したか。侵入時刻、影響範囲、未確認期間を分けて記録したか。

復旧・連絡：クリーンな復旧元を確認したか。侵入口の修正と秘密情報の更新を終えたか。主要機能を検証したか。漏えい可能性を法務・個人情報保護担当と評価したか。顧客・取引先へ伝える事実と未確認事項を整理したか。再開後の監視担当、頻度、再隔離条件を決めたか。

担当者別の引き継ぎ事項

経営・事業責任者：停止の事業影響、顧客被害の可能性、復旧の条件、外部への説明責任を持ちます。技術担当から「危険です」とだけ聞いても判断できないため、継続する場合のリスクと停止する場合の損失、限定再開の選択肢を比較してもらいます。決定した内容と判断時刻を記録します。

ホスト・サーバー担当：PHPの修正状態、サーバー隔離、ログ保全、環境の再構築可能性を確認します。複数サイトを同一アカウントで運用しているなら、他サイトへの影響範囲も伝えます。利用者に提供できるログと、ホスト内でしか確認できない記録を区別します。共有環境なら他契約者の情報を含まない形で結果を報告する方法を相談します。

WordPress保守担当：コア・テーマ・プラグイン・ユーザー・設定・独自コードの正規状態を特定し、侵害の疑いがある現物との差分を調べます。復旧時はファイルだけでなくDBの設定や投稿内容も確認します。PHPの修正はホスト側の責任範囲かもしれないため、保守担当だけで「対策完了」と報告しません。

法務・個人情報保護担当：どの情報をサイトが扱い、どの範囲が攻撃者から見えた可能性があるか、技術担当と事実を合わせます。報告・通知の要否は公式情報、契約、個別事情に基づいて評価します。利用者向け文面に推測や過度な安心表現がないか確認します。技術調査の限界が結論にどう影響するかも明記します。

広報・顧客対応担当：公表文、FAQ、窓口、次回更新時刻をそろえます。問い合わせで新しい被害情報が集まったら、個別のサポートで終わらせず調査担当へ連携します。顧客からの通報内容には個人情報や画面のスクリーンショットが含まれるため、受付システムの権限と保存期間を確認します。

このチェックリストはサイトの規模や契約に合わせて増減してください。医療、決済、会員制など、重要なデータを扱うサイトほど専門家との連携が必要です。調査で「対応できなかった項目」は消さずに残し、後日のログ保持設定や契約の見直しに生かします。NIST SP 800-61 Rev.3やIPAの初動対応に関する資料も、組織の手順を整える際の参考になります。

最後に、発見時刻、対応履歴、修正状況、復旧判断者、再発防止策を記録します。WordPress公式の侵害時ガイドも参照してください。今回の脆弱性が原因と断定できない場合は、原因を「調査中」と明記することが正確です。

この対応は一度の作業で終わりません。公開再開時点では、ログの一部が未回収、外部サービスの調査が継続中、検索結果に古い改ざんページが残る、といった課題があり得ます。未完了項目ごとに担当者と期限を置き、次の確認で完了の証拠を残します。検索結果やキャッシュの修正依頼は、公開サイトの安全性と内容を確認した後に進めます。報告書に「完了」と書くのは、決めた復旧条件を満たした範囲だけです。技術的な根本原因が特定できなければ、残るリスクと追加調査の予定を明記してください。四半期後には改善策の実施状況を見直し、担当者の交代やホストの契約変更で手順が使えなくなっていないかも確かめます。事故から得た教訓を、次の緊急更新に備える運用へ変えることが最後の工程です。

根拠（2026年10月22日確認）：WordPress公式侵害時ガイド、WordPress公式注意喚起、PHP公式リリース、IPA「中小企業のためのセキュリティインシデント対応の手引き」、NIST SP 800-61 Rev.3、個人情報保護委員会「漏えい等の対応」

AIスキルで、未来の自分をアップデート！

今なら完全無料でAIを学べる！

WithAIには、目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースがあります。動画や実践を通して、スマホ・PCから自分のペースで学べます。WithAIは侵害調査や緊急復旧の窓口ではありません。不審な活動が進行中なら契約ホストと専門担当者へ連絡し、安全が確認された後にAIの学習を始めたい方は、WithAIの無料学習案内をご覧ください。