xmlrpc.php攻撃とは？WordPressで無効化する方法と有効か確認する手順【2026年7月】

xmlrpc.phpは、WordPressを外部から操作するための古い窓口です。総当たり攻撃の増幅やDDoSの踏み台に悪用されるため、使っていなければ無効化（遮断）が推奨されます。この記事では、攻撃の仕組み、自分のサイトで有効かどうかの確認方法、そして確実に無効化する手順を、実際に自社サイトで遮断した経験をもとに解説します。

xmlrpc.phpとは？何のための機能か

xmlrpc.phpは、WordPressを外部のソフトから遠隔操作するための入口（XML-RPCという通信規格の窓口）です。WordPressをインストールすると、標準でサイトの直下（例：あなたのサイト/xmlrpc.php）に置かれています。

もともとは次のような用途で使われてきました。

• スマートフォンのWordPressアプリからの投稿
• 他サイトとのピンバック・トラックバック（言及の通知）
• Jetpackなど一部プラグインの外部連携

しかし現在は、これらの多くが後継のREST APIに置き換わっており、多くのサイトでxmlrpc.phpは使われていません。使っていないのに開いたままだと、攻撃の入口だけが残ることになります。

xmlrpc.phpが狙われる2つの攻撃

xmlrpc.phpが悪用される代表的な攻撃は、ブルートフォース（総当たり）の増幅とPingbackを悪用したDDoS・踏み台化の2つです。

攻撃	仕組み	被害
ブルートフォース増幅（system.multicall）	1回のリクエストに数百のID・パスワードの組み合わせを詰め込める。通常のログイン回数制限を回避して高速に試行される	管理画面を乗っ取られる
Pingback悪用（pingback.ping）	攻撃者が多数のサイトのxmlrpc.phpに指示を出し、標的サイトへ一斉にリクエストを送らせる。あなたのサイトが「加害者」の踏み台にされる	他サイト攻撃への加担・自サイトの高負荷

とくにsystem.multicallは、ログイン試行回数の制限（数回失敗したらロックする類の対策）をすり抜けてしまうのが厄介な点です。ログイン画面をいくら守っても、xmlrpc.phpが開いていれば裏口から総当たりされる余地が残ります。

自分のサイトでxmlrpcが有効か確認する方法

確認は簡単です。ブラウザのアドレスバーに「あなたのサイト/xmlrpc.php」と入力してアクセスしてください。

• 「XML-RPC server accepts POST requests only.」と表示される → 有効（開いている）
• 「Forbidden」やエラー（403など）で見られない → すでに遮断されている

複数の項目をまとめて確認したい場合は、URLを入れるだけの無料WordPress脆弱性診断でも、XML-RPCの状態を含む17項目をその場でチェックできます。診断のやり方はWordPress脆弱性診断のやり方で解説しています。

xmlrpc.phpを無効化する3つの方法

無効化には主に3つの方法があります。サーバ負荷が最も小さく確実なのは「.htaccessでの遮断」です。難易度と確実性で選んでください。

方法	難易度	確実性	備考
.htaccessで遮断	中（要サーバ操作）	高（ファイルごと遮断）	サーバ負荷が最小。Apache環境向け
プラグインで無効化	低（管理画面のみ）	中〜高	SiteGuardや専用プラグイン。手軽
functions.phpのフィルタ	中（コード編集）	低〜中	機能は止まるが窓口は応答が残る場合あり（後述）

方法1：.htaccessで遮断する（推奨）

サーバの.htaccessに次の記述を追加すると、xmlrpc.phpへのアクセスをファイルごと遮断できます（Apache 2.4の場合）。

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

記述後、xmlrpc.phpにアクセスして「Forbidden（403）」になれば成功です。サーバ操作に不安がある場合は、次のプラグイン方式が安全です。

方法2：プラグインで無効化する（手軽）

管理画面だけで完結させたいなら、国産の「SiteGuard WP Plugin」や、XML-RPCを無効化する専用プラグインを使います。ピンバックだけを止めたい場合は、pingbackに限定して無効化できるプラグインもあります。プラグインの入れすぎは避け、既存のセキュリティプラグインで対応できないか先に確認しましょう。

方法3：functions.phpのフィルタ（限定的）

テーマのfunctions.phpに次の1行を追加すると、XML-RPCの機能自体を無効化できます。

add_filter( 'xmlrpc_enabled', '__return_false' );

ただしこの方法には落とし穴があります。次のセクションで、実際に自社サイトで遭遇した注意点を紹介します。

【実例】「無効化したつもり」の落とし穴

当サイトを自社の診断ツールで点検したとき、XML-RPCが「有効」と判定されました。調べると、フィルタや設定で機能を止めても、xmlrpc.phpというファイル自体は残り、アクセスすると「POSTのみ受け付ける」という応答（405）を返し続けていたのです。

外部のスキャナ（診断ツール）は、xmlrpc.phpが200や405で応答すると「窓口が生きている＝有効」とみなします。つまり「機能は無効化したつもり」でも、窓口が応答している限り、攻撃の対象としては残り続けるということです。実際、この状態でxmlrpc.phpにPOSTを送ると、通常の応答が返ってきました。

そこで.htaccessでファイルごと遮断（403化）したところ、診断は「有効」判定が消え、スコアも改善しました。教訓は明確です。

• 「機能を無効化」だけでは、窓口（ファイル）が応答を返し続けることがある
• 確実に消すなら、ファイルレベルでの遮断（.htaccess等で403）が有効
• 対策後は必ず、xmlrpc.phpにアクセスするか診断ツールで「本当に閉じたか」を確認する

無効化してはいけないケース（先に確認）

xmlrpc.phpを使っている場合は、無効化すると機能が止まります。次に当てはまるなら、無効化の前に影響を確認してください。

• Jetpackなど、XML-RPCを使うプラグインを利用している
• WordPressのスマホアプリから投稿・管理している
• 外部サービスとの連携でXML-RPC経由の投稿・取得をしている

これらを使っていない一般的なサイトであれば、無効化して問題ありません。「ピンバックの悪用だけ止めたい」場合は、pingbackに限定して無効化する方法もあります。

まとめ：使っていなければファイルごと遮断が確実

xmlrpc.phpは、総当たり攻撃の増幅やDDoSの踏み台に悪用される古い窓口です。Jetpackやスマホアプリなどで使っていなければ、.htaccessでファイルごと遮断するのが最も確実です。機能の無効化だけでは窓口が応答を返し続けることがあるため、対策後は必ず「本当に閉じたか」を確認しましょう。

よくある質問（FAQ）

Q. xmlrpc.phpは削除してもいいですか？

ファイルを削除しても、WordPress本体を更新すると再び作成されます。削除より、.htaccessでの遮断やプラグインでの無効化のほうが、更新に影響されず確実です。

Q. 無効化するとSEOに悪影響はありますか？

ありません。xmlrpc.phpは検索エンジンの評価には関係しない機能です。むしろ攻撃の入口を減らせるため、サイトの安定運用に役立ちます。

Q. WordPressを更新するとxmlrpc.phpは復活しますか？

ファイル自体は更新のたびに再配置されます。ただし.htaccessでの遮断設定は残るため、遮断方式であれば更新後も無効化が維持されます。

Q. REST APIも無効にすべきですか？

REST APIは現在のWordPressやプラグインが動作に使う重要な仕組みのため、安易な無効化は不具合の原因になります。REST APIは無効化ではなく、ユーザー情報の露出を絞るなどの個別対策が基本です。

Q. 無効化できたか確認するには？

xmlrpc.phpにアクセスして「Forbidden（403）」になっていれば遮断成功です。無料の脆弱性診断ツールでも、XML-RPCが有効か無効かを判定できます。

免責事項

本記事は一般的な情報提供を目的としており、記載内容は2026年7月時点の情報にもとづきます。サーバ設定やfunctions.phpの編集は、誤るとサイトが表示されなくなる場合があります。作業前に必ずバックアップを取り、不安な場合は専門の事業者にご相談ください。