WordPressのサイトを開いた瞬間、いつものトップページではなく、
真っ黒な画面に「Hacked by CoupDeGrace」と表示されていたら、頭が真っ白になると思います。
「ページを消せば直るのでは」「お客様に見られる前に早く戻したい」
そう感じるのは自然です。けれど、焦って見えているページだけを削除すると、かえって本当の痕跡を見逃すことがあります。
今回の事例で怖かったのは、黒い改ざん画面そのものではありません。
管理画面から不正ページを削除したあとも、データベースの奥に122件の不審なchangeset関連データと、36件のoEmbedキャッシュが残っていたことです。
WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、画面上の改ざんだけでなく、データベースやファイルに残る見えない痕跡まで初心者向けに解説します。
- WordPressが「Hacked by CoupDeGrace」に改ざんされた実例
- wp2shell攻撃と一致したデータベース上の痕跡
- 不正ページだけ削除しても復旧と言えない理由
- 初心者がやってはいけない危険な対応
- 安全に復旧するために確認すべき流れ
WordPressの改ざん復旧で大切なのは、見た目を戻すことではありません。
なぜ改ざんされたのかを調べ、見えない不正データを取り除き、再び侵入されない状態に近づけることです。
この記事では、実際に確認した画面とデータベースの痕跡をもとに、
「どこまで調べてから復旧と言えるのか」をわかりやすく整理します。

WordPressがHacked by CoupDeGraceに改ざんされた時の結論
WordPressが「Hacked by CoupDeGrace」に改ざんされた時は、
不正ページを消す前に、証拠保全と侵害範囲の確認を優先すべきです。
理由は単純です。画面に見えている改ざんページは、被害の一部にすぎないからです。
攻撃者が作った投稿、キャッシュ、管理者ユーザー、不審ファイル、データベース上の痕跡が別の場所に残っている可能性があります。
- 「Hacked by CoupDeGrace」という公開ページが4件作成されていた
- 非公開投稿を含めると同じ改ざん文字列を含む投稿が計6件あった
- 改ざん内容を含むoEmbedキャッシュが36件残っていた
- 2020年1月1日に日付偽装されたcustomize_changeset関連が122件見つかった
- 実際の更新日時は2026年7月22日から8月27日に集中していた
黒い改ざん画面は、火事でいえば煙のようなものです。
煙だけを消しても、壁の内側で火が残っていれば、また燃え広がります。

不正固定ページは4件公開されていた
管理画面の固定ページ一覧には、本来存在しない「Hacked by CoupDeGrace」というページが複数並んでいました。
しかも、公開日時を見ると短い時間に連続して作成されています。
この画面だけを見ると、固定ページをゴミ箱に入れれば終わりに見えます。
しかし今回は、そこから先の調査で、管理画面には出てこない不審データが見つかりました。
表面だけ直すと見えない痕跡が残る
WordPressの「投稿」や「固定ページ」は、データベース内の一部です。
`wp_posts` には、公開記事だけでなく、リビジョン、添付ファイル、自動保存、oEmbedキャッシュ、カスタマイザー変更履歴なども保存されます。
つまり、管理画面で見えている不正ページを消しても、
攻撃の過程で作られた別のデータまで一緒に消えるとは限りません。
wp2shell攻撃と一致したWordPress内部の痕跡
今回の事例は、データベースに残った複数の痕跡が、
WordPress本体の脆弱性を悪用するwp2shell攻撃チェーンの特徴と一致していました。
wp2shellは、WordPress本体に存在した2つの脆弱性を組み合わせる攻撃として報告されています。
脆弱なプラグインやテーマがなくても、対象バージョンのWordPress本体が攻撃対象になり得る点が危険でした。
- CVE-2026-60137:ログイン不要で悪用され得るSQLインジェクション
- CVE-2026-63030:REST APIのバッチ処理の混乱を悪用し、攻撃の影響を拡大する脆弱性
- 修正版はWordPress 6.8.6、6.9.5、7.0.2として公開
- WordPress公式は深刻度を考慮し、影響サイトへの強制自動更新も有効化
Wordfenceは、2026年7月29日の技術解説で、同社の一部テレメトリだけでも1,100万件を超える攻撃試行を遮断したと報告しています。
ただし、これは侵害に成功したサイト数ではなく、観測・遮断された攻撃試行数です。
oEmbedキャッシュが36件残っていた
oEmbedは、URLを貼るだけでYouTubeや別ページなどを埋め込めるWordPressの機能です。
表示を速くするため、WordPressは埋め込み結果をキャッシュとして保存することがあります。
今回、改ざんページを管理画面から削除したあとも、
攻撃者名や改ざん内容を含むoEmbedキャッシュが36件残っていました。
元のページを消しても、そこから派生したキャッシュは残ることがあります。
ここを見ないまま復旧完了にすると、データベース内に不正な痕跡を抱えたまま運用を再開することになります。
customize_changeset関連が122件見つかった
さらに調査すると、`post_date` がすべて `2020-01-01 00:00:00` に設定された不審データが見つかりました。
ところが、実際の更新日時である `post_modified` は2026年7月22日から8月27日に集中していました。

- customize_changeset本体:116件
- changesetを親に持つ通常投稿:6件
- 合計:122件
- タイトルは `changeset`、`c`、`cs`、`ch`、`x` など不自然な短い文字列
公開日だけを見ると、2020年に作られた古いデータに見えます。
しかし、更新日時、投稿タイプ、公開状態、タイトル、親子関係を組み合わせると、通常運用のデータとは考えにくい状態でした。
WordPress改ざんで管理画面削除だけでは終わらない理由
WordPress改ざんの復旧は、「不正ページを消したか」ではなく、
「同じ条件で再検索して0件になったか」まで確認して初めて前に進めます。
今回も、管理画面上の不正ページを削除しただけなら数分で見た目は戻せました。
しかし、データベースを直接確認しなければ、36件のキャッシュと122件のchangeset関連は残ったままでした。
改ざん文字列をデータベースから検索する
今回の調査では、投稿タイトルや本文だけでなく、抜粋やキャッシュまで含めて検索しました。
代表的には、次のような条件で確認しています。
SELECT
ID,
post_parent,
post_type,
post_status,
post_date,
post_modified,
post_author,
post_name,
post_title
FROM wp_posts
WHERE post_title LIKE '%CoupDeGrace%'
OR post_content LIKE '%CoupDeGrace%'
OR post_excerpt LIKE '%CoupDeGrace%'
OR post_content LIKE '%L4663r666h05t%'
ORDER BY ID;この検索により、公開ページだけでなく、非公開投稿やoEmbedキャッシュも確認できました。
テーブル接頭辞が `wp_` ではない環境では、実際の接頭辞へ置き換える必要があります。
changesetと親子投稿をまとめて確認する
日付偽装を見逃さないために、公開日だけでなく、更新日時と親子関係も確認しました。
次のように `customize_changeset` 本体と、それを親に持つ投稿をまとめて見ると、不自然な構造に気づきやすくなります。
SELECT
c.ID,
c.post_parent,
c.post_type,
c.post_status,
c.post_date,
c.post_modified,
c.post_author,
c.post_name,
c.post_title,
parent.post_type AS parent_type
FROM wp_posts AS c
LEFT JOIN wp_posts AS parent
ON parent.ID = c.post_parent
WHERE c.post_date = '2020-01-01 00:00:00'
AND (
c.post_type = 'customize_changeset'
OR parent.post_type = 'customize_changeset'
)
ORDER BY c.ID;別のサイトで同じSQLを実行して結果が出たからといって、すべて削除してよいとは限りません。正常なカスタマイザー履歴が含まれる可能性もあるため、内容・日時・親子関係・バックアップを確認して判断してください。
削除後に0件確認を行う
復旧作業では、削除したことよりも、削除条件で再検索して0件になったことが重要です。
今回も、改ざん文字列を含む投稿・キャッシュと、不審なchangeset関連がどちらも0件になったことを確認しました。
ただし、データベース上の該当件数が0件になっても、それだけで完全復旧とは判断しません。
ファイル、管理者ユーザー、パスワード、ログ、WordPress本体の更新状況まで確認して、ようやく復旧に近づきます。
WordPress改ざん復旧で実際に確認した流れ
WordPress改ざん復旧は、慌てて消すより、順番を守る方が結果的に早く安全です。
証拠を残し、見える被害と見えない被害を分けて確認し、再感染経路をつぶしていきます。
- ファイルとデータベースをバックアップして証拠を保全する
- 管理画面で投稿・固定ページ・ユーザー・プラグイン・テーマを確認する
- データベースから改ざん文字列、不審な投稿タイプ、キャッシュを検索する
- post_dateだけでなくpost_modifiedと親子関係を見る
- 関連するpostmeta、term_relationships、コメント、リビジョンも確認する
- 削除後に同じ条件で再検索し、0件を確認する
- ファイル改ざん、不正管理者、パスワード、SALT、ログ、キャッシュを確認する
特に大切なのは、最初にバックアップを取ることです。
削除を先に行うと、侵入経路や更新日時を調べるための証拠まで失う可能性があります。
また、WordPress本体を更新しただけで安心するのも危険です。
更新は新たな侵入を防ぐ対策であり、すでに作られた不正管理者やバックドアを自動的に消すものではありません。
ファイル側に残るバックドアも見る
wp2shellの完全な攻撃チェーンでは、攻撃者が管理者アカウントを作成し、通常の管理者機能を使って不正なプラグインをアップロードできる可能性があります。
そのため、データベースだけ見て終わるのは危険です。
- `wp-content/uploads` にPHPファイルが置かれていないか
- `wp-content/mu-plugins` に身に覚えのないファイルがないか
- プラグインやテーマに最近追加された不審ファイルがないか
- `.htaccess`、`wp-config.php`、`index.php` に不正コードがないか
- WordPressコアファイルが改変されていないか
管理者ユーザーと認証情報も見直す
身に覚えのない管理者ユーザーが残っていると、画面を直しても再びログインされます。
全管理者のパスワード変更、不要ユーザーの削除、セッションの破棄、認証用SALTの更新まで行う必要があります。
また、FTP、サーバーパネル、データベース、メールアカウントなど、WordPress以外の認証情報も確認対象です。
侵入経路がWordPress本体だけとは限らないためです。
WordPress改ざんでやってはいけない5つの対応
WordPressが改ざんされた時ほど、自己判断で一気に消す対応は避けるべきです。
焦りは当然ですが、順番を間違えると証拠を失い、復旧の難易度が上がります。
- 不正ページだけ削除して安心する
- WordPressを更新しただけで復旧完了にする
- セキュリティプラグインを入れただけで安心する
- バックアップを取らずにデータベースを直接削除する
- 画面が戻った時点で検索結果やキャッシュを確認しない
今回のように、改ざん画面の裏側に多数のキャッシュやchangesetが残ることがあります。
「表示が戻った」は、復旧完了ではありません。
検索結果、ブラウザキャッシュ、キャッシュプラグイン、サーバーキャッシュ、CDNにも改ざんタイトルが残る場合があります。
お客様や取引先が古い改ざん表示を見てしまえば、信頼を失う原因になります。
閲覧したパソコンが必ず感染するわけではない
WordPressサイトが改ざんされたことと、閲覧したパソコンが自動的に感染したことは同じではありません。
今回確認したスクリーンショットでは、主に改ざんメッセージが表示されていました。
ただし、スクリーンショットだけでは、別のJavaScript、外部通信、ダウンロード処理まで存在しなかったとは断定できません。
改ざんサイトを開いた場合は、不審な通知許可、ファイルのダウンロード、パスワード入力、アプリのインストールは避けてください。
WordPressをwp2shell型の攻撃から守る対策
WordPressを守る基本は、最新版に更新し、更新が成功していることを確認し、侵害後の痕跡を継続監視することです。
自動更新を有効にしているだけでは不十分です。
ファイル権限、容量不足、通信エラー、独自設定などにより、自動更新に失敗することがあります。
管理画面やサーバー上のバージョン情報を直接確認してください。
- WordPress本体を修正版以降へ更新する
- 自動更新が実際に成功したか確認する
- `/wp-json/batch/v1` や `?rest_route=/batch/v1` への不審アクセスを確認する
- 不明な管理者ユーザーやプラグイン追加を監視する
- 同じサーバー内だけでなく、外部にもバックアップを保存する
ただし、ログに該当URLがあるだけで侵害成功とは限りません。
探索、遮断済みの攻撃、正常通信、成功した侵害を分けて判断する必要があります。
逆に、ログに見つからないから安全とも言い切れません。
ログの保存期間が短い、ローテーションで消えている、攻撃者が痕跡を消している可能性もあるためです。
WordPress改ざん復旧でよくある質問
WordPress改ざんは見た目が戻ってからが本番です
WordPressが「Hacked by CoupDeGrace」に改ざんされた今回の事例では、
黒い画面を消したあとに、本当に怖い痕跡が見つかりました。
36件のoEmbedキャッシュ、122件の不審なchangeset関連、日付偽装、特殊な親子関係。
どれも、通常の投稿一覧だけ見ていたら見逃していた可能性があります。
サイトが表示されたから直った。管理画面からページを消したから終わった。
そう判断してしまうと、不正データやバックドアを抱えたまま運用を再開することになります。
WordPress復旧で大切なのは、表面を整えることではありません。
侵入の可能性を調べ、見えない痕跡を取り除き、再発しにくい状態へ戻すことです。
WordPressの改ざん復旧が自分で判断できない時は

ホームページの乗っ取り・改ざん・マルウェア感染でお困りなら、
クイックレスキューが復旧と再発防止を支援します。
- 「Hacked by〜」というページが表示された
- 身に覚えのない投稿や固定ページが作られた
- 不明な管理者ユーザーが増えている
- 削除しても不正ページやファイルが復活する
- データベースやファイルをどこまで見ればよいかわからない
- 自分で触って壊すのが怖い
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心







