WordPress Application Passwordsが悪用された？確認・無効化・再発防止

WordPressのApplication Passwordsに見覚えのない項目がある、外部サービスから不審な投稿や更新が行われた。
このような時は、通常のログインパスワードを変えるだけでは不十分です。発行済みApplication Passwordsを記録して失効し、利用ログとユーザー権限まで確認する必要があります。

Application Passwordsは外部アプリやREST API、XML-RPCがWordPressへ接続するための認証情報です。
便利な反面、漏えいすると、その認証情報を発行したユーザーと同じ権限でAPI操作を受ける恐れがあります。

よこやま良平

20年以上ITエンジニアとして、WordPressの制作・保守・復旧に携わっている、よこやま良平です。API経由の不正操作は管理画面ログインだけを見ても分からないため、認証情報、権限、リクエストを一つの時系列で確認します。

結論は『一覧を撮る→正規用途を照合する→不審なものを失効する→通常アカウントも保護する→API操作の影響を調べる』です。
連携名だけで安全と決めず、誰が、いつ、何のために発行し、どこから使ったかを確認してください。

この記事はApplication Passwordsそのものを危険と決めつける内容ではありません。
必要な連携は残しつつ、見覚えのない発行、漏えい、権限過大、退職者や外注先の残存を判断するための実務手順を解説します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPress Application Passwordsの仕組みと悪用時の影響

Application Passwordsを調べる最初の結論は、通常の管理画面ログインとは別の認証情報として扱うことです。
WordPressユーザーごとに発行され、外部アプリがREST APIやXML-RPCへ接続する時に使われます。

生成された秘密は発行時に一度だけ表示され、WordPress側では復元できない形で保存されます。
一覧には名前、作成情報、最終利用日時やIPなど判断材料が表示される場合がありますが、秘密そのものを後から確認することはできません。

通常のパスワード変更だけでは失効しない

Application Passwordsは通常のログインパスワードから独立しています。
管理画面のパスワードを変更しても、発行済みApplication Passwordsが自動で全部消えるとは限らないため、個別または一括の失効操作が必要です。

反対に、Application Passwordsは通常のwp-adminログインフォームへ入力するためのものではありません。
管理画面に入れなかったから安全と判断せず、APIを使った投稿作成、更新、メディア追加、ユーザー情報取得などの痕跡を調べます。

操作できる範囲は発行したユーザー権限に依存する

WordPress標準のApplication Passwordsは、発行時に細かなAPI権限を一つずつ選ぶ仕組みではありません。
基本的には紐づくユーザーが持つ権限で認証されるため、管理者が発行した秘密の漏えいは影響範囲が大きくなります。

投稿専用ツールへ管理者のApplication Passwordsを渡すと、本来不要な操作まで許す可能性があります。
正規連携でも、専用の低権限ユーザーを作り、必要な役割だけを付ける方が安全です。

WordPress乗っ取り判定｜管理者アカウントと権限を確認する方法

Application Passwords悪用の疑いは発行済み一覧から確認する

最初の確認場所は、対象ユーザーのプロフィールにあるApplication Passwords一覧です。
ただし、見つけてすぐ削除すると名前や最終利用情報を失うため、緊急度を見ながら先に画面と時刻を保存します。

管理者が複数いるサイトでは、自分のプロフィールだけでは足りません。
投稿者や外部連携専用ユーザーも含め、誰がApplication Passwordsを持てる状態かを一覧化してください。

名称・作成者・最終利用・IPを照合する

一覧の名称が『mobile』『backup』『integration』でも、正規とは限りません。
担当者、利用サービス、作成日、保管場所、接続先URL、最終利用日時、接続元IPを、台帳や契約情報と照合します。

最終利用が空でも安全とは断定できません。発行直後で未使用、古いWordPressで情報が十分でない、リバースプロキシ越しでIPが分かりにくいなどの可能性があります。
逆に見覚えのあるIPでも、共有サーバーや外部サービスの出口IPか確認が必要です。

ユーザーが知らない発行はアカウント侵害も疑う

本人が作成していないApplication Passwordsがあるなら、秘密だけの漏えいではなく、通常アカウントが侵害されて新規発行された可能性も考えます。
ログイン履歴、メール変更、権限変更、二段階認証、セッション、プロフィール更新を同じ期間で確認してください。

退職者や外注先が作成した連携を放置していた場合は、悪意がなくても管理不能な認証情報です。
誰も用途を説明できないものは、正規連携の停止影響を確認し、記録後に失効するのが正解です。

WordPressのユーザー権限を間違えると危険？管理者・編集者・投稿者の違い

Application Passwordsの悪用をログと変更履歴で調査する

一覧だけでは、何が操作されたかまでは分かりません。
Webサーバー、WAF、WordPress、監査プラグイン、外部連携サービスのログを同じタイムゾーンへ揃え、認証利用とコンテンツ変更を結び付けます。

REST APIとXML-RPCへのリクエストを探す

REST APIなら`/wp-json/`配下のPOST・PUT・PATCH・DELETE、XML-RPCなら`/xmlrpc.php`へのPOSTを確認します。
リクエスト時刻、接続元IP、User-Agent、HTTPメソッド、対象ルート、応答コード、送受信量を保存してください。

Basic認証のAuthorizationヘッダーには秘密が含まれるため、ログや報告書へその値をそのまま貼ってはいけません。
ヘッダーを採取する必要がある場合はアクセス制限された証拠保管先へ置き、共有用資料では必ず伏せ字にします。

調査時刻 | 接続元IP | 方式 | メソッド | APIルート | 応答 | User-Agent | 関連変更
2026-10-24 01:23 JST | 203.0.113.xxx | REST | POST | /wp-json/wp/v2/posts | 201 | external-tool | 投稿IDを新規作成
2026-10-24 01:25 JST | 203.0.113.xxx | REST | POST | /wp-json/wp/v2/media | 201 | external-tool | メディアIDを追加

投稿・メディア・ユーザーの変更を時系列に並べる

不審な認証利用と同じ時間帯に、投稿本文、固定ページ、メディア、ユーザー、コメント、設定が変わっていないか確認します。
ゴミ箱、リビジョン、自動保存、作成者、更新者、添付ファイルの親投稿も対象です。

表示上は異常がなくても、非公開下書き、外部リンク、SEOメタ、リダイレクト設定、Webhook先が変更されている場合があります。
プラグイン独自APIがあるサイトでは、そのプラグインの注文、会員、フォーム、キャッシュ操作ログも確認してください。

WordPressのXML-RPCは無効化してよい？Jetpack・アプリ利用時の判断基準

Application Passwordsを証拠保存後に無効化する手順

悪用の可能性が高い場合は、証拠を最低限保存したうえで、対象のApplication Passwordsを速やかに失効します。
操作中も不正更新が続く、個人情報へ到達する、管理者権限が使われる状況では、完全な調査より封じ込めを優先してください。

不審な1件を失効するか全件を失効するか決める

用途と漏えい範囲を特定でき、不審な1件だけが明確なら個別失効ができます。
一方、通常アカウント侵害、共有チャットやソースコードへの秘密混入、複数の不明項目、管理端末感染が疑われる場合は、そのユーザーの全Application Passwords失効を選びます。

全件失効すると、バックアップ、投稿アプリ、外部管理、監視、連携サービスが止まる可能性があります。
業務影響を記録しつつ、安全を優先して止め、必要なものだけ新規発行する順番にします。

通常パスワード・セッション・二段階認証も見直す

見覚えのない発行がある場合は、通常ログインパスワードを安全な端末から変更し、全セッションを終了します。
二段階認証の登録端末、復旧コード、メールの転送や委任、パスワード再設定先も確認します。

同じパスワードをメール、ホスティング、外部サービスで使い回していたなら、上位アカウントから順に変更してください。
WordPressだけ直しても、管理メールを奪われていれば再設定されるためです。

1. 一覧・最終利用情報・対象ユーザー権限を保存する
2. 不審なApplication Passwordsを個別または全件失効する
3. 通常パスワード変更と全ログインセッション終了を行う
4. 二段階認証・復旧コード・管理メールを再確認する
5. API経由で変更された投稿・メディア・設定を復旧する
6. 必要な正規連携だけ新しい認証情報で再設定する
7. ログ監視を続け、旧認証情報の再利用失敗を確認する

失効後に旧認証情報が使えないことを確認する

管理画面で削除表示を確認するだけでなく、正規のテスト環境から旧Application Passwordsが401などで拒否されることを確認します。
本番データを書き換えないGET系の確認を選び、秘密をコマンド履歴や共有資料へ残さないでください。

CDNやWAFが応答をキャッシュしていないか、外部連携側が別の認証情報へ自動切替していないかも確認します。
失効時刻、確認方法、結果を記録し、調査の終了条件を明確にします。

WordPressハッキング発覚直後の初期対応チェックリスト

Application Passwordsの正規連携を安全に復旧する

連携復旧では、以前と同じ認証情報をそのまま作り直さないことが重要です。
利用目的、必要権限、保管場所、担当者、更新方法、廃止条件を決めてから、新しいApplication Passwordsを発行します。

管理者ではなく専用の低権限ユーザーを使う

投稿作成だけなら、管理者ではなく編集者や投稿者など、必要な操作を満たす最小権限を検討します。
ただし、外部サービスが必要とするAPI操作は製品ごとに違うため、ステージング環境で権限不足と過剰権限を確認してください。

専用ユーザーには用途が分かる表示名を付け、個人の退職や異動に影響されない管理体制にします。
一つの認証情報を複数サービスで共有せず、サービス単位で発行すれば、事故時に止める範囲を限定できます。

秘密をソースコードやチャットへ保存しない

Application Passwordsは環境変数、秘密管理サービス、アクセス制限された設定保管先へ保存します。
Gitリポジトリ、チケット、メール、チャット、スクリーンショット、作業メモへ平文で残してはいけません。

漏えいした可能性がある秘密は、リポジトリから文字列を消すだけでは不十分です。
コミット履歴、CI/CDログ、成果物、バックアップ、共有先に残るため、先に失効し、新しい秘密を発行して利用先を更新します。

連携テストは読み取りから段階的に行う

新しい認証情報を設定したら、接続確認、読み取り、限定された書き込み、実運用の順に試します。
いきなり大量投稿や一括同期を実行すると、権限設定や対象URLの誤りに気づいた時の影響が大きくなります。

テスト中はWebサーバーとWordPressのログを確認し、想定したユーザー、IP、ルートだけが使われているか見ます。
外部サービスの終了後にApplication Passwordsが残らないよう、台帳へ次回確認日も入れてください。

Application Passwords悪用を防ぐ設定と運用

再発防止はApplication Passwordsを全サイトで無効にすることだけではありません。
利用がないサイトは無効化を検討でき、利用があるサイトは発行者、ユーザー権限、保管、ログ、棚卸しを組み合わせて守ります。

使わないサイトでは機能を無効化する

外部アプリ、REST API認証、XML-RPC連携を一切使わないなら、WordPressのフィルターや信頼できるセキュリティ機能でApplication Passwordsを無効化できます。
ただし、REST API全体を雑に止めるとブロックエディターやプラグインへ影響するため、機能の違いを分けて設定します。

add_filter( 'wp_is_application_passwords_available', '__return_false' );

コードを入れる場合は子テーマや専用プラグインで管理し、テーマ更新で消えない形にします。
本番へ反映する前にバックアップを取り、管理画面、投稿編集、フォーム、バックアップ、外部連携を確認してください。

管理者だけに発行を集中させない

必要な連携へ管理者権限を渡す運用をやめ、専用ユーザーと最小権限へ分離します。
ユーザー名の使い回しを避け、管理者数、外注先権限、退職者アカウントを定期的に棚卸しします。

クイックレスキュー365は不正ログインブロック、ログインURL変更、XMLRPC遮断、ユーザー名漏えい防御などを利用できます。
ただしマルウェアのスキャン機能はないため、感染確認が必要な場合はWordfenceなどのスキャンと手動調査を組み合わせてください。

日本製セキュリティ対策で不正アクセスを遮断「クイックレスキュー365」無料ダウンロード

APIログと変更通知を継続監視する

REST APIとXML-RPCの書き込み、管理者ユーザー作成、権限変更、Application Passwords発行、投稿大量更新を監視対象にします。
WAFで一律遮断するだけでなく、正規サービスのIP変動やUser-Agent変更を考慮し、誤検知と見逃しを調整します。

ログは保存期間、タイムゾーン、取得担当、確認頻度を決めます。
事故が起きてから初めて有効化しても過去は戻らないため、平常時に一度、発行から失効までのテストを行うと確実です。

プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。

WordPress・サイト保守クイックレスキュー365

Application Passwords悪用でよくある質問

Application Passwords悪用は一覧・ログ・権限を一緒に確認する

Application Passwordsの悪用が疑われたら、通常パスワードだけを変更して終わらせず、発行済み一覧と最終利用情報を保存します。
次にREST API・XML-RPCのリクエストと投稿・メディア・ユーザー変更を時系列で照合してください。

不審な項目は証拠保存後に失効し、通常アカウント、セッション、二段階認証、管理メールも守ります。
正規連携は専用の低権限ユーザーと新しい秘密で作り直し、用途・担当・保管先・廃止条件を台帳化することが再発防止につながります。

管理者権限で不審なAPI操作が続いている、ログが足りず影響範囲を判断できない、投稿やユーザーが改ざんされている場合は、証拠を消さず専門家へ相談してください。
秘密の失効とサイト全体の復旧を分けずに進めることが重要です。

WordPressの不正アクセス・認証悪用が自分で直せない時は

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で