WordPressのXML-RPCを安全に無効化する方法

WordPress セキュリティ 2026年6月1日読了 8分

WordPressのxmlrpc.phpは、外部システムからWordPressをリモート操作するためのインターフェースです。便利な機能である一方、ブルートフォース攻撃の入口として悪用されることも多く、不要な場合は無効化することが推奨されます。本記事では、サイトの動作に影響を与えずに安全にXML-RPCを無効化する手順を整理いたします。

この記事でわかること

XML-RPCの役割と攻撃に悪用される理由
無効化する前に確認すべき影響範囲
無効化の3つの方法（プラグイン・.htaccess・関数）の使い分け
無効化後の動作確認方法

XML-RPCとは何か

XML-RPCは「XML Remote Procedure Call」の略で、HTTP通信経由でWordPressにリモートからコマンドを送る仕組みです。WordPressがブログツールとして発展してきた歴史的経緯から、外部のブログクライアントアプリ（古くはWindows Live Writer等）や、モバイルアプリ、Jetpackといったプラグインがこの仕組みを利用してまいりました。

サイトのドキュメントルートに設置されているxmlrpc.phpファイルが、このインターフェースの入口でございます。WordPressをインストールした時点で、誰でもアクセス可能な状態で公開されており、ユーザー側で意識的に無効化しない限り常に有効です。

なぜ攻撃の標的になりやすいのか

XML-RPCは、設計上「1回のリクエストで複数の操作を一気に実行する」ことが可能でございます。system.multicallというメソッドを使うと、たとえばログイン試行を一度のリクエストで数百回繰り返せます。

通常のログイン画面（wp-login.php）に対するブルートフォース攻撃は、ログイン保護プラグインで「N回失敗したらロック」という対策が一般的ですが、XML-RPC経由のsystem.multicallを使うと一度の通信で多数の試行が完結するため、回数制限による防御が機能しにくいのです。

このため、近年のWordPressサイトへの攻撃の多くがXML-RPC経由で行われており、サーバーログを見ると「POST /xmlrpc.php」へのアクセスが大量に記録されているサイトが多くございます。

無効化前の影響範囲確認

XML-RPCを無効化する前に、サイトでこの機能を使っているプラグインや外部連携がないかを確認することが大切でございます。代表的な依存例は次の通りです。

Jetpack

Jetpackは、WordPress.com側とXML-RPC経由で通信する設計が含まれています。ただし近年は、JetpackがREST APIを優先的に使うよう改修されており、多くの機能はXML-RPC無効化後も問題なく動作いたします。とはいえ、サイト統計や一部の連携機能で影響が出る可能性があるため、Jetpackを利用中の場合は無効化後の動作を必ず確認してください。

モバイル投稿アプリ

WordPressモバイルアプリで投稿される場合、古いバージョンのアプリはXML-RPC経由で動作します。最新版のアプリはREST API対応に切り替わっていますが、念のため動作確認をおすすめいたします。

外部の自動投稿ツール

IFTTTやZapierなど、外部の自動連携ツールでWordPressに投稿している場合は、ほぼ確実にXML-RPCに依存しております。無効化前に、連携の方式を「REST API + アプリケーションパスワード」に切り替える対応が必要です。

ピンバック・トラックバック

ピンバック・トラックバックを利用している場合、これもXML-RPC経由で動作しています。ただしスパムの温床となっているため、すでに無効化されているサイトが多く、影響は軽微なケースが大半です。

方法1：セキュリティプラグインで無効化

最も手軽で安全な方法は、セキュリティプラグインの設定で無効化することです。

SiteGuard WP Plugin

日本で広く使われているSiteGuard WP Pluginには「XML-RPC防御」という設定項目があります。管理画面の「SiteGuard → XML-RPC防御」を開き、「ピンバック無効化」と「XML-RPC無効化」を有効に切り替えるだけで完了いたします。

「ピンバック無効化」のみ有効にする選択も可能で、これはピンバック攻撃のみを止めつつ、Jetpack等の連携は維持できる柔軟な設定でございます。

Disable XML-RPC Pingback

軽量なプラグインで、有効化するだけでXML-RPCのピンバック機能を無効化できます。設定画面はなく、有効化と同時に効果が発揮されます。

Wordfence Security

WAF機能を持つセキュリティプラグインで、XML-RPC経由の不正な大量リクエストを自動的にブロックします。プラグインの設定で「ブロックする」を選択することで、XML-RPC自体の応答を遮断することも可能です。

方法2：.htaccess で遮断

プラグインに依存せず、サーバーレベルで遮断する方法です。サイトのドキュメントルートにある.htaccessに次の記述を追加します。

# XML-RPC 遮断
<Files xmlrpc.php>
    Require all denied
</Files>

古いApache（2.2以前）の場合は次の書式となります。

# XML-RPC 遮断（Apache 2.2 形式）
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

この方法のメリットは、WordPressが動く前のApacheレベルで遮断するため、サーバー負荷が最小になることです。デメリットは、特定のIPだけアクセスを許可するなどの柔軟な制御がやや書きにくい点です。

特定IPのみ許可したい場合は次のように記述します。

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

方法3：関数フィルターで無効化

テーマのfunctions.phpまたは独自プラグイン内に、次のフィルターを追加することで、XML-RPCのメソッド呼び出し自体を無効化できます。

// XML-RPC を完全無効化
add_filter('xmlrpc_enabled', '__return_false');

これにより、xmlrpc.phpへのアクセス自体はできますが、すべてのメソッドが「呼び出し拒否」となり、実質的に機能を無効化できます。

より細かく、ピンバックのみを無効化したい場合は次のフィルターを追加します。

// ピンバックメソッドのみ無効化
add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

この方法はサーバー側の設定変更が不要で、WordPress内部で完結するため、サーバー管理権限がない環境でも適用可能でございます。

無効化後の動作確認

設定後は、必ず動作確認を実施してください。

① xmlrpc.php へのアクセス確認

ブラウザでhttps://example.com/xmlrpc.phpにアクセスしてみてください。

方法1・2（プラグイン・.htaccess）の場合：「403 Forbidden」または専用エラーページが表示
方法3（関数フィルター）の場合：「XML-RPC services are disabled on this site.」と表示

② サーバーログでアクセス減少を確認

サーバーのアクセスログで、無効化前後のxmlrpc.phpへのアクセス状況を比較します。攻撃側も時間をかけて減っていくため、即座にゼロにはなりませんが、数日〜数週間で大幅に減少する傾向がございます。

③ 既存連携の動作確認

事前に把握した連携（Jetpack、モバイルアプリ、外部投稿ツール等）が引き続き動作するかを確認します。問題があれば、即座にロールバックできる状態を保ったうえで設定を行うことが大切です。

まとめ

XML-RPCの無効化は、WordPressサイトのセキュリティ対策の中でも費用対効果が高い施策でございます。多くのサイトでは無効化による実害はなく、攻撃の入口を1つ閉じる効果のみが残ります。

導入手順を整理しますと次の通りです。

サイトでXML-RPCに依存している機能（Jetpack、モバイルアプリ、外部連携）がないか棚卸しする
影響がないことを確認したのち、プラグイン・.htaccess・関数フィルターのいずれかで無効化する
無効化後、xmlrpc.phpへのアクセスが遮断されていることを確認
サーバーログでアクセス減少を継続的に観察

セキュリティ対策は「攻撃を完全に防ぐ」よりも「攻撃面を1つずつ減らす」という考え方が現実的です。XML-RPC無効化は、その第一歩として最初に着手すべき項目と考えております。