WordPressのマルウェア感染・改ざんからの復旧手順

WordPressがマルウェアに感染したり改ざんされたりしたときは、①感染した状態のコピーを残す ②すべてのログイン情報を無効にする ③本体・プラグイン・テーマを正規のファイルで入れ替える ④残ったファイルとデータベースを点検する ⑤更新してパスワードをもう一度変える ⑥検索結果の後始末をする、の順に進めます。ポイントは、侵入口をふさいでからきれいにすることです。バックアップから戻しただけでは、同じ手口で再び改ざんされます。

この記事は、公開停止・証拠の保全・関係者への連絡といった初動を終えた後の、WordPress固有の復旧作業を扱います。初動がまだの場合は、先にホームページがハッキングされたときの初動対応を確認してください。

手順は、WordPress.orgの公式ドキュメント「FAQ My site was hacked」と、Googleのweb.devの解説をもとに整理しています。あわせて、当社が実際に対応した改ざんの復旧事例も紹介します。

復旧を始める前に確認すること

WordPressの復旧作業に入る前に、次の3点が終わっているかを確認します。いずれも冒頭で紹介した初動対応の記事で詳しく解説している内容です。

• サイトを一時的に公開停止し、訪問者への被害を止めている
• 画面・ログ・改ざんされたファイルなどの証拠を残している
• サーバー会社、制作・保守会社、社内の責任者に連絡している

WordPress.orgのドキュメントは、これに加えて作業に使うパソコンのウイルススキャンを勧めています。攻撃の起点がパソコンにあり、トロイの木馬などでFTPや管理画面のログイン情報が盗まれている例が多いためです。パソコンが感染したままでは、サイトをきれいにしてもすぐにまた入られてしまいます。

復旧方法を選ぶ｜バックアップから戻すか、駆除するか

復旧の進め方は、ハッキング前のきれいなバックアップがあるかどうかで変わります。web.devの解説「Clean and maintain your site」では、次の3つに分けて案内しています。

注意したいのは、「きれいな」バックアップかどうかの見極めです。web.devは、そのバックアップがハッキングされる前に作られたものかを確認するよう求めています。改ざんは気づくまでに時間がかかることがあるため、サーバーの自動バックアップ（例：エックスサーバーは過去14日分）がすべて感染後のもの、ということも起こりえます。日頃のバックアップの取り方と保存期間の考え方は、WordPressのバックアップと復元方法で解説しています。

WordPressの復旧手順

ここからは、きれいなバックアップがない場合も含めて、WordPressを復旧する手順を順番に説明します。バックアップから戻せた場合も、ステップ2とステップ5以降は省略しないでください。

ステップ1：感染した状態のコピーを取っておく

WordPress.orgのドキュメントは、駆除に入る前に感染していても、もう1つスナップショット（コピー）を取っておくよう勧めています。作業中に何かを壊してしまったとき、参照できる元の状態がなくなるのを防ぐためです。web.devも、きれいなバックアップがない場合は感染した状態のバックアップを取り、本番ではなくコピーで作業する方法を紹介しています。

ファイル一式とデータベースの両方をコピーし、「感染時」とわかる名前で、公開フォルダの外に保管します。

ステップ2：すべてのアクセスを無効にする

攻撃者がまだログインできる状態で作業しても意味がありません。WordPress.orgのドキュメントに沿って、次の順で入口を閉じます。

1. 全ユーザーのパスワードを変更する（特に管理者）
2. 見覚えのないユーザーを確認する：管理画面の「ユーザー」で、知らない管理者が追加されていないかを確認し、記録してから削除する
3. ログイン中のセッションを切る：wp-config.php の「認証用ユニークキー（セキュリティキー）」を、WordPress公式のキー生成ページ（https://api.wordpress.org/secret-key/1.1/salt/）で作った新しい値に書き換える。これで、ログインしたままの人は強制的にログアウトされる
4. WordPress以外の入口も変える：FTP/SFTP、サーバーの管理画面（コントロールパネル）、データベース（MySQL）のパスワード

WordPress.orgは、これらは「自分のユーザーだけでなく、環境にアクセスできるすべてのユーザー」に及ぶとしています。退職者や以前の制作会社のアカウントが残っていれば、このタイミングで整理します。

ステップ3：スキャンで感染箇所の見当をつける

WordPress.orgのドキュメントは、サイトのスキャン方法として、**サイト内で動くスキャナー（プラグイン）**と、外部から調べるスキャナーの2種類を挙げ、組み合わせることで見つけられる可能性が高まるとしています。プラグインの例としてWordfence、Sucuri、Quttera、GOTMLS、外部スキャナーの例としてVirusTotalやSitecheckが紹介されています。

WP-CLI（WordPressをコマンドで操作するツール）が使える環境なら、wp core verify-checksums で、本体のファイルがWordPress.orgの正規のファイルと一致するかを確認できます。一致しないファイルがあれば、改ざんの手がかりになります。

スキャンで「問題なし」と出ても、安全が保証されたわけではありません。次のステップ以降の点検は省略しないでください。

ステップ4：本体・プラグイン・テーマを正規のファイルで入れ替える

WordPress.orgのドキュメントは、本体を入れ直すときのポイントとして次の点を挙げています。

• いま使っているのと同じバージョンを入れ直す（違うバージョンにするとサイトが動かなくなるおそれがある）
• 管理画面の「再インストール」ではなく、FTP/SFTPでファイルを置き換える。管理画面からの再インストールは既存のファイルを上書きするだけのことが多く、攻撃者が追加したファイルが残るため
• /wp-admin と /wp-includes は、フォルダごと安全に置き換えられる

web.devも、上書きの更新では古いファイルが残ることがあるため、クリーンインストールを勧めています。

テーマとプラグインが入っている wp-content は、慎重に進めます。

• プラグインとテーマは、公式ディレクトリや開発元から改めてダウンロードしたものに入れ替える
• 使っていないプラグイン・テーマは、停止ではなく削除する
• 有料プラグインを非正規の配布元から入手していた場合は、それ自体が感染源の可能性がある

ステップ5：残ったファイルを点検する

入れ替えられないファイル（設定ファイルやアップロードした画像のフォルダなど）は、1つずつ確認します。

ステップ6：データベースを点検する

改ざんはファイルだけでなく、データベースにも及ぶことがあります。phpMyAdminなどで、次の点を確認します。

• ユーザー：wp_users テーブルに、管理画面で見えなかったユーザーが残っていないか
• サイトURL：wp_options テーブルの siteurl と home が、正しいURLになっているか（別サイトへの転送に使われることがある）
• 記事・固定ページ：本文に、見覚えのないスクリプトやリンクが埋め込まれていないか
• 追加されたページ：攻撃者が作った記事・ページが残っていないか（URLを記録してから削除）

データベースを直接さわる作業は、誤ると表示が崩れたりデータが消えたりします。自信がない場合は、無理をせず専門家に依頼してください。

ステップ7：最新版に更新し、パスワードをもう一度変える

きれいになったら、WordPress本体・テーマ・プラグインを最新版に更新します。WordPress.orgは「古いバージョンは新しいバージョンよりハッキングされやすい」としています。

そして、パスワードをもう一度変更します。WordPress.orgのドキュメントは、発見時に変えただけなら、サイトがきれいになったことを確認した後に改めて変えるよう求めています。データベースのユーザー名とパスワードを変えた場合は、wp-config.php の設定も合わせます。

最後に、侵入経路を振り返ります。古いプラグインだったのか、使い回しのパスワードだったのか、パソコンの感染だったのかを特定できないと、同じ被害を繰り返すおそれがあります。

## 検索結果の後始末

サイトがきれいになっても、攻撃者が作ったスパムページが検索結果に残っていることがあります。WordPressの復旧とあわせて、次の対応を行います。

• 攻撃者が作ったURLは404（または410）を返すようにする：web.devは、これでいずれGoogleのインデックスから外れるとしています。
• 急ぐ場合はSearch Consoleの「削除」ツールを使う：Search Consoleヘルプによると、削除リクエストでブロックされる期間は約6か月で、恒久的に消すには404・410を返すなどの対応が必要です。web.devは、改ざんされただけの正規のページには使わないよう注意しています。
• サイトマップを再送信し、URL検査で再クロールを依頼する：Google検索セントラルによると、クロールには数日から数週間かかることがあります。
• 警告が出ている場合は審査をリクエストする：Search Consoleの「セキュリティの問題」レポートから、駆除が終わってから申請します。
• 警告の種類ごとの審査期間や、検索順位への影響と回復の考え方は、[セキュリティとSEOの関係](/column/security-seo-impact/)で詳しく解説しています。

検索結果の後始末

サイトがきれいになっても、攻撃者が作ったスパムページが検索結果に残っていることがあります。WordPressの復旧とあわせて、次の対応を行います。

• 攻撃者が作ったURLは404（または410）を返すようにする：web.devは、これでいずれGoogleのインデックスから外れるとしています。
• 急ぐ場合はSearch Consoleの「削除」ツールを使う：Search Consoleヘルプによると、削除リクエストでブロックされる期間は約6か月で、恒久的に消すには404・410を返すなどの対応が必要です。web.devは、改ざんされただけの正規のページには使わないよう注意しています。
• サイトマップを再送信し、URL検査で再クロールを依頼する：Google検索セントラルによると、クロールには数日から数週間かかることがあります。
• 警告が出ている場合は審査をリクエストする：Search Consoleの「セキュリティの問題」レポートから、駆除が終わってから申請します。

警告の種類ごとの審査期間や、検索順位への影響と回復の考え方は、セキュリティとSEOの関係で詳しく解説しています。

【事例】アイエムワークスが対応した改ざんの復旧

当社が復旧を担当した改ざん事例を紹介します。お客様の特定を避けるため、業種は伏せています。

この事例からわかること

この事例では、見た目の書き換え・ページの追加・転送・裏側のコードという、性質の違う改ざんが同時に起きていました。見た目の書き換えを直しただけでは、裏側のコードや転送の設定が残ってしまいます。前述のステップ4〜6のように、ファイルとデータベースの両方を、場所ごとに点検する必要があるのはこのためです。

また、侵入に使われたのは脆弱性ではなく、使い回されていた正規のパスワードでした。この場合、本体やプラグインを最新にするだけでは再発を防げません。ステップ2のアクセスの無効化と、二段階認証の導入が欠かせない対策になりました。

担当者がこの事例でいちばん大きかったと振り返るのは、早く気づけたことです。Googleからの警告や通知は出ていなかったため、通知を待っていたら発見はもっと遅れていた可能性があります。

この事例で行った作業

この事例では、1つの方法だけで元に戻したわけではありません。不正なファイルの駆除、バックアップからの復元、環境の作り直しを組み合わせて復旧しました。

不正なコードが見つかったのは、次の場所です。

どれも、この記事の「ステップ5：残ったファイルを点検する」で挙げた場所です。見た目の書き換えを直しただけでは、こうした場所に残った不正なコードは消えません。

約2週間の内訳

サイトをきれいにして再公開したあとも、検索結果に残ったスパムページへの対応に時間がかかります。復旧のスケジュールは、検索結果の後始末まで含めて考えておきましょう。

断言はできませんが、サイトが改ざんされる例として多いのは、パスワードの使い回しと、古いバージョンのまま放置されたサイトです。保守契約を結んでいる場合は、セキュリティ対策がどのレベルまで含まれているかを確認してみてください。

依頼する場合は、駆除だけでなく、侵入経路の特定と再発防止策まで含まれているか、作業内容の報告があるかを確認しましょう。

復旧後に続けたい再発防止策

復旧が終わっても、侵入口となった弱点を残せば同じことが起こります。WordPress.orgのドキュメントも、復旧後は推奨されているセキュリティ対策（Hardening WordPress）を実施するよう案内しています。

• 管理画面に二段階認証を設定し、パスワードを使い回さない（具体的な設定はWordPressのログイン画面を守る方法）
• 本体・テーマ・プラグインを最新に保ち、使わないものは削除する
• サーバーの外にもバックアップを保管し、長めに残す世代を用意する
• Search Consoleを登録し、site:自社ドメイン での検索結果と、サイトの見た目を定期的に確認する
• 保守契約がある場合は、更新作業・監視・改ざん時の対応がどこまで含まれているかを確認する

再発防止策の全体像と優先順位は、WordPressのセキュリティ対策ガイドにまとめています。

まとめ｜WordPressの復旧は「入口を閉じてから、場所ごとに点検」

• 復旧は、公開停止・証拠保全・連絡などの初動を終えてから始めます。作業に使うパソコンのウイルススキャンも忘れずに行います。
• ハッキング前のきれいなバックアップがあれば戻せますが、戻しただけでは侵入口が残ります。
• 手順は、感染時のコピー → 全アクセスの無効化（パスワード・セキュリティキー・不審なユーザー） → 本体・プラグイン・テーマの入れ替え → 残ったファイルとデータベースの点検 → 更新とパスワードの再変更 → 検索結果の後始末、の順です。
• 本体は同じバージョンを、管理画面の再インストールではなくFTP/SFTPで置き換えます（WordPress.org）。
• 当社の事例では、原因はパスワードの使い回しで、復旧までに約2週間かかりました。いちばん大きかったのは、早く気づけたことです。

参考資料・出典

（いずれも2026年10月確認）

• WordPress.org「FAQ My site was hacked」（最終更新 2026年7月26日） https://wordpress.org/documentation/article/faq-my-site-was-hacked/
• WordPress.org「Secret key generator」 https://api.wordpress.org/secret-key/1.1/salt/
• WordPress Developer Resources「wp core verify-checksums」（WP-CLI Commands） https://developer.wordpress.org/cli/commands/core/verify-checksums/
• web.dev「Clean and maintain your site」 https://web.dev/articles/clean-and-maintain-your-site
• Search Console ヘルプ「削除ツール」 https://support.google.com/webmasters/answer/9689846?hl=ja
• Google 検索セントラル「Google に再クロールを依頼する」（最終更新 2025年12月31日） https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl?hl=ja