2026.09.10

ログイン画面は守っても裏口は開いたまま？WordPressをxmlrpc.phpやREST APIの「裏口」から守る不正ログイン対策

【AIによる要約】
– WordPressへの不正ログインは、ログイン画面だけでなくxmlrpc.phpやREST APIという裏口からも行われ、こちらはロック系プラグインが効かず放置されがちです。
– まずサーバーのアクセスログで裏口へのアクセス実態を確認し、xmlrpc.phpを使っていなければサーバー設定で遮断するのが最優先です。
– REST APIは使う機能だけを残す考え方で制限し、WAFや二段階認証と組み合わせます。サーバー設定に触れる判断は保守パートナーへの相談が安心です。

はじめに：「ログイン画面にプラグインを入れたのに」

「ログイン試行回数を制限するプラグインを入れているから、不正ログインは大丈夫」

そう考えていた運用現場で、管理画面以外の入り口から総当たり攻撃を受けていたケースを、当社は業界歴10年・300社以上の支援の中で何度も目にしてきました。

WordPressのセキュリティ対策情報は「ログイン画面の強化」に偏りがちです。しかしWordPressには、ログイン画面とは別に外部から認証を試せる「裏口」が標準で用意されています。この記事では、その代表的な存在であるxmlrpc.phpとREST APIの仕組み、放置すると何が起きるのか、そしてどう遮断すべきかを解説します。

xmlrpc.phpとは？WordPress標準装備の「裏口」

xmlrpc.phpは、WordPressに昔から標準搭載されているAPIの入口です。スマホアプリや外部ツールから記事を投稿・編集するための仕組みで、ログイン画面を経由せずに、ユーザー名とパスワードで認証できます。

便利な機能である一方、攻撃者から見ると魅力的な点があります。

• 1回の通信で数十〜数百組のIDとパスワードを試せる：ログイン画面なら1回のアクセスで1組しか試せませんが、xmlrpc.phpのsystem.multicallという機能を使うと、1回の通信で大量の認証をまとめて試せます。
• ログイン画面向けの対策が効きにくい：ログイン試行回数を制限するプラグインは、ログイン画面（wp-login.php）へのアクセスを監視しているものが多く、裏口のxmlrpc.php経由の攻撃を見逃すことがあります。
• pingback機能がDDoSの踏み台にされる：他サイトへの通知機能（ピンバック）を悪用され、自分のサーバーが他のサイトへの攻撃に加担させられる事例も知られています。

WordPress公式のハーディング（強化）ガイドでも、利用していない場合はxmlrpc.phpの無効化が推奨されています（出典：WordPress.org Hardening WordPress – Disabling XML-RPC）。

放置すると何が起きるか

裏口からの総当たり攻撃は、毎日、自動的に、人間が寝ている間も送られてきます。放置した場合の帰結は次の通りです。

1. 管理者アカウントの乗っ取り：パスワードが破られると、記事の改ざん、フィッシングページの設置、不正なリンクの埋め込みなどが行われます。Googleに「このサイトは有害な可能性があります」と表示され、検索流入が消失します。
2. サーバー資源の消耗と停止：大量の認証リクエストはサーバーに負荷をかけます。共有サーバーでは他サイトごと停止させ、サーバー会社から利用制限をかけられることもあります。
3. 踏み台として加害側になる：ピンバック機能の悪用で、自社サーバーが第三者サイトへの攻撃の踏み台になります。サーバー会社から「攻撃元として停止措置をした」と通知され、業務が止まります。

改ざん被害からの復旧は、記事の修復だけでなく、マルウェアの洗い出し、検索エンジンへの再審査申請まで含むと数週間に及ぶこともあります。最初の1回の遮断作業にかかる時間より、はるかに重いコストです。

まず現状確認：裏口は使われているか

遮断する前に、自社のサイトで裏口が実際に使われているかを確認します。やみくもに遮断して、スマホアプリや外部ツールとの連携が壊れてから慌てないためです。

確認すること

• サーバーのアクセスログ：POST /xmlrpc.php へのアクセスがどのくらいあるか。数百〜数千回/日という数字が出てきたら、すでに攻撃を受けています。同じIPから短時間に大量のリクエストが来ていれば総当たり攻撃の痕跡です。
• 連携ツールの有無：WordPressアプリ、Jetpack、外部投稿ツール、レイアウト崩れ修正系のプラグインなど、XML-RPCに依存する仕組みを使っていないか。通常のブラウザでの記事更新はXML-RPCを使わないため、「ブラウザで更新しているだけ」のサイトなら遮断して問題ないのが一般的です。

対策の優先順位：言い切るとこの順です

「どの対策から始めるべきか迷う」という声をよく聞きます。当社の判断基準は明確で、使っていない裏口は物理的に閉めるのが最も確実で、その後は多層防御を足すだけです。

第1優先：xmlrpc.phpをサーバー設定で遮断する

プラグインでの無効化も可能ですが、プラグインはPHPレベルで動くため、遮断前の通信自体はサーバーまで到達します。サーバーの設定（Apacheの.htaccessやNginxの設定）でファイルへのアクセスを拒否する方法が、負荷的にも確実性の面でも上位です。

.htaccessの例（Apache）：

<Files xmlrpc.php>
  Require all denied
</Files>

共用レンタルサーバーで管理画面から設定できない場合は、XML-RPC無効化系プラグインでも実用上十分な効果があります。ただし「プラグインを追加するだけ」で終わらせず、遮断後にアクセスが403で返ることを必ず確認してください。

第2優先：REST APIのユーザー列挙を塞ぐ

/wp-json/wp/v2/users にアクセスすると、公開記事を書いたユーザーのログイン名（スラッグ）が一覧で取得できるケースがあります。ログイン名が分かると総当たり攻撃の成功率は大きく上がるため、これは塞ぐべき情報漏えいです。

対応は次のいずれかです。

• セキュリティプラグインの機能で、REST APIのユーザー情報の公開を制限する
• 利用していないREST APIのエンドポイント（投稿作成・ユーザー一覧など）を関数で無効化する
• WAF（Webアプリケーションファイアウォール）で不要なパスへのアクセスを遮断する

注意点として、REST APIはお問い合わせフォームのプラグインやテーマの一部機能でも使われています。すべて丸ごと止めると画面が壊れることがあるため、「使う機能だけを残す」部分遮断が現実的です。

第3優先：多層防御を足す

裏口を閉めても、ログイン画面本体の対策は別途必要です。

• 二段階認証（2FA）：パスワードが漏れても突破されにくくなります。
• WAFの有効化：レンタルサーバー標準のWAFを有効にしておくだけで、既知の攻撃パターンをかなり防げます。
• パスワード運用の徹底：ユーザー名「admin」の使用禁止と、パスワードマネージャーによる長いパスワードの利用。
• 定期的なログ監視：上記を設定しても、新しい抜け道は生まれます。月次でアクセスログの異常を確認する運用が理想です。

IPA（情報処理推進機構）の「情報セキュリティ10大脅威」でも、WordPressへの攻撃は継続的に上位に挙げられており、公開前の防御設計が重要とされています（出典：IPA 情報セキュリティ10大脅威）。

落とし穴チェックリスト

現場でハッとする盲点をまとめます。設定前に1つずつ確認してください。

• xmlrpc.phpを遮断した後、WordPressモバイルアプリやJetpackが使えなくならないか確認したか
• REST APIを丸ごと無効化して、お問い合わせフォームやテーマの機能が壊れていないか実機で確認したか
• ログイン試行制限プラグインがxmlrpc.php経由の攻撃をカバーしているか仕様を確認したか（カバーしないものが多い）
• ユーザー名「admin」が残っていないか（残っている場合は移行が必要）
• サーバー標準のWAFが有効になっているかサーバー管理画面で確認したか
• 遮断・制限の設定をした後、アクセスログで403になっているか検証したか
• 変更前にバックアップを取得したか（.htaccessを編集すると、書き方を誤るとサイト全体が500エラーになります）

自社で対応する範囲と、プロに任せる範囲

この判断基準も明確にしておきます。

• 自社で対応できる範囲：セキュリティプラグインの導入、二段階認証の設定、WAFの有効化（サーバー管理画面のチェックボックス操作）、パスワード運用の見直し。
• プロに任せるべき範囲：.htaccessやNginx設定の直接編集（誤るとサイト全停止）、REST APIの部分遮断のためのPHP実装、アクセスログの分析、既に攻撃を受けている状態からの調査と駆除。

特に「.htaccessを編集してすぐに500エラーが出た」という相談は少なくありません。テキスト1行の変更でも、本番環境への反映は検証環境での確認が前提です。

まとめ

WordPressの不正ログイン対策は、ログイン画面だけを固めても完成しません。xmlrpc.phpやREST APIという標準装備の裏口を確認し、使っていないものは閉める。使うものは最小限に制限する。その上で多層防御を足す——この順序で進めれば、大多数の総当たり攻撃は防げます。

当社カジヤは、業界歴10年・300社以上の支援の中で、攻撃・改ざん被害の復旧にも何度も直接立ち会ってきました。そして自社でもWebサービスを運営している当事者として、「被害が出てから慌てる運用」より「先回りして閉める運用」が結果的に安いと確信しています。

「ログに大量のxmlrpc.phpアクセスが出ている」「どのエンドポイントを残していいか分からない」といった状況なら、まず現状を解析した上で、サイトの利用形態に合わせた遮断設計を提案できます。Webサイト保守管理サービスまで、お気軽にご相談ください。