WordPressのXML-RPC（xmlrpc.php）を停止・無効化する完全ガイド｜攻撃リスクと.htaccess・プラグイン・コードによる安全な遮断手順

「サーバーのCPU使用率が突然100%に跳ね上がり、サイトが重くなったり503エラーが頻発する…」
「アクセスログを確認したら、見覚えのない海外IPから /xmlrpc.php へ毎秒数十件のPOSTリクエストが届いていた…」――このような経験はありませんか？

WordPressのルートディレクトリに標準で存在する「xmlrpc.php（XML-RPC）」は、外部アプリケーションと連携するための遠隔操作APIですが、現在ではブルートフォース攻撃（パスワード総当たり）やDDoS攻撃の踏み台として最も悪用されやすい脆弱なエンドポイントとなっています。

本記事では、XML-RPCの役割と放置する危険性（3大攻撃リスク）をわかりやすく整理した上で、.htaccess・Nginx・プラグイン・PHPコード・レンタルサーバー設定による安全な停止手順と停止後の検証方法をステップ形式で完全解説します。

WordPressのXML-RPC（xmlrpc.php）とは？基本機能と現在の位置づけ

「XML-RPC」とは、XML形式のデータを用いてインターネット経由で別のサーバーやプログラムの処理を呼び出す「リモートプロシージャコール（Remote Procedure Call）」の通信プロトコルです。WordPressではルートディレクトリにある xmlrpc.php がその通信窓口を担当しています。

1. 外部アプリや遠隔操作のためのレガシー通信プロトコル

WordPressの初期（2000年代）において、ブラウザ以外の外部環境からWordPressを遠隔操作するためにXML-RPCが導入されました。具体的には以下のような用途で使われていました：

• スマートフォンの旧WordPressアプリ：スマホ端末から記事の下書き保存や公開を行う通信。
• 外部デスクトップエディタ：Windows Live WriterやMarsEditなどの外部投稿ソフトからの記事同期。
• トラックバック・ピンバック機能：他サイトで自分の記事が引用・リンクされた際に自動で通知・承認し合う相互リンク通知システム。

2. WordPress REST APIへの移行とXML-RPCの役割縮小

WordPress 4.7以降、モダンで軽量・セキュアなJSON形式の通信規格である「WordPress REST API（/wp-json/wp/v2/）」がコア機能として標準実装されました。

現在では、公式モバイルアプリを含むほぼすべてのモダンな外部連携サービスがREST APIに移行しており、後方互換性のために残されているXML-RPCを有効のまま放置するメリットはほとんどありません。

なぜxmlrpc.phpは狙われるのか？放置する3大攻撃リスク

セキュリティ対策が施されていないWordPressサイトにおいて、xmlrpc.php は攻撃者にとって格好のターゲットです。放置すると以下のような深刻な被害を受けるリスクがあります。

1. system.multicallを悪用した高速ブルートフォース攻撃（総当たり）

通常のログイン画面（wp-login.php）に対するブルートフォース攻撃では、1回のHTTP POSTリクエストで1組のユーザー名・パスワードしか試行できません。そのため、多くのセキュリティプラグインやWAF（Web Application Firewall）が「短時間に連続するログイン失敗」を検知してIPを遮断できます。

しかし、XML-RPCに備わっている system.multicall メソッドを悪用されると、たった1回のHTTPリクエストの中に数百〜数千通りのログイン試行データをまとめて送信することが可能になります。

この手法を使われると、アクセス回数制限やレートリミットを簡単に迂回され、わずか数分〜数十分の間に膨大な辞書攻撃を実行されて管理者権限が奪取されてしまいます。

2. pingback.pingを悪用したDDoS攻撃の踏み台化（増幅攻撃）

XML-RPCのピンバック機能（pingback.ping メソッド）は、「記事Aが記事Bにリンクした」ことを記事Bのサーバーに自動通知する仕様です。

攻撃者はこの仕組みを悪用し、世界中の無防備なWordPressサイトの xmlrpc.php に対して、標的となる被害者サイトのURLを一斉に送りつけます。すると、何万ものWordPressサイトが一斉に標的サイトへ確認通信（HTTPリクエスト）を送信する「反射型DDoS攻撃（Reflection DDoS）」が発生します。

• 自サイトが受ける被害：自社サーバーが攻撃の踏み台として利用され、帯域逼迫やサーバー過負荷に陥るだけでなく、ホスティング事業者から規約違反としてアカウントの一時停止（サイト閲覧制限）を受ける恐れがあります。

3. 大量POSTリクエストによるサーバーCPU枯渇・503エラー障害

xmlrpc.php へのリクエストは、WordPressのコアプログラム、PHPインタープリタ、MySQLデータベースの全スタックを起動して認証やクエリ処理を実行するため、静的ファイルへのアクセスに比べて極めて重い処理負荷がかかります。

海外ボットネットから1秒間に数百件規模のPOSTリクエストが送りつけられると、PHP-FPMのワーカープロセスやデータベースの接続プールが一瞬で上限に達し、一般の読者がアクセスした際に「503 Service Unavailable」や「500 Internal Server Error」「Error Establishing a Database Connection（データベース接続確立エラー）」が発生してサイトが完全にダウンしてしまいます。

XML-RPCを停止してもサイト運営に影響はないか？事前チェックリスト

XML-RPCを停止する前に、自社サイトの運用環境に影響がないか以下のチェックリストで確認しましょう。

停止時に確認が必要な特殊ケース

以下のようなサービス・連携を利用している場合のみ、事前確認または後述の「特定IP許可」「機能限定無効化」の対応が必要です：

1. Jetpackプラグインの一部機能：Jetpackの統計情報やソーシャル自動共有、ダウンタイム監視機能の一部は、WordPress.comのサーバーと通信するためにXML-RPCを補助的に利用する場合があります（※後述の特定IP許可設定で共存可能）。
2. 古い外部ブログエディタ：Windows Live Writerなど、10年以上前のレガシーエディタソフト。
3. IFTTTやZapierの古いWordPressトリガー：レガシーなXML-RPCベースのアクション（※現在はWebhookやREST API連携が推奨）。

【方法別】WordPressのXML-RPCを停止・無効化・遮断する5つの手順

WordPressでXML-RPCを停止・遮断する方法には、サーバー層での防御からプラグインによる手軽な設定まで複数のアプローチがあります。自社のサーバー環境や運用スキルに合わせて最適な方法を選択してください。

方法1: .htaccess でアクセスを完全遮断する（最も推奨）

WordPressが稼働しているWebサーバーが Apache または LiteSpeed の場合、ルートディレクトリにある .htaccess ファイルに遮断ルールを追記するのが最も効果的で推奨される方法です。

Webサーバーが xmlrpc.php へのリクエストを受け取った瞬間に「403 Forbidden（アクセス拒否）」を返すため、WordPress本体やPHP、データベースが一切起動せず、サーバーリソースの消費を完全にゼロに抑えられます。

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
    Require all denied
</Files>

※旧世代のApache 2.2系または下位互換性を重視する場合は、以下の記述でも動作します：

# Block WordPress xmlrpc.php requests (Apache 2.2 compatible)
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

方法2: Nginx設定でxmlrpc.phpへのアクセスを拒否する

KUSANAGIやVPS、専用サーバー環境などで Nginx を単独運用している場合は、仮想ホストの server ブロック設定ファイル（例: /etc/nginx/conf.d/your-site.conf）に以下の location ディレクティブを追加します。

# Block xmlrpc.php and suppress logging
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

設定を保存後、nginx -t で構文エラーがないか確認した上で、systemctl reload nginx を実行して反映します。access_log off; を併記しておくことで、攻撃トラフィックによるディスクI/Oやログファイルの肥大化も防ぐことができます。

方法3: セキュリティプラグインでワンクリック無効化（SiteGuard WP Plugin）

コードの編集やサーバー設定に不慣れな場合は、日本国内で多くの実績を持つセキュリティプラグイン「SiteGuard WP Plugin」を利用するのが最も簡単です。

1. WordPress管理画面の左メニューから 「プラグイン」→「新規プラグインを追加」 を開き、「SiteGuard WP Plugin」を検索してインストール・有効化します。
2. 左メニューに表示される 「SiteGuard」→「XML-RPC防御」 をクリックします。
3. 設定画面で 「XML-RPC防御」のスイッチを有効（ON） にします。
4. 動作モードとして 「無効化（XML-RPC全体を停止）」 を選択し、「変更を保存」をクリックします。

※「All-In-One Security (AIOS)」や「Wordfence Security」などの海外製セキュリティプラグインでも、同様に設定画面の「Firewall」や「XML-RPC Prevention」項目からワンクリックで無効化できます。

方法4: functions.php / mu-plugins に無効化フィルターコードを追記する

プラグインを追加せずにWordPressのコード上でXML-RPCを無効化したい場合は、WordPress標準のフィルターフックを利用します。

使用している子テーマの functions.php または、テーマ変更の影響を受けない /wp-content/mu-plugins/disable-xmlrpc.php を新規作成し、以下のコードを記述します：

<?php
/**
 * Plugin Name: Disable XML-RPC Completely
 * Description: 完全なXML-RPC機能の無効化とX-Pingbackヘッダーの削除
 */

// 1. XML-RPC機能自体を完全停止
add_filter('xmlrpc_enabled', '__return_false');

// 2. HTTPレスポンスヘッダーから X-Pingback を削除
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

// 3. XML-RPCメソッド一覧からピンバック関連を明示的に削除
add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

方法5: 主要レンタルサーバーの管理画面からXML-RPC制限を有効化

国内の主要なレンタルサーバーでは、サーバーコントロールパネル上に「XML-RPC APIアクセス制限」機能が用意されています。サーバー側で海外IPからのアクセスや全アクセスを一括遮断できます。

• エックスサーバー（Xserver）：
  サーバーパネルにログイン → 「WordPressセキュリティ設定」→「XML-RPC APIアクセス制限」 を「ON」にする。
• ConoHa WING：
  コントロールパネル → 「サイト管理」→「サイトセキュリティ」→「WordPressセキュリティ」 の「XML-RPC防御」を「ON」にする。
• さくらのレンタルサーバ：
  コントロールパネル → 「Webサイト/ドメイン」→「WAF設定」 およびアクセス制限設定で制御。
• ロリポップ！（LOLIPOP!）：
  ユーザー専用ページ → 「セキュリティ」→「WAF設定」 でXML-RPC関連シグネチャを有効化。

XML-RPC停止後の動作確認・テスト手順

XML-RPCの停止・遮断設定を行ったら、必ず期待通りにブロックされているかを検証しましょう。

1. ブラウザからのアクセス確認

ブラウザのアドレスバーに https://あなたのサイトURL/xmlrpc.php と入力してアクセスします。

• .htaccess / Nginx で遮断した場合：画面に 403 Forbidden エラーが表示されれば遮断成功です。
• functions.php / プラグインで無効化した場合：画面に XML-RPC server accepts POST requests only. と表示されます（※GETリクエストには応答しますが、実際のRPCメソッド処理は拒否されます）。

2. curlコマンドによるPOSTリクエスト送信テスト

より確実に検証したい場合は、パソコンのターミナル（Mac）やコマンドプロンプト/PowerShell（Windows）から curl コマンドでテスト用のPOSTリクエストを送信します：

curl -i -X POST -d "<methodCall><methodName>system.listMethods</methodName><params></params></methodCall>" https://あなたのサイトURL/xmlrpc.php

トラブルシューティング：Jetpackを利用しながらxmlrpc.phpを安全に運用する方法

「Jetpackプラグインの機能を利用したいが、攻撃は防ぎたい」という場合は、Jetpackの通信元IPアドレスのみをホワイトリスト許可し、それ以外のアクセスをすべて遮断する設定を行います。

JetpackのIPアドレスのみを.htaccessで許可する設定例

Automattic社（Jetpackの提供元）が公開している公式IPアドレス帯域（Jetpack IP ranges）を指定し、.htaccess を以下のように構成します：

# Allow Jetpack IPs and block all other xmlrpc.php requests
<Files xmlrpc.php>
    Require all denied
    # Automattic / Jetpack official IP blocks
    Require ip 192.0.64.0/18
    Require ip 198.181.116.0/22
    Require ip 122.248.245.244/32
    Require ip 54.217.201.243/32
    Require ip 54.232.116.4/32
</Files>

この設定を行うことで、JetpackとWordPress.com間の正当な同期通信を維持しながら、世界中からの不正な総当たり攻撃やDDoSリクエストを100%水際でブロックできます。

まとめとMozCheckによるセキュリティ診断の推奨

WordPressのセキュリティ対策における鉄則は、「使っていない不要な通信口（アタックサーフェス）はすべて閉じておくこと」です。

• 現代のWordPressにおいて xmlrpc.php をオープンにしておく必要性はほぼありません。
• サーバー負荷を最も軽減できる .htaccess による完全遮断 または プラグインによる無効化 を今すぐ実施しましょう。
• XML-RPCの停止とあわせて、ログイン画面のURL変更・2段階認証・WAFの有効化・ファイルのパーミッション適正化を組み合わせることで、強固な多層防御が完成します。

あわせて読みたいWordPressセキュリティ＆トラブル解決記事

• Contact Form 7のスパム対策完全ガイド｜海外ボットを遮断するおすすめ設定とTurnstile・Honeypot・Akismet導入手順
• WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで
• 【即時解除】WordPressメンテナンスモードが終わらない原因と直し方｜.maintenanceファイル削除からエラー再発防止まで完全ガイド
• 【即時復旧】WordPress「このサイトで重大なエラーが発生しました」の原因特定と直し方完全ガイド｜リカバリーモード・デバッグ手順
• WordPress乗っ取り被害からの緊急復旧マニュアル｜管理者権限の奪還・バックドア駆除・再発防止策
• WordPressで勝手にリダイレクトされる原因と対策｜リダイレクトハッキングの特定・完全駆除マニュアル
• WordPress改ざん復旧完全マニュアル｜原因特定からバックドア根絶・安全なデータ復元手順まで
• 【完全版】WordPressマルウェア駆除手順｜感染箇所の特定から安全な削除・再感染防止まで
• WordPressセキュリティ診断ツールおすすめ比較｜無料・オンライン・プラグインの選び方
• WordPress監視・保守代行サービスの選び方｜費用相場と失敗しない比較ポイント
• WordPressのユーザー名（ログインID）を隠す完全ガイド｜露出する原因とプラグイン・コードによる漏洩防止手順