WordPressのXML-RPCとは？無効化すべき理由と実際の対応事例

先日、あるクライアントのWordPressサイトについて、サイトの管理会社から連絡が届きました。内容を要約すると、XML-RPCを悪用した攻撃によるサイト乗っ取り事例が確認されたため管理サイトを調査したところ、当該サイトでXML-RPC機能が有効になっていることが判明した、運用上支障がないことを確認のうえ無効化してほしい、というものです。

結論から言うと、スマホのWordPress公式アプリや一部の外部連携で使っていない限り、XML-RPCは無効化すべき機能です。ただし、その「使っていない」の確認を飛ばして作業すると、思わぬ機能停止を招きます。同じような連絡を受けた担当者の方、これから受けるかもしれない制作会社の方に向けて、XML-RPCとは何か、なぜ問題なのか、影響をどう確認するか、そしてENVY DESIGNが実際にどう対応したかをまとめます。

XML-RPCとは

XML-RPCは、WordPressを外部から遠隔操作するための通信の仕組みです。WordPressのインストールディレクトリ直下にある xmlrpc.php というファイルがこの機能を担っており、外部のアプリケーションからこのファイルに命令を送ることで、管理画面にログインしなくても記事の投稿や編集ができます。

代表的な用途は、スマートフォンのWordPress公式アプリからの記事投稿です。ほかにも、Jetpackプラグインの一部機能や、外部のブログ投稿クライアント、他サイトからのピンバック受信などがXML-RPCを使います。

ただし、XML-RPCは古い仕組みです。現在のWordPressにはREST APIという後継の仕組みがあり、外部連携の主流はそちらに移っています。XML-RPCが今も残っているのは、主に古い環境との互換性を保つためです。それにもかかわらず、WordPressをインストールするとxmlrpc.phpは標準で設置され、機能も有効になっています。

何が問題なのか

XML-RPCの問題は、この仕組みが「認証機能つきの裏口」として攻撃に悪用される点にあります。悪用のパターンは大きく2つです。

ブルートフォース攻撃（不正ログインの試行）

攻撃者はxmlrpc.phpに対してユーザー名とパスワードの組み合わせを機械的に送りつけ、正解を探します。パスワードの総当たりは通常のログイン画面（wp-login.php）でも可能ですが、XML-RPC経由が特に狙われる理由が2つあります。

1つ目は、ログイン画面の防御をすり抜けられることです。画像認証やログイン試行回数の制限といった対策の多くはログイン画面を対象にしているため、xmlrpc.phpからの認証試行には効かないケースが多くあります。

2つ目は、system.multicallという機能による攻撃の増幅です。XML-RPCには複数の命令を1回のリクエストにまとめて送る仕組みがあり、これを悪用すると、1回のHTTPリクエストに数百から数千通りのパスワード候補を詰め込んで一括で試せます。通常のログイン画面では1リクエストで1回しか試行できないところ、桁違いの効率で攻撃でき、しかもアクセスログ上は少数のリクエストにしか見えないため検知されにくいという厄介な特性があります。

パスワードが破られれば管理者権限を奪われ、サイトの改ざんやマルウェアの設置、スパム配信の踏み台化といった、いわゆる乗っ取りに至ります。

ピンバック機能の悪用（DDoS攻撃の踏み台）

XML-RPC経由で「このサイトにピンバックを送って」と依頼できる仕組みを悪用し、多数のWordPressサイトに一斉に命令を出して、特定の標的サイトへアクセスを集中させる手口です。この場合、自分のサイトが被害者ではなく、攻撃の道具として加害者側に加担させられてしまいます。

無効化の前に確認すべきこと

「使っていないなら無効化する」が定石ですが、実務ではこの「使っていない」の確認が一番重要です。今回、私たちは以下を確認しました。

スマホのWordPress公式アプリで更新していないか

一番影響が出やすいのがこれです。スマートフォンのWordPress公式アプリからの記事更新はXML-RPCを使うため、無効化すると使えなくなります。注意したいのは、スマホでの更新がすべて該当するわけではない点です。スマホのブラウザ（SafariやChrome）から管理画面にログインして更新している場合はXML-RPCを使いません。担当者にヒアリングする際は「スマホで更新しているか」ではなく「アプリか、ブラウザか」を聞くのがポイントです。

XML-RPCを使うプラグインが入っていないか

代表格はJetpackです。WordPress.comとの連携にXML-RPCを使うため、導入サイトで無効化すると統計情報などの機能が止まります。プラグイン一覧を確認し、Jetpackや外部連携系のプラグインの有無をチェックします。

外部サービスとの連携がないか

今回のサイトには、外部のシステムと連携したイベント予約の仕組みがありました。一見するとXML-RPC無効化の影響を受けそうに思えますが、調べてみると予約機能は完全に外部のプラットフォーム上で動いており、WordPressサイトからは単にリンクを張っているだけでした。XML-RPC無効化で影響が出るのは「外部からxmlrpc.php宛てに通信してくるもの」だけなので、こうした構成であれば影響はありません。

見た目上「連携しているように見える」機能が、実際にどのサーバーのどの仕組みで動いているかを切り分けることが、影響確認の本質です。ここを曖昧にしたまま「たぶん大丈夫」で進めると、無効化後に想定外の機能停止を起こしかねません。

無効化する3つの方法

無効化の方法は大きく3つあります。それぞれ効果と特性が異なります。

1. functions.phpにコードを書く

テーマのfunctions.phpに次の1行を追加する方法です。

add_filter('xmlrpc_enabled', '__return_false');

手軽ですが、弱点が2つあります。まず、このフィルターが止めるのは認証が必要なメソッドだけで、xmlrpc.php自体は生きて応答を返し続けます。ブルートフォースの入口は塞げますが、ピンバック悪用は防げず、攻撃リクエストのたびにPHPが実行されるためサーバー負荷も減りません。また、親テーマのfunctions.phpに書いた場合、テーマの更新で記述が消えます。

2. .htaccessで遮断する

.htaccessに次の記述を追加し、xmlrpc.phpへのアクセス自体をWebサーバーの段階で拒否する方法です。

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

認証試行もピンバック悪用も含めて完全に遮断でき、PHPが実行される前に弾くため攻撃が来てもサーバー負荷がほぼかかりません。テーマやWordPressの更新にも影響されず、戻したいときは記述を削除するだけです。遮断の完全性と変更の小ささでは、この方法が最も優れています。

3. セキュリティプラグインを使う

SiteGuard WP Pluginなどのセキュリティプラグインには、XML-RPCを無効化する機能があります。SiteGuardの場合、内部的には.htaccessに遮断の記述を書き込む方式のため、遮断効果は方法2と同等です。プラグインが1つ増える分、今後のアップデート管理対象は増えますが、ログインURLの変更や画像認証など、XML-RPC以外のセキュリティ機能もまとめて管理できます。

今回の対応：SiteGuardを選んだ理由

ENVY DESIGNは今回、SiteGuard WP Pluginでの無効化を選びました。

今回の要件を満たすだけなら、.htaccessへの数行の追記で足ります。それでもプラグインを選んだのは、このサイトにはセキュリティ対策のプラグインが入っておらず、今後ログインURLの変更をはじめとしたセキュリティ強化をクライアントと相談していく前提があったためです。その際、SiteGuardが入っていれば設定をONにするだけで対応でき、対応の土台を先に作っておく判断をしました。

XML-RPC無効化という単発の作業として見るか、サイトのセキュリティ改善の第一歩として見るかで、最適な方法は変わります。単発なら.htaccess、継続的に関わるならプラグイン、というのが今回の整理です。

SiteGuard導入時の注意点：ログインURL変更がデフォルトでONになる

SiteGuardを導入する際に、知っておかないと事故につながるポイントがあります。SiteGuardは有効化した瞬間に、ログインページのURL変更と画像認証がONになります。機能を選んでから有効になるのではなく、全部ONで始まって不要なものを後から切る設計です。

有効化直後に表示される新しいログインURLを控えずにブラウザを閉じてしまい、自分が管理画面に入れなくなるというのが、SiteGuard導入トラブルの定番です。導入時は、有効化前に.htaccessのバックアップを取り、有効化したらその場で新URLを控え、設定画面で不要な機能をOFFにする、という手順を踏むことをおすすめします。

今回のサイトは利用しているユーザーアカウントが多く、周知なしにログインURLが変わると現場が混乱するため、ログインURL変更の機能はいったんOFFに戻しました。不正ログイン対策として有効な機能ではありますが、導入するなら全ユーザーへの事前周知とセットで行うべきもので、依頼された作業範囲を超えて勝手に運用を変えるべきではないと判断したためです。ログインURL変更は、周知の段取りを含めて今後クライアントと相談していく項目として残しています。

無効化できているかの確認

作業後は、ブラウザで自サイトのURLの末尾に /xmlrpc.php を付けてアクセスします。403 Forbiddenなどのエラーが表示されれば、遮断できています。逆に「XML-RPC server accepts POST requests only.」と表示される場合、XML-RPCは生きています。この確認方法は無効化の前に現状を把握する手段としても使えるので、自社サイトや管理しているサイトで一度確認してみることをおすすめします。

よくある質問

XML-RPCを無効化するとREST APIやブロックエディタに影響はありますか？

影響ありません。REST APIはXML-RPCとは別の仕組みで、ブロックエディタ（Gutenberg）や多くのプラグインが使っているのはREST APIの方です。xmlrpc.phpへのアクセスを遮断しても、管理画面での編集や通常のサイト表示には影響しません。

ログイン画面に画像認証を入れていれば、XML-RPCは有効のままでも安全ですか？

安全とは言えません。画像認証やログイン試行回数制限の多くはログイン画面（wp-login.php）を対象としており、xmlrpc.php経由の認証試行には効かないケースが多くあります。ログイン画面の対策とXML-RPCの無効化は別物として、両方を行う必要があります。

無効化した後に必要になった場合、元に戻せますか？

戻せます。.htaccessで遮断した場合は追記した記述を削除するだけ、SiteGuardの場合は設定画面でXMLRPC防御をOFFにするだけです。データが消える類の変更ではないため、切り戻しは数分で完了します。

自分のサイトでXML-RPCが有効か確認する方法はありますか？

ブラウザでサイトURLの末尾に /xmlrpc.php を付けてアクセスしてください。「XML-RPC server accepts POST requests only.」と表示されれば有効、403 Forbiddenなどのエラーが表示されれば遮断されています。

まとめ

XML-RPCは、スマホの公式アプリやJetpackを使っていないサイトであれば、無効化してもデメリットは実質なく、リスクだけを消せます。一方で、その「使っていない」の確認は、ヒアリングだけでなくプラグイン構成や外部連携の実態まで調べて初めて自信を持って判断できるものです。

また、今回のような指摘は、制作から年数が経ち、保守契約のないままになっているサイトで起こりがちです。制作当時のセキュリティ水準のまま止まっているサイトは、XML-RPCに限らず見直しの余地が残っていることが多くあります。管理会社や外部からセキュリティの指摘を受けた際は、指摘された1点だけを塞いで終わりにするのではなく、サイト全体のセキュリティを見直すきっかけにしていただくのが良いと思います。

関連記事

• WordPressの緊急脆弱性「wp2shell」の概要と対応手順｜初心者向けに解説
• ホームページ公開前に確認すべきチェックリストとは
• WordPressのプラグインが更新できない原因はファイル所有者のズレ｜FTPでの解決手順

お問い合わせ

ENVY DESIGNでは、Webサイトの制作・保守運用の一環として、WordPressサイトのセキュリティ対応のご相談を承っています。今回のような外部からの指摘への対応にお困りの際は、お気軽にご相談ください。

こうしたセキュリティ対応を含む継続的な保守は、ホームページ保守・運用サポートのページでご紹介しています。