「WordPressのプロフィールに、作った覚えのないApplication Passwordsがある」「深夜に知らないIPから使われている」と不安になっていませんか？
通常の管理画面ログイン履歴に異常がなくても、API経由で投稿や設定へアクセスされた可能性は残ります。
結論から言うと、ラベル・作成日時・最終使用日時・最終IPを記録し、正規連携か確認したうえで、不審なものを失効するのが最初の対応です。
ただし、Application Passwordsを取り消しただけで「復旧完了」と考えてはいけません。
その認証情報を作成できた原因が正規ユーザーのアカウント侵害なら、同じ人物が新しい認証情報を追加するおそれがあります。
実ユーザーのパスワード、ログインセッション、二段階認証、管理者、プラグイン、ファイル、Cron、アクセスログまで分けて確認する必要があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験とWordPress公式資料をもとに、Application Passwordsの確認、無効化、影響調査を初心者にも分かる順番で解説します。
- Application Passwordsと通常のログインパスワードの違い
- ラベル・作成日時・Last Used・Last IPの確認方法
- 不審な認証情報を個別または全件で無効化する判断
- REST APIやXML-RPCのアクセスをログから追う方法
- 失効後に正規連携を安全に戻し、再発を防ぐ手順
見覚えのない登録があり、同時に投稿・ユーザー・設定の変更も起きている場合は緊急度が高い状態です。
まず証拠を短時間で残し、被害を止めるところから始めましょう。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressのApplication Passwords悪用を疑う前に仕組みを知る
WordPressのApplication Passwordsは、外部アプリや自動処理がWordPress APIへ接続するための専用認証情報です。
正規機能なので、一覧にあるだけでは不正アクセスと断定できません。
一方、紐づくユーザーの権限でAPI操作に使われるため、管理者アカウント用の認証情報が漏れれば影響は大きくなります。
「ログイン画面に入られていないから安全」とは判断できない点が重要です。
通常のWordPressパスワードとは用途が違う
通常のパスワードは、主にwp-login.phpから人が管理画面へ入るために使います。
Application Passwordsは、WordPress 5.6以降に標準搭載され、HTTPS上のREST APIやXML-RPCなどへプログラムから接続する用途です。
WordPress公式は、Application Passwordsをwp-login.phpの対話的ログインには使用できないと説明しています。
そのため通常ログインの失敗記録がなくても、API側のアクセス記録は別に確認しなければなりません。
認証後は紐づくユーザーの権限で動く
Application Passwordsは、作成したユーザーとは別の小さな専用ユーザーを作る機能ではありません。
認証に成功すると、基本的には紐づくユーザーが持つ権限の範囲でAPIへアクセスします。
編集者なら投稿編集、管理者ならユーザーや設定に関わる操作まで到達し得るため、発行先は最小権限にするのが原則です。
管理者の日常アカウントへ何本も発行している運用は、1本漏れた時の影響範囲を広げます。
- 通常のWordPressパスワードとログインCookie
- Application PasswordsとAPIアクセス
- 二段階認証と回復コード
- サーバー、SFTP、データベース、メールの認証情報
WordPressの不審なApplication Passwordsを見つけた直後の初動
不審なApplication Passwordsを見つけた直後は、詳細を記録してから短時間で失効し、正規管理経路を確保します。
調査を優先しすぎて有効なまま放置すると、その間にもAPI操作を続けられるおそれがあります。
ただし、何も記録せず「すべて取り消す」を押すと、どの認証情報がいつ使われたかを後から説明しにくくなります。
画面保存と時刻記録を先に行い、数分で封じ込めへ進むのが現実的です。
名称・作成日時・最終使用日時・最終IPを保存する
対象ユーザーのプロフィール画面を開き、Application Passwords一覧を画面保存します。
名称、作成日時、Last Used、Last IP、表示されている並び、確認したJST時刻を一緒に残してください。
WordPressは生成した平文のApplication Passwordを作成時に一度だけ表示し、保存時はハッシュ化します。
一覧から元の文字列を取り出すことはできないため、画面保存で秘密そのものを露出する心配は通常ありません。
- 対象ユーザーのID・ログイン名・権限
- Application Passwordの名称と作成日時
- Last UsedとLast IP
- 発見時刻、同時に見つけた投稿・設定・ユーザー変更
- 関連するサーバー通知、監視通知、アクセスログの保全場所
被害が進行中なら記録後すぐ個別または全件失効する
知らない投稿が増えている、ユーザーが追加された、設定が書き換わるなどの被害が進行中なら、正規連携の確認を長時間待たないでください。
不審な1件が特定できるなら個別に取り消し、判別できない場合は対象ユーザーの全件失効を選びます。
全件失効は正規アプリも停止させますが、侵害中は可用性より封じ込めを優先する場面があります。
止まる業務と復旧担当をメモし、後で必要な連携だけ新しい認証情報で戻します。
- 作成者も用途も分からない認証情報が最近使われている
- 同じ時間帯に投稿・固定ページ・ユーザーが変更された
- 管理者ユーザーに紐づき、国外など説明できないIPが記録されている
- 失効しても同名または別名の認証情報が再び作成される
- 不審ファイル、リダイレクト、迷惑メール送信など別症状もある
正規管理者を確保し、別経路の乗っ取りを防ぐ
失効操作の前後で、信頼できる正規管理者が少なくとも1人ログインできる状態を確認します。
不審ユーザーだけでなく、既存管理者のメールアドレス、権限、表示名、回復経路が変更されていないかも見てください。
見覚えのない管理者がいる場合は、投稿所有者や操作履歴を記録せずに削除しないことが大切です。
次の記事では、不審ユーザーを安全に止めて削除するまでの判断を詳しく整理しています。
乗っ取り全体の初動、バックアップ、公開影響の停止をまだ行っていない場合は、次の手順も並行して確認してください。
WordPressのApplication Passwords一覧を全ユーザーで確認する
Application Passwordsの確認は、最初に見つけた管理者1人だけで終えず、権限を持つ全ユーザーへ広げるのが正解です。
攻撃者が別ユーザーへ予備の認証情報を作っていると、1件の失効後もアクセスが続きます。
編集者、投稿者、API専用ユーザーにも、サイトの運用に応じた権限があります。
全ユーザー一覧を作り、Application Passwordsの有無、用途、担当者、継続・失効の判断を1行ずつ記録します。
管理画面のユーザープロフィールから確認する
管理画面の「ユーザー」から対象者を開き、プロフィール下部のApplication Passwords欄を確認します。
自分以外のユーザーを確認できるかは、現在の権限とサイト構成によって変わります。
一覧が空なら、そのユーザーに現在保存されているApplication Passwordsはありません。
欄そのものが表示されない場合は、HTTPS、WordPressのバージョン、プラグインやフィルターによる無効化、ユーザーごとの利用制限を確認します。
Last Usedは最大24時間程度の精度で読む
WordPress公式によると、Last Usedは利用のたびにデータベースへ書き込むのではなく、基本的に1日1回の更新です。
つまり表示時刻は「その瞬間の最後のリクエスト」を秒単位で示す監査ログではありません。
Last Usedが深夜だから不正と決めつけたり、表示後の数時間に利用がないと断定したりしないでください。
正確な要求時刻、URL、HTTPメソッド、応答は、WebサーバーやWAF、CDN、監査ログ側で補います。
WordPressの不審アクセスをログと変更履歴から確認する
Application Passwordsの悪用を確認するには、Last IPとLast Usedを起点に、API経路・操作対象・変更結果を時系列で照合します。
IPアドレス1個や投稿1件だけでは、正規連携と侵害を正しく分けられません。
調査では「誰の認証情報が」「どの経路へ」「いつ」「何を要求し」「サイトで何が変わったか」を1本の表にします。
完全なログが残っていなくても、複数の弱い手掛かりを同じ時間軸へ置くと判断しやすくなります。
REST APIとXML-RPCへの要求を絞り込む
Webサーバー、CDN、WAFのログで、wp-json配下とxmlrpc.phpへのアクセスを確認します。
Last IP、疑わしい時間帯、対象ユーザーの変更時刻を条件にし、POST・PUT・PATCH・DELETEなど更新につながる要求を優先して見ます。
ただし、Basic認証の資格情報やAuthorizationヘッダーをログへ出力・共有してはいけません。
調査資料には時刻、接続元、要求先、メソッド、応答コード、利用者の説明に必要な範囲だけを残します。
- JSTへ統一した要求時刻とタイムゾーン
- 接続元IP、プロキシ経由の記録、User-Agent
- wp-jsonまたはxmlrpc.phpの要求先
- HTTPメソッド、応答コード、応答サイズ
- 直後に作成・更新・削除された投稿、ユーザー、設定
投稿・ユーザー・プラグイン・設定の変更を並べる
不審なAPIアクセスと同じ時間帯に、投稿タイトル、本文、公開状態、管理者、Application Passwords、プラグイン、テーマ、optionsが変わっていないか確認します。
予約投稿や正規の自動連携もあるため、各変更の担当者と業務予定を照合してください。
見覚えのないプラグインや連携が増えている場合は、停止・削除前にフォルダー名、バージョン、導入日時、設定、登録元を保全します。
正規保守ツールに見せかけた不審な機能を、名前だけで安全と判断してはいけません。
WordPressのApplication Passwordsを安全に無効化する
不審なApplication Passwordsは、対象が特定できれば個別失効、判別できなければ対象ユーザーの全件失効が基本です。
失効後は接続試験をせず、正規アプリ側で認証エラーになったことだけを安全に確認します。
平文を回収して再利用するのではなく、必要な正規連携には新しい認証情報を発行します。
同じ名称、同じユーザー、同じ保存場所を無条件で戻すと、漏えい原因まで再現してしまいます。
個別失効と全件失効を使い分ける
用途と所有者が明確な正規連携を止めたくない場合は、不審なUUIDの1件だけを取り消します。
名称が曖昧、担当者不明、複数件が同時に使われた、一覧自体を信頼できない場合は、全件失効の方が安全です。
WordPressコアには個別削除と全件削除の仕組みがあり、取り消した認証情報は以後の認証に使えません。
削除前後の一覧、失効件数、操作した正規管理者、JST時刻をインシデント記録へ残してください。
実パスワード・Cookie・二段階認証は別に対応する
Application Passwordsを全件失効しても、通常のWordPressパスワードや既存のログインCookieが自動ですべて変わるわけではありません。
正規ユーザーのパスワード変更、全セッションのログアウト、二段階認証の再確認を別工程で実施します。
管理者メール、回復用メール、サーバーパネル、SFTP、データベース、DNS、CDNにも異常があれば、WordPress内だけの変更では足りません。
安全と確認した端末から、上位の管理面を先に保護してから下位の認証情報を交換します。
- 対象ユーザーの通常パスワードを固有の強いものへ変更
- 既存ログインセッションを全端末から失効
- 二段階認証、回復コード、管理者メールを再確認
- 不審な管理者と権限変更を調査
- サーバー・SFTP・DB・DNS・CDNの侵害有無を確認
正規連携は新しい専用ユーザーと保管方法で戻す
必要な連携を戻す前に、そのアプリが現在も使われているか、必要な権限は何か、秘密情報をどこへ保存するかを見直します。
可能なら管理者ではなく、業務に必要な最小権限の専用ユーザーを用意してください。
新しいApplication Passwordは画面共有、メール本文、チャット、ソースコード、公開リポジトリへ貼らず、対応する安全な秘密情報保管へ登録します。
接続確認後は、旧設定やバックアップ、テスト端末に古い認証情報が残っていないかも確認します。
WordPressのApplication Passwords失効後に全体を調査する
Application Passwordsを失効した後は、作成された原因とAPI以外の侵入口を閉じるまで調査を続ける必要があります。
正規ユーザーのアカウントやサーバーが侵害されたままなら、新しい認証情報を再作成されるからです。
「取り消したら不審アクセスが止まった」は封じ込めの成功を示しますが、侵入経路の解消を証明しません。
ファイル、データベース、管理者、プラグイン、テーマ、Cron、ログ、同一サーバー内の別サイトまで範囲を決めて確認します。
不審ファイル・管理者・プラグイン・Cronを確認する
API経由の操作だけでなく、バックドアや不審プラグインが残っていないかを調べます。
更新日時だけで感染を断定せず、WordPress公式配布物との差分、ハッシュ、コード、通信先、アクセスログを組み合わせてください。
感染ファイルを安全に絞り込む方法は、次の記事で削除前の確認順を解説しています。
WP-Cronやサーバー側Cronに不審な処理があると、失効後もユーザー作成、設定変更、外部通信を繰り返す可能性があります。
正規イベントを壊さない調べ方は、次の記事も参考にしてください。
WordPress本体・テーマ・プラグインを安全に更新する
侵害の入口が脆弱性だった可能性に備え、バックアップと互換性を確認してWordPress本体、テーマ、プラグインをサポート中の版へ更新します。
配布元が不明な製品、放置された製品、使っていない製品は、必要性と代替を確認して整理します。
更新前に証拠を上書きしないことも大切です。
インシデント対応では「保全」「封じ込め」「駆除」「復旧」「再発防止」の順番を決め、変更のたびに状態を記録します。
- 全ユーザー、権限、通常セッション、Application Passwords
- WordPress本体、テーマ、プラグイン、mu-plugins
- 公開領域、uploads、キャッシュ、設定ファイル、データベース
- WP-Cron、サーバーCron、自動デプロイ、外部連携
- サーバー、WAF、CDN、DNS、メール、同居サイトのログ
使わないサイトでは機能制限を検討する
外部アプリやAPI連携を一切使わないサイトでは、Application Passwordsを無効化して入口を減らす方法があります。
ただし、プラグイン、スマートフォンアプリ、保守サービス、公開ツールが依存していないかを先に確認してください。
add_filter( 'wp_is_application_passwords_available', '__return_false' );上のフィルターはWordPress公式ガイドで案内されている全体無効化の例です。
子テーマへ安易に入れるとテーマ変更で消えるため、管理できる専用プラグインやmu-pluginなど、運用に合う場所を開発担当者と決めます。
機能を無効化しても、既存のユーザー侵害、マルウェア、盗まれた通常パスワードまでは解消しません。
入口削減は全体復旧の一部として扱ってください。
WordPressのApplication Passwords悪用に関するよくある質問
最後に、Application Passwordsの確認と無効化で迷いやすい点を整理します。
WordPressのApplication Passwords悪用は記録・失効・全体調査で止める
WordPressのApplication Passwordsに見覚えのない登録や利用履歴がある時は、名称だけで安全・危険を決めないでください。
ユーザー、ラベル、作成日時、Last Used、Last IP、発見時刻を保存し、正規連携の担当者と短時間で照合します。
身に覚えがなければ個別失効し、判別できない、被害が進行中、複数件が疑わしい場合は全件失効します。
その後、通常パスワード、ログインセッション、二段階認証、管理者メール、サーバー側認証を別々に保護してください。
最後に、ユーザー、投稿、設定、プラグイン、テーマ、ファイル、データベース、Cron、アクセスログを時系列で確認します。
不審な認証情報が再作成されず、正規連携だけが最小権限で動き、複数回の監視で異常がない状態を復旧完了の基準にしましょう。
- 一覧と関連する変更・ログを短時間で保全する
- 不審なものを個別または全件で失効する
- 通常パスワード・セッション・二段階認証を保護する
- 管理者・ファイル・プラグイン・Cron・ログを調査する
- 正規連携を最小権限で再発行し、時間を置いて再確認する
WordPressの不審なApplication Passwordsを自分で調査できない時は
見覚えのないApplication Passwords、API経由の投稿変更、不審な管理者やファイルがあり、
どこまで失効・調査すべきか判断できないなら、クイックレスキューが証拠保全から復旧、再発防止まで対応します。
- Application Passwordsの正規連携と不正登録を判別できない
- 不審なAPIアクセスと変更内容をログから追えない
- 全件失効で止まる正規サービスの影響が分からない
- 失効後も認証情報や不審ユーザーが再作成される
- ファイル・データベース・Cronまで調査するのが難しい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
