WordPressが改ざんされた！最初の1時間でやるべき初動対応【2026年版】

まず、深呼吸してください。

WordPressの「乗っ取り」や「改ざん」に気づいた直後は、誰でも焦ります。ただ、ここで慌てて操作すると、被害が拡大したり、原因調査に必要な証拠を消してしまったりします。実際、Googleもセキュリティ問題の調査で「感染ページを普段どおりブラウザで直接開かない」ことや、サイト全体を修正してからレビュー申請することを明確に案内しています。

初動での目的は「完璧な修復」ではなく「被害拡大を止め、証拠を残し、正しい順番で復旧に進むこと」です。

この記事は、株式会社WEBRALに相談が多い実例を踏まえつつ、Wordfence / Sucuri / WPScan / IPA / JPCERT/CC / Google公式情報に基づいて、時系列で使えるチェックリストにまとめています。

乗っ取り・改ざんの症状別 早見表（最初にここだけ確認）

症状	まず疑うこと	優先度	最初の対応
管理画面に入れない（パスワード再発行も不可）	管理者アカウント改変・削除	最優先	サーバー側から管理者復旧、全認証情報の緊急変更
訪問者だけ別サイトへリダイレクトされる	DB/テーマ/PHPの改ざん、Apache系なら.htaccess、Nginx系ならserver block/vhost設定の改ざん	最優先	サイト一時停止、ログ保全、感染ページを直接ブラウザ閲覧しない
Google検索で「このサイトは危険」「改ざんされた可能性」表示	Safe Browsing検知（マルウェア/フィッシング等）	高	Search ConsoleのSecurity Issuesで原因確認→修正→レビュー申請
見覚えのない固定ページ・日本語スパムURLが増えた	SEOスパム注入・悪性サイトマップ	高	DBと公開ディレクトリ調査、不正URL除去、再クロール対応
ホスティング会社からマルウェア通知	サーバー側で不審通信/ファイル検知	高	即時隔離、ホストへ証拠保全依頼、停止範囲を確認
見覚えのない管理者ユーザーが追加されている	権限昇格・バックドア運用	最優先	不正ユーザー凍結、全ユーザー強制パスワード変更、改ざん範囲調査

Wordfence / Sucuri の公開ガイドでも、勝手なリダイレクト 管理画面ロックアウト 検索結果やブラウザ警告 ホストからの異常通知 は、典型的な侵害シグナルとして挙げられています。

初動の原則（先に「やること」と「やらないこと」を分ける）

区分	原則
やること	被害拡大の停止、証拠保全、連絡体制の確立、復旧方針の決定
やらないこと	証拠を消す操作、闇雲な削除、原因未特定のまま本番復旧

IPAの最新手引き（2026年3月版）でも、インシデント対応は 検知・初動対応 → 報告・公表 → 復旧・再発防止 の順で整理されています。つまり、「いきなり直す」のではなく、「止血→記録→復旧」が基本です。

最初の1時間でやること（止血フェーズ）

目標	具体アクション	完了条件
被害拡大を止める	隔離・一時停止・管理導線の保護	新たな改ざんと外部被害が止まる
証拠を残す	ファイル/DB/ログの取得	事後調査できる状態になる
指揮系統を作る	社内連絡と責任者確定	誰が判断するか明確になる

1) まず「隔離」する（ただし電源を雑に落とさない）

• 可能なら公開サイトをメンテナンス表示へ切替（または一時的にWAF/Basic認証で閉鎖）
• 管理画面、SSH/SFTP、コントロールパネルへのアクセス元を限定
• 被害ホストや端末をネットワーク分離

IPAは初動対応として、外部アクセス可能な状態なら ネットワーク遮断・機器隔離・サービス停止 を示しつつ、不用意な電源断で記録を消さない 点を明記しています。ここは最重要です。

2) 証拠保全を先にやる（修正はその後）

• 現時点のサイトファイルを丸ごとバックアップ（圧縮して保管）
• DBダンプを取得
• Web/PHP/アクセス/認証ログを別保管
• いつ・誰が・何をしたかを時系列メモ化（5W1H）

Wordfenceも、侵害確認後は最初にサイト全体とDBのバックアップ取得を推奨しています。Google公式もログ監視の重要性を強調しており、ログ改ざん対策まで言及しています。

3) 連絡体制を立ち上げる

• 社内の責任者（経営者/情報セキュリティ責任者）へ即時報告
• レンタルサーバー会社へ「停止範囲」「証拠保全」「復旧制限」を確認
• 必要に応じてJPCERT/CCへ相談

JPCERT/CCは、被害組織向けに インシデント初動対応支援 と セカンドオピニオン を明示しています。自力で判断が難しい時は、早めに外部知見を使う方が被害を小さくできます。

4) 同時に「認証情報の緊急リセット計画」を立てる

この段階では、まだ雑に作業しません。まず対象を洗い出します。

• WordPress全ユーザー（特に管理者）
• SFTP/FTP
• SSH
• DBユーザー
• サーバー管理画面
• CDN / DNS / WAF / バックアップサービス / メール

24時間以内にやること（調査・封じ込めフェーズ）

目標	具体アクション	完了条件
侵入口を塞ぐ	認証情報更新・脆弱コンポーネント停止	再侵入しにくい状態になる
改ざん箇所を特定	重点ファイルとDBの比較調査	不正変更の一覧が出る
復旧方針を確定	リストアか手動修復かを判断	作業手順が一本化される

1) 全認証情報を一斉リセット

Wordfenceの手順でも、復旧工程の早い段階で 全パスワード変更 を強く推奨しています。使い回しアカウントがあると、掃除後の再侵入が起きます。

• 全管理者ユーザーの強制リセット
• 不審ユーザーの無効化・削除（証拠は残す）
• APIキー・アプリパスワード・接続トークンの再発行
• 2FAの再設定（管理者必須）

2) 改ざんファイルの重点確認

WordPress改ざんでは、すべてのファイルを同じ熱量で見ると時間切れになります。優先順位を決めます。

優先度A（最優先）

• wp-config.php
• .htaccess
• wp-content/uploads/ 内の php 実行ファイル

優先度B（次点）

• wp-content/themes/<使用中テーマ>/functions.php
• wp-content/plugins/ 内の不審な新規フォルダ
• must-use plugins（mu-plugins）

優先度C（横断確認）

• wp-admin と wp-includes の追加ファイル有無
• スケジュールタスク（cron）
• DB内の不審オプション・管理者ユーザー

Wordfenceは wp-admin / wp-includes に新規ファイルがある場合は高確率で不正と説明しています。またGoogleのセキュリティ解説でも、ヘッダリダイレクト や JavaScript注入、.htaccess 改変が典型例として示されています。

3) 変更差分を機械的に洗い出す

SSHが使える場合、Wordfenceが紹介するように更新時刻検索は有効です。

find . -mtime -2 -ls

上記は「直近2日で変更されたファイル」の洗い出しです。侵害推定時刻に合わせて -mtime を調整し、正規更新との差分を切り分けます。

4) 復旧方針を決める（リストア vs 手動クリーン）

• クリーンなバックアップ があり、感染時刻より前と確信できる: リストア優先
• バックアップの清潔性が不明 / 長期間侵害の可能性: 手動調査＋専門家併用

Google公式も「最後の正常バックアップから置換」か「手動除去」のどちらかで全体修正するよう案内しています。部分修正だけでは再審査が通らないケースがあります。

1週間以内にやること（復旧完了・再発防止フェーズ）

目標	具体アクション	完了条件
対外的な正常化	Search Consoleでレビュー申請	警告解除と再評価が進む
再発防止	脆弱性管理・監視強化	同系統の再侵入を防止
運用定着	手順書化・演習	担当者依存が減る

1) Google Search ConsoleでSecurity Issuesを解消

• Security Issuesレポートですべての指摘カテゴリを確認
• サイト全体の修正完了を確認（部分修正で終わらせない）
• Request Review で対応内容を具体的に記載

Googleは、レビュー申請時に「何が問題だったか」「どう修正したか」「結果どうなったか」を明確に書くことを求めています。審査期間は一般に 数日〜数週間 です。

補足として、警告を再現できない場合でも、GoogleはSecurity Issuesレポートを「source of truth（基準情報）」として扱うよう案内しています。

2) 脆弱性の棚卸し（WPScanなどで客観確認）

• WordPress本体、テーマ、プラグインのバージョン一覧化
• 使っていないプラグイン/テーマを削除
• 既知脆弱性の有無を確認

WPScanは、WordPress本体・プラグイン・テーマの脆弱性データを継続更新しており、API上で 手動検証済み（Verified） や CVE採番（CNA） 情報を公開しています。復旧後の再点検に有効です。

3) 監視と体制を整える

• 改ざん監視（ファイル差分監視、管理者追加検知）
• ログ保全期間の明確化
• インシデント時の社内連絡網と意思決定フロー整備
• 月1回の復旧訓練（机上で可）

IPAの手引きでも、最終フェーズは 再発防止（技術対策・ルール・教育・体制） まで含めて完了としています。

やってはいけないこと（アンチパターン）

NG行動	なぜ危険か
いきなりプラグインを全削除	原因特定前に証拠消失。再発防止に必要な痕跡が失われる
感染ページを普段のブラウザで巡回	端末二次感染・誤認リスク。Googleも直接閲覧を避けるよう案内
改ざんファイルだけ消して即公開	侵入口未封鎖だと再侵入し、短時間で再改ざんされる
1つのパスワードだけ変更して終了	同時に漏えいした他アカウントから横展開される
ログをローテーション前に消す	法務・保険・顧客説明で必要な証跡がなくなる
「表示が戻ったから完了」と判断	Search Console警告や隠しバックドアが残る場合がある

初動の失敗で多いのは「早く戻したい気持ち」が先行して、証拠保全と再侵入対策が後回しになることです。

セルフ対応か、専門家依頼かの判断基準

条件	判断
侵害範囲が限定的で、直近クリーンバックアップがある	セルフ対応可能性あり
管理者乗っ取り + 不審ユーザー追加 + リダイレクト混在	専門家依頼を推奨
EC/会員情報など個人データを扱う	早期に専門家・法務含めた体制へ
社内にWordPress/サーバー調査経験者がいない	早めに外部支援を使う方が安全
Google警告解除が長引く、再感染を繰り返す	専門家依頼を優先

Googleの案内でも、マルウェア対応にはコードやサーバー設定の理解が必要で、難しい場合は支援チームを組むことが推奨されています。無理に内製で引っ張るより、被害期間を短くする方が合理的です。

株式会社WEBRALとしての支援範囲（必要な場合の選択肢）

株式会社WEBRALでは、以下のようなケースで復旧支援を行っています。

• どこまで侵害されているか分からない
• 担当者が1人で初動判断が難しい
• 一度直したのに再改ざんされた
• Search Consoleの警告解除まで一気通貫で進めたい

対応は、証拠保全 → 封じ込め → 復旧 → 再発防止 の順で実施します。セルフ対応が可能な場合はそのまま進めるのが最もよく、難易度が高い局面だけ外部支援を使うという使い方でも問題ありません。

まとめ

WordPressの乗っ取り・改ざん対応は、技術力より先に「順番」が重要です。

1. 最初の1時間で止血と証拠保全
2. 24時間以内に侵入口封鎖と復旧方針確定
3. 1週間以内に外部警告解除と再発防止の定着

この3段階を守るだけで、復旧スピードと再発率は大きく変わります。まずは本記事のチェックリストを社内手順に落とし込み、次のインシデント時に迷わない状態を作っておくことをおすすめします。

参考情報（公式・一次情報）

• Wordfence: How to Clean a Hacked WordPress Site using Wordfence
  https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/
• Sucuri: WordPress Hacked: What to Do When Your Site is Compromised
  https://blog.sucuri.net/2024/02/wordpress-hacked.html
• Sucuri: 2023 Hacked Website & Malware Threat Report
  https://blog.sucuri.net/2024/06/2023-hacked-website-malware-threat-report.html
• Sucuri: Backdoors Risks & Mitigation（PDF）
  https://sucuri.net/wp-content/uploads/documentation/Sucuri_Backdoors_Risks_%26_Mitigation.pdf
• WPScan: WordPress Vulnerability Database API
  https://wpscan.com/api/
• Google Search Console Help: Security issues report
  https://support.google.com/webmasters/answer/9044101
• Google Search Central: Preventing malware infection
  https://developers.google.com/search/docs/monitor-debug/security/prevent-malware
• IPA: 中小企業のためのセキュリティインシデント対応の手引き（2026年3月）
  https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_incidenttebiki.pdf
• IPA: プラクティス7-2 従業員の初動対応の規定
  https://www.ipa.go.jp/security/economics/practice/practices/Practice228/
• JPCERT/CC: インシデント対応依頼
  https://www.jpcert.or.jp/form/
• JPCERT/CC: インシデント相談・情報提供（被害組織向け）
  https://www.jpcert.or.jp/ir/consult.html

※本記事は2026年6月4日時点で公開されている情報を基に作成しています。運用手順に転記する際は、各機関の最新改訂日もあわせて確認してください。