WordPressが乗っ取られていないか確認する方法｜改ざん・不正ユーザー・ログのチェック手順

WordPressを最新版へ更新しても更新前に作られた不正な管理者ユーザーやバックドア用のファイルが自動で消えるわけではありません。

「知らない管理者が増えている」「見覚えのないページへ転送される」「セキュリティ警告が出た」といった異変がある場合は、管理者ユーザー、プラグインとテーマ、ファイル、アクセスログを順番に確認します。

この記事では管理画面だけで確認できる項目から、WP-CLIやアクセスログを使った確認方法、怪しい形跡を見つけた場合の初動対応までまとめました。

この記事を作成したきっかけは2026年7月に公開されたWordPressの脆弱性、通称「wp2shell」です。自動更新の仕組みや当時の経緯は前回の記事で詳しく解説しています。

あわせて読みたい

WordPressの自動更新を無効にしていても強制更新された理由と仕組みを解説 WordPressで自動更新をオフにしていても更新される理由を解説。マイナー・セキュリティ更新の仕様や緊急時の強制更新、自動更新を停止する設定方法、更新後に確認したいポイントをまとめています。

この記事でわかること

• WordPressが侵害されていないか確認する順序
• 不審な管理者、プラグイン、ファイルの見分け方
• アクセスログやWP-CLIを使った確認方法
• 怪しい形跡が見つかった場合の初動対応

更新済みでも侵害の確認が必要な理由

WordPressをセキュリティ修正版へ更新するとその修正版で解消された脆弱性を使った攻撃を受ける可能性は下がります。とはいえ、更新前に作られた不正な管理者ユーザー、プラグイン、バックドア用のファイルまでは自動的に削除されません。

調査では、不審な挙動に気づいた時刻の前後を確認します。重大な脆弱性の公表後に確認する場合は公表日から修正版への更新完了時刻までを重点的に見て、可能であれば数日前までログを遡ってください。

侵害の形跡をチェックする

WordPressの現在のバージョンを確認する

ダッシュボードの「更新」を開き現在利用しているWordPressがサポート中の最新版になっているか確認します。

ここで確認するのは単にバージョン番号が新しいかどうかだけではありません。WordPressから届いた自動更新メール、レンタルサーバーの更新履歴、バックアップ履歴などから更新完了時刻を確認し、アクセスログと照合できるように控えておきます。

最新版になっていれば、すでに修正された脆弱性を使った新たな攻撃を受ける可能性は下げられます。が、更新前に侵害されていなかったことまで証明できるわけではありません。

古いバージョンのままの場合は、調査と並行して更新します。すでに不審なユーザーやファイルが見つかっている場合は、先にファイル、データベース、アクセスログを保存してください。

見覚えのない管理者ユーザーを確認する

「ユーザー」から「ユーザー一覧」を開き権限を管理者に絞り込みます。ユーザー名、表示名、メールアドレス、権限に心当たりがあるか確認してください。

WordPressの標準画面では登録日が表示されません。登録日時まで確認する場合はWP-CLIを使います。

wp user list \
    --role=administrator \
    --fields=ID,user_login,user_email,user_registered,roles \
    --format=table

プラグインとmu-pluginsを確認する

インストール済みプラグインを開き次の点を確認します。

• 自分や管理担当者が導入していないプラグイン
• WordPress更新前後に突然追加されたプラグイン
• 配布元や用途を確認できないプラグイン
• 無効化されているが設置した覚えのないプラグイン

通常のプラグイン一覧だけでなくwp-content/mu-pluginsも確認します。Must-Useプラグインは通常のプラグインとは扱いが異なり、管理画面から無効化できません。

怪しいプラグインを見つけてもすぐに削除せず、フォルダ名、ファイル一覧、更新日時を記録し、可能であればコピーを保存してください。

WP-CLIが使える場合はWordPress.orgで配布されているプラグインのファイルをチェックできます。

wp plugin verify-checksums --all

mu-pluginsや独自・有料プラグインなどWordPress.orgのチェックサムが用意されていないものは確認できない場合があります。

テーマを確認する

使用中のテーマ、子テーマ、親テーマ、未使用テーマを確認します。

見覚えのないテーマがあっても、その場ですぐに削除しないでください。使用中の子テーマが必要としている親テーマや、復旧時に使う予備テーマである可能性があります。

まずフォルダ名と更新日時を記録し現在有効なテーマと親子関係を確認します。そのうえで、配布元の正規ファイルと比較します。

子テーマを使っている場合はfunctions.php、テンプレートファイル、独自のJavaScriptに、追加した覚えのないコードがないか確認してください。

uploadsフォルダの実行ファイルを確認する

wp-content/uploads は通常は画像、動画、PDFなどを保存する場所です。PHPなどの実行可能ファイルが置かれている場合は、優先して調査します。

ただ、PHPファイルが存在するだけで侵害確定とはいえません。一部のプラグインがファイルを生成している可能性もあるため、ファイル名、保存場所、更新日時、作成元のプラグインを確認してください。

SSHが使える場合は次のコマンドで実行可能な拡張子を探せます。

find wp-content/uploads -type f \
  \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) \
  -print

見つかったファイルをブラウザから開かないでください。削除前にパスと更新日時を記録して必要に応じてホスティング会社や専門家へ確認を依頼します。

コアとプラグインの改ざんを確認する

WordPressコアは公式のチェックサムと比較できます。

wp core verify-checksums

ルートディレクトリ内の非標準ファイルも確認する場合は次のコマンドを使います。

wp core verify-checksums --include-root

--include-rootで警告されたファイルがすべて不正とは限りません。正規の設定ファイル、認証ファイル、ホスティング会社が設置したファイルなども警告対象になるため、自動的に削除しないでください。

このコマンドで確認できるのは主にWordPressコアです。wp-content、wp-config.php、データベース内のユーザーや設定までは確認できません。

セキュリティプラグインのスキャンは補完手段として利用できますが、コアチェックサムや手動確認を完全に置き換えるものではありません。

アクセスログとWAFログを確認する

アクセスログやWAFログでは、普段と異なるURLへのアクセスや、短時間に集中しているリクエストがないか確認します。

特に確認したいのは、次のような記録です。

• 普段利用していないURLへのPOSTリクエスト
• 管理画面やREST APIへ短時間に集中しているアクセス
• 不審なユーザーやファイルが作成された時刻と近いアクセス
• WAFやセキュリティ機能が遮断または警告したリクエスト

1件のログだけで判断せず、リクエスト日時、HTTPメソッド、ステータスコード、送信元IPを確認します。不審なユーザーやファイルが見つかっている場合は、それらの作成時刻とも照らし合わせてください。

ログに不審なアクセスが残っていても、攻撃が成功したとは限りません。探索だけで終わったアクセスや、WAFによって遮断されたリクエスト、正規のプラグインによる通信の可能性もあります。

POST /wp-json/batch/v1
POST /?rest_route=/batch/v1

該当するログが見つからない場合もそれだけで安全とは判断できません。ログの保存期間が過ぎている、サーバー側でリクエスト本文を記録していない、攻撃者が痕跡を削除したといった可能性が残ります。

確認結果の判断目安

ここまでの確認結果は次のように判断します。

怪しい形跡が見つかったら

怪しいユーザーやファイルを見つけても、最初から削除や上書きを始めないでください。先に現在の状態を保存します。

1. ファイル、データベース、アクセスログ、WAFログのコピーを取得する
2. 保存したデータに「侵害の疑いあり」と明記し、通常の復元用バックアップと分ける
3. 必要に応じてメンテナンス状態にするか、ホスティング会社へ一時的なアクセス制限を依頼する
4. クリーンな端末から認証情報を変更する

変更対象にはWordPress管理者、ホスティング管理画面、SSH・SFTP・FTP、データベース、パスワード再設定に使うメールアカウントを含めます。

データベースのパスワードを変更した場合はwp-config.php の設定も変更します。

ログインセッションをすべて無効にする

WordPressの認証キーとSALTは、ログインCookieの署名と検証に使われる秘密値です。これらを変更すると、発行済みのログインCookieが無効になり、ログイン中のユーザーを強制的にログアウトさせられます。

WP-CLIでは次のコマンドを使います。

wp config shuffle-salts

アプリケーションパスワードを利用している場合は各ユーザーのプロフィール画面から不要なものを取り消します。外部サービス用のAPIキーやトークンがWordPress内に保存されていた場合は、サービス提供元側でも再発行してください。

バックアップから復元するときの注意点

戻すべきなのは「脆弱なバージョンになる前」ではなく「侵害前と判断できる時点」のバックアップです。

復元する場合はファイルだけでなくデータベースも対象にします。バックアップのWordPress、プラグイン、テーマが古い場合はインターネットへ再公開する前に修正版へ更新してください。

復元後も、管理者ユーザー、プラグイン、テーマ、uploadsフォルダ、チェックサム、アクセスログをもう一度確認します。侵害時に使われていた可能性があるパスワード、SALT、アプリケーションパスワード、APIキーは再利用しません。

WordPress本体を再インストールするだけでは不十分な理由

「怪しかったらとりあえずWordPress本体を再インストールすればいいのでは」と思う方もいるかもしれません。ですが、コアファイルの再インストールで直せるのはコア部分だけです。

• データベースに直接追加された不正な管理者ユーザー
• uploadsフォルダなどに置かれたPHPの不正ファイル（いわゆるWebシェル）
• 不正なプラグインやテーマ
• 投稿やオプションテーブルに埋め込まれた不正なスクリプト

これらはコアファイルの再インストールでは触れられない部分です。コアの再インストールは「土台をきれいにする」効果はありますが、それだけで侵害への対応が完了するわけではない、と考えておいたほうが安全です。

2026年7月に発生したwp2shellの事例

この記事を作成するきっかけになったのが2026年7月に公表されたWordPressの脆弱性です。WordPress.orgは2026年7月17日にWordPressのバージョン「7.0.2」「6.9.5」「6.8.6」を公開しました。修正されたのは「CVE-2026-63030」「CVE-2026-60137」の2件です。

WordPress 6.9系と7.0系ではこの2件を組み合わせることでログインしていない攻撃者が標準構成のWordPress上でコードを実行できる可能性がありました。この攻撃チェーンは通称「wp2shell」と呼ばれています。

WordPress 6.8系が影響を受けるのはCVE-2026-60137のSQLインジェクションです。6.8系はREST APIのルート判定に関する脆弱性の対象ではないため、6.9系や7.0系と同じリモートコード実行の攻撃チェーンには該当しません。

WordPress 7.1 beta1も2件の影響を受け、7.1 beta2で修正されています。通常の本番サイトでベータ版を使うことは少ないものの、当時の検証環境を残している場合はバージョンを確認してください。

修正版が公開された2026年7月17日には、REST APIのバッチエンドポイントを調べるアクセスと、SQLインジェクションを試みるアクセスが観測されました。2026年7月21日には、2件ともCISAのKEVカタログへ追加されています。

セキュリティ修正版への更新と更新前に侵害されていないかの確認は別の作業だということですね。更新後も不正なユーザーやファイルが残っていないか確認する必要があります。

よくある質問

判断に迷ったときの結論

• 更新済みでも、更新前の侵害までは否定できない
• 不審なものを見つけても、削除前に証拠を保存する
• 復元する場合は「侵害前と判断できる時点」のバックアップを使う