「WordPressのユーザー一覧には知らない管理者がいないのに、管理者として動いた形跡がある」「データベースを見ると、見覚えのない権限情報が残っている」と不安になっていませんか？
WordPressの権限は、ユーザー本体だけで決まりません。
通常はデータベースのwp_usermetaにあるcapabilitiesと、サイトごとの接頭辞を組み合わせて判定されます。
ただし、usermetaに不審な行があるだけで「隠し管理者がログインできる」と断定するのも危険です。
管理画面、WP-CLI、wp_users、有効な接頭辞、キャッシュ、マルチサイト構成を同じ時点で照合する必要があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、権限情報を壊さず確認し、不正な管理者権限だけを安全に復旧する順序を解説します。
wp_usermetaで管理者権限が保存される仕組み- ユーザー一覧とデータベースの結果が違う時の確認順
- 接頭辞・重複メタ・マルチサイトを見落とさない方法
- WP-CLIと読み取りSQLで証拠を壊さず調べる手順
- 不正権限を除去し、再生成元まで止める復旧方法
結論から言うと、最初にやるべきことはwp_usermetaの直接編集ではありません。
現状を保全し、WordPressが実際に参照している権限と画面表示の差を確定してから、対象を限定して修正するのが正解です。
この順番を守れば、正規の管理者まで消したり、シリアライズされた値を壊したりする事故を避けやすくなります。
まずはWordPressの権限がどこで決まるのかを整理しましょう。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressのusermeta改ざんはユーザー一覧だけで判断しない
WordPressの管理者権限を調べる時は、wp_usersとwp_usermetaを必ずセットで確認します。wp_usersにはログイン名やメールアドレスなどがあり、役割や追加権限は主にwp_usermetaへ保存されるためです。
capabilitiesが現在の役割を決める中心情報
単一サイトで接頭辞がwp_なら、代表的な権限キーはwp_capabilitiesです。
管理者では、値の中にadministratorが有効な役割として保存されます。
wp_user_levelも見つかりますが、これは古い互換性のため残る値です。
数字が高い行だけを見て管理者と断定せず、capabilities、WordPressの認識するroles、実際に許可される操作を合わせて判断してください。
wp_users.IDと対象ユーザーの実在- 稼働サイトの接頭辞に対応する
capabilities - 管理画面またはWP-CLIが返すroles
- 管理画面操作・API・ログに残る実際の権限使用
不審なusermetaがあってもログイン可能とは限らない
削除済みユーザーのusermetaだけが孤立して残るケースや、過去のテーブル接頭辞に対応する権限キーが残るケースがあります。
対応するwp_users行がなければ、そのメタ行だけで通常のWordPressログインは成立しません。
一方で、正規ユーザーに見えるIDへ不正な管理者権限が追加されている場合は緊急性が高くなります。
攻撃者が新しいユーザーを増やさず、既存アカウントの権限だけを変更している可能性があるためです。
WordPressのusermeta調査前に証拠と復元手段を残す
wp_usermetaを調べる前に、ファイルとデータベースの原本を保存してください。
不正権限の作成時刻や侵入経路は、ユーザー行だけでなく、アクセスログ、プラグイン、テーマ、予約処理に残る情報と合わせて追うからです。
現在の状態を同じ時刻で記録する
ユーザー一覧のスクリーンショット、WP-CLIの一覧、対象テーブルのエクスポート、確認時刻を同じ調査メモへ残します。
画面を見た後にキャッシュ削除やプラグイン停止を先に行うと、差分が設定変更によるものか侵害によるものか分かりにくくなります。
- WordPressファイル一式とデータベース全体のバックアップ
wp_usersとwp_usermetaの個別エクスポート- 管理画面・WP-CLI・SQLの確認結果と実行時刻
- Webサーバー、WAF、認証、監査ログの保管
- 戻し方と復元先を確認した作業用コピー
不審ユーザーの削除やパスワード変更を急がない
被害が進行中なら、公開制限やログイン経路の一時制限など、被害拡大を止める措置は必要です。
ただし証拠を残す前にユーザー削除、DB行削除、ログ全消去を行うと、作成元や利用時刻を追いにくくなります。
正規ユーザーか判断できない場合は、先にサイト所有者と管理担当者へ確認します。
制作会社、保守会社、決済・会員機能、外部APIが専用ユーザーを使うこともあるため、見慣れない名前だけで削除してはいけません。
WordPressのusermetaで管理者権限を確認する5項目
wp_usermetaでは、値だけでなくユーザーID、メタキー、接頭辞、行数、サイト構成を順番に確認します。
一部だけを見ると、古いデータを現行権限と誤認したり、別サイトの管理者を不正ユーザーと誤認したりするためです。
1. 稼働中のテーブル接頭辞を確定する
最初にwp-config.phpの$table_prefixと、実際にWordPressが使っているテーブルを照合します。
接頭辞がsecure_なら、権限キーも通常はsecure_capabilitiesとsecure_user_levelです。
移行や復旧を繰り返したサイトでは、wp_、old_、backup_など複数のテーブル群が残ることがあります。
古いテーブルを直しても稼働サイトは変わらず、逆に調査対象を取り違える原因になります。
2. user_idとwp_users.IDを突き合わせる
権限メタのuser_idが、どのwp_users.IDへ対応するか確認します。
ログイン名、メール、登録日、表示名、所有コンテンツを調べ、正規ユーザー・不審ユーザー・孤立メタに分類してください。
ログイン名やメールは攻撃者が正規らしく見せられるため、それだけでは本人確認になりません。
運営者の申告、作成ログ、過去のバックアップ、利用端末・IP、管理作業履歴を合わせて判断します。
3. capabilitiesとuser_levelを別々に確認する
capabilitiesは、PHPのシリアライズ形式で役割や個別権限を保持することがあります。
手作業で文字数部分だけを書き換えると値が壊れるため、phpMyAdminのセルを直接編集してはいけません。
user_levelは互換用であり、単独の数字だけで現在の権限を決めません。
両方が不一致なら、不完全な移行、失敗した権限変更、不正操作、プラグイン独自処理を疑い、WordPress APIが返すrolesと比較します。
4. 同じmeta_keyの重複行を探す
同じユーザーに同じcapabilitiesキーが複数ある場合は、重複の作成経路を調べます。
移行ツールや不具合で増えた可能性もあるため、後から作られた行を機械的に不正と決めつけないでください。
重複行では、umeta_id、値、バックアップとの差分、作成時期を推定できるログ、実際のWordPressの読み取り結果を記録します。
どの行が参照されるかを曖昧なまま削除すると、正規権限が消えるおそれがあります。
5. マルチサイトのサイト別キーを確認する
WordPressマルチサイトでは、ネットワーク内のサイトごとにwp_2_capabilitiesのようなキーが使われます。
メインサイトで権限が見えなくても、別サイトでは管理者として登録されている場合があります。
逆に、別サイトの正規管理者をメインサイトの不正権限と誤認してはいけません。
サイトID、対象URL、そのユーザーが所属すべきサイト、スーパー管理者の扱いを確認してから判定します。
WordPress管理画面に権限が見えにくい原因を切り分ける
通常のWordPressでは、有効な管理者roleを持つユーザーはユーザー一覧へ反映されます。
DB上の権限と画面が一致しないなら、「隠し管理者」という言葉だけで済ませず、表示経路と参照先の違いを調べるべきです。
別接頭辞・別サイト・別DBを見ていないか
phpMyAdminで開いたDBと、公開中WordPressが接続するDBが同じか確認します。
ステージング、旧サーバー、読み取りレプリカ、移行前DBを見ていると、管理画面との結果は当然一致しません。
WordPress側ではサイトURL、DB名、テーブル接頭辞を記録し、DB側では対象テーブルの更新状況を確認します。
「同じドメインだから同じDB」と推測せず、設定と実体を照合してください。
オブジェクトキャッシュが古い権限を返していないか
RedisやMemcachedなどの永続オブジェクトキャッシュを使うサイトでは、DBを直接変更した後に古いユーザー情報が残ることがあります。
だからこそDB直編集を避け、WordPressのAPIや管理画面から正規の権限変更を行うことが重要です。
確認時は、DBの値、WP-CLIが返すroles、管理画面の表示を順に記録します。
キャッシュを消す場合も、実行前後の結果を残し、変化した箇所を特定してください。
プラグインや不正コードが一覧を変更していないか
管理画面のユーザー一覧は、プラグインやテーマのフックで検索条件・列・表示内容を変更できます。
不正コードがユーザーを除外する可能性もありますが、保守プラグインや会員機能が意図して表示を調整する場合もあります。
全プラグインをいきなり停止せず、コード検索、最近の更新、mu-plugins、drop-in、テーマ、監査ログを確認します。
表示だけを直しても、不正権限の追加元やバックドアが残れば再発します。
- 公開中サイトが実際に接続しているDBと接頭辞
- 単一サイトかマルチサイトか、対象のサイトID
- Redis・Memcachedなどのオブジェクトキャッシュ
- ユーザー一覧へ作用するプラグイン・テーマ・mu-plugins
- 管理画面とWP-CLIを実行したWordPress環境の一致
WordPressのusermetaをWP-CLIと読み取りSQLで確認する
安全な調査では、最初の操作を読み取り専用にします。
WP-CLIでWordPressが認識する役割を確認し、次にSQLで保存行と重複を調べると、アプリケーション側とDB側の差を把握できます。
WP-CLIでWordPressが認識するrolesを一覧にする
WP-CLIは、必ず対象サイトのWordPressルートで実行します。
マルチサイトや別URLを扱う場合は、対象URLを明示し、どのサイトの権限を見ているか記録してください。
wp db prefix
wp user list --fields=ID,user_login,user_email,roles --format=table
wp user meta list 123 --format=table最初のコマンドで接頭辞を確認し、2つ目でWordPressが認識するrolesを取得します。
3つ目の123は調査対象のユーザーIDへ置き換え、capabilitiesとuser_levelを含むメタ行を確認します。
出力にはメールアドレスなどが含まれるため、共有前にマスキングしてください。
チャット、公開チケット、記事へ、実在ユーザーのメールや認証情報を貼り付けてはいけません。
SQLはSELECTだけで保存状態を確認する
DB側では、稼働サイトの接頭辞へ置き換えたうえでSELECTを使います。
次の例はwp_の場合なので、実環境の接頭辞が異なるならテーブル名とメタキーを両方変更してください。
SELECT user_id, umeta_id, meta_key, meta_value
FROM wp_usermeta
WHERE meta_key IN ('wp_capabilities', 'wp_user_level')
ORDER BY user_id, meta_key, umeta_id;この結果で、各ユーザーIDの権限メタと互換用レベルを確認できます。meta_valueにはシリアライズ値が含まれるため、表計算ソフトで自動変換せず、原文のまま保存してください。
重複行はCOUNTで抽出してから個別確認する
同じユーザー・同じメタキーが複数あるかは、集計だけで確認できます。
重複が見つかっても、この段階では削除せず、該当するumeta_idと値を個別に記録します。
SELECT user_id, meta_key, COUNT(*) AS rows_count
FROM wp_usermeta
WHERE meta_key IN ('wp_capabilities', 'wp_user_level')
GROUP BY user_id, meta_key
HAVING COUNT(*) > 1;重複が0件でも安全とは限りません。
正規ユーザーの権限が1行だけ不正変更されているケースや、プラグインが実行時に追加権限を与えるケースもあるため、ログとコード調査が必要です。
WordPressの不正な管理者権限を壊さず復旧する
不正な管理者権限の復旧は、権限行の削除だけでは終わりません。
対象ユーザーを確定し、利用中セッションを止め、権限を正規状態へ戻し、追加元を除去し、同じ異常が再発しないことまで確認します。
正規ユーザーと不正ユーザーで対応を分ける
正規ユーザーが不正に昇格されている場合は、そのアカウントを削除すると所有コンテンツや業務連携へ影響します。
正しい役割へ戻し、パスワード・アプリケーションパスワード・セッションを見直し、本人の端末やメールも確認します。
完全な不正ユーザーなら、証拠保全と所有コンテンツの確認後に削除を検討します。
投稿数0でもAPI操作、設定変更、プラグイン導入は可能なので、「記事を書いていないから無害」と判断してはいけません。
WordPressのAPI経由で正しい役割へ戻す
正規ユーザーの役割修正は、管理画面やWP-CLIなど、WordPressの権限APIを通して行います。
これによりシリアライズ値、関連メタ、オブジェクトキャッシュの整合性を保ちやすくなります。
- バックアップと調査結果を保全する
- 対象ユーザーの正規・不正と必要な役割を確定する
- 利用中セッションと不正な認証経路を失効させる
- WordPressのAPI経由で役割を修正またはユーザーを削除する
- 追加元の脆弱性・マルウェア・外部侵害を除去する
- 管理画面・WP-CLI・DB・ログを再確認する
直接DELETEやUPDATEを最初の修復に使わない
SQLのDELETEやUPDATEは強力ですが、接頭辞・ユーザーID・メタキーを間違えると正規管理者がログインできなくなります。
キャッシュとの不一致やシリアライズ破損も起こりやすいため、初心者が最初に選ぶ方法ではありません。
管理画面もWP-CLIも使えず、DB修復しか残っていない場合は、作業用コピーで復元手順を試してから本番へ反映します。
変更対象のumeta_idを限定し、前後の値、実行時刻、担当者を記録してください。
WordPressのusermeta改ざんを再発させない確認
権限を戻した後は、usermetaを書き換えた経路を止めます。
ユーザー情報だけ直しても、脆弱なプラグイン、不正PHP、漏えいした認証情報、悪用されたAPI、DBバックドアが残れば同じ管理者権限が再生成されるためです。
ファイル・DB・ログを同じ時系列で調べる
不審権限を確認した時刻の前後で、アクセスログ、WAFログ、管理画面ログイン、ユーザー作成・更新、プラグイン導入、PHPファイル更新、Cron実行を並べます。
1つの時系列へまとめると、権限変更の直前に起きた操作を絞り込みやすくなります。
ファイル名や更新日時だけで感染を断定せず、公式配布物との差分、コード内容、呼び出し元、通信先を確認します。
DB側ではユーザー関連だけでなく、options、投稿、予約処理、プラグイン独自テーブルも調査対象になります。
すべての認証情報と管理者運用を見直す
WordPress管理者だけでなく、サーバー、SFTP、SSH、DB、ホスティング管理画面、メール、DNS、CDN、外部連携の認証情報を影響範囲に応じて更新します。
変更は安全な端末から行い、多要素認証と個人別アカウントを使ってください。
共有管理者を1つ使い回すと、誰の操作か追えません。
必要最小限の管理者だけを残し、日常作業は編集者など適切な役割へ分け、退職者・外注終了者のアカウントをすぐ停止できる運用にします。
復旧後も権限の再生成を監視する
復旧直後に1回正常でも、数時間後や翌日に権限が戻ることがあります。
管理者一覧、対象ユーザーのメタ、最近のログイン、ファイル差分、予約処理を定期的に確認してください。
再生成した場合は、修正が失敗したのではなく、書き戻す仕組みが残っている証拠です。
再び同じ行だけを削除せず、実行時刻からファイル・DB・Cron・外部アクセスを追い直します。
WordPressのusermeta改ざんでよくある質問
WordPressのusermeta改ざんは照合してから復旧する
WordPressの管理者権限は、ユーザー一覧だけでも、wp_usermetaの1行だけでも正確に判断できません。
稼働DBと接頭辞、wp_users.ID、capabilities、WP-CLIのroles、マルチサイト、キャッシュ、表示を変えるコードを同じ時点で照合する必要があります。
調査はバックアップと証拠保全から始め、最初は読み取り専用で進めてください。
正規ユーザーの不正昇格と完全な不正ユーザーを分け、WordPressのAPI経由で権限を戻し、追加元まで除去することが安全な復旧につながります。
- 管理画面・WP-CLI・DBで正規の役割が一致している
- 不正ユーザー・不正権限・不正セッションが残っていない
- 脆弱性・不正コード・漏えい認証情報を対処した
- 数時間後・翌日にも権限が再生成していない
- ファイル・DB・ログ・作業記録を安全に保管した
WordPressの見えにくい管理者権限を自分で復旧できない時は
管理画面とデータベースの結果が一致しない、不正権限が何度も戻る、正規ユーザーを消しそうで不安な場合は、
クイックレスキューが権限・ファイル・DB・ログをまとめて調査します。
- 管理画面に見えない権限情報がDBに残っている
- 不審な管理者を削除しても再び追加される
- 接頭辞やマルチサイトが複雑で対象を判断できない
- 正規ユーザーや投稿を壊さずに復旧したい
- マルウェアと侵入経路までまとめて調べたい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
