「自分のWordPressが、知らないうちに他人へのサイバー攻撃に使われているかもしれない」と聞くと、ぞっとしませんか。私自身、サーバーのアクセスログを眺めていて、xmlrpc.php という見慣れないファイルに対する大量のリクエストに気づいて手が止まった経験があります。これは「Pingback（ピンバック）」という機能を悪用した攻撃の足跡で、放っておくと自分のサイトが攻撃の「踏み台」にされてしまいます。
厄介なのは、踏み台にされても自分のサイトが派手にダウンするわけではなく、被害者は別のサーバーだという点です。だから気づきにくく、気づかないまま加害者側に回り続けてしまいます。
しかも、このPingbackは多くのWordPressで初期状態のまま有効になっています。対策していないサイトは今でも珍しくありません。長年Webに関わってきた私の体感でも、ここはセキュリティの「やり忘れ」の定番です。
この記事では、Pingbackを悪用したDDoS攻撃の仕組みと、自分のサイトを踏み台にされないための具体的な対策を、2026年時点で本当に有効な方法に絞って解説します。コードを触りたくない方向けの手順も用意したので、自分のサイトに合うやり方を選んでください。
そもそもPingbackとは何か
Pingbackとは、自分の記事が他のサイトからリンクされたとき、その事実を自動で通知し合う仕組みです。たとえばどこかのブログが私の記事を紹介してくれると、「あなたの記事にリンクが張られましたよ」という通知が私のサイトに届く、といった使われ方をします。
この通知のやりとりにWordPressが使っているのが、ルート直下にある xmlrpc.php というファイルです。これは「XML-RPC」という、外部のアプリやサービスとWordPressをつなぐための古くからある窓口で、Pingbackのほかにスマホアプリからの投稿などにも使われてきました。
機能としては便利なのですが、この「外部からの指示を素直に受け付けて、別のサーバーへアクセスしに行く」という性質こそが、悪用の入り口になっています。
Pingbackを悪用したDDoS攻撃の仕組み
DDoS攻撃とは、世界中の大量のコンピュータから一つのサーバーへ一斉にアクセスを浴びせ、相手をパンクさせる攻撃です。Pingbackの悪用は、この「大量のアクセス元」として、世界中のごく普通のWordPressサイトを利用します。
流れをかみ砕くと、こうです。攻撃者は、Pingbackが有効なWordPressサイトを大量にリストアップしておきます。そして各サイトの xmlrpc.php に対して、「このURL（＝攻撃したい標的）からあなたへリンクが張られたので確認しに行ってほしい」という偽のPingbackリクエストを送りつけます。
指示を受けたWordPressは、律儀に「本当にリンクが張られているか確認しよう」として、標的のサーバーへアクセスしに行きます。これが何万ものサイトで同時に起きると、標的のサーバーには各地から一斉にアクセスが殺到し、処理しきれずにダウンします。
これは「リフレクション（反射）攻撃」と呼ばれる手口です。攻撃者は小さな指示を送るだけで、踏み台にされたサイトが何倍もの負荷を標的に向けて生み出してくれる――つまり攻撃を「増幅」できてしまうわけです。Cloudflareのレポートでは、標的のキャッシュを無効化するためにURLへ毎回異なるクエリ文字列を付けるなど、手口が巧妙化している例も報告されています。過去には16万を超えるWordPressサイトが一斉に踏み台として使われた攻撃も観測されました。
ここで強調したいのは、悪用された自分のサイトは「攻撃される側」ではなく「攻撃に加担させられる側（踏み台）」になるという点です。自分のサイトが直接落ちるとは限らないので、被害が見えにくい。だからこそ、攻撃される前に運営者の側で能動的にふさいでおく必要があります。
出典：Cloudflare「WordPress Pingback Attacks and our WAF」
2026年のいま、まず知っておきたい前提
対策に入る前に、ひとつ大事な前提を共有しておきます。2026年現在、ほとんどのサイトにとってXML-RPCはもう「役目を終えた古い窓口」になっています。
というのも、WordPress 4.7以降は「REST API」というJSON形式の新しい連携の仕組みが主役になり、外部アプリやサービスとの連携はそちらで完結するようになったからです。Patchstackなどのセキュリティベンダーも、REST APIがXML-RPCを置き換えたこと、そして現代では多くのサイトにとってXML-RPCは利点よりリスクが上回る存在になっていると指摘しています。
つまり、Jetpackや一部の古い外部ツールを意識的に使っている場合を除けば、XML-RPCは丸ごと止めてしまっても困らないケースがほとんどだということです。この前提を踏まえると、後述する対策の選び方がぐっと分かりやすくなります。
出典：Patchstack「Understanding XML-RPC in WordPress」
自分のサイトが踏み台にされていないか確認する
対策の前に、まず現状を確認しましょう。チェックの仕方は大きく二つあります。
一つ目は、ブラウザで https://（自分のドメイン）/xmlrpc.php にアクセスしてみる方法です。「XML-RPC server accepts POST requests only.」のようなメッセージが表示されたら、このファイルが外部から到達できる状態です。これ自体がただちに被害を意味するわけではありませんが、Pingbackが有効なら踏み台に使われ得る、というサインだと考えてください。
二つ目は、より確実な方法で、サーバーのアクセスログを見る方法です。xmlrpc.php に対して短時間に大量のPOSTリクエストが記録されていたら要注意。とくに、リクエスト元のユーザーエージェントが WordPress/x.x.x; http://... のような形（バージョン番号とURLを含む独特の文字列）になっているものが並んでいたら、Pingbackの仕組みを通じた不審なアクセスである可能性が高いです。
ログを直接見るのが難しければ、Wordfenceなどのセキュリティプラグインを入れておくと、こうした不審なアクセスの検知やブロックを自動でやってくれるので、状況の把握が一気にラクになります。
踏み台にならないための具体的な対策
対策は一つではなく、サイトの使い方に応じて組み合わせます。基本方針は「まずPingbackを受け付けない」、そのうえで「XML-RPCを使っていなければ窓口ごと閉じる」です。手軽な順に紹介します。
① Pingback・トラックバックを受け付けない設定にする
もっとも手軽で、コードも不要な対策です。これから書く投稿でPingbackを受け付けないようにします。
- WordPressのダッシュボードにログインする
- 「設定」→「ディスカッション」を開く
- 「他のブログからの通知（ピンバック・トラックバック）を受け付ける」のチェックを外す
- 「変更を保存」をクリックする
これだけで、少なくとも今後の踏み台リスクは下げられます。
② すでに投稿済みの記事のPingbackも一括で止める
①はこれからの投稿向けの設定なので、すでにある記事には一括操作で適用します。記事数が多いサイトほど効いてきます。
- ダッシュボードで「投稿」→「投稿一覧」を開く
- タイトル横のチェックボックスで対象記事をすべて選択する
- 「一括操作」のプルダウンで「編集」を選び「適用」をクリックする
- 「トラックバック/ピンバック」の項目を「許可しない」に変更する
- 「更新」をクリックする
③ XML-RPC自体を無効化する
前述のとおり、いまどきのサイトはXML-RPCを使っていないことが多いので、窓口ごと閉じてしまうのが確実です。テーマの functions.php（できれば子テーマ側）に次の一行を追加すると、XML-RPCの機能が無効になります。
add_filter( 'xmlrpc_enabled', '__return_false' );ただし注意点があります。XML-RPCは、Jetpackや一部の古い外部投稿ツールなどでまだ使われていることがあります。これらを利用している場合、丸ごと無効化すると正しく動かなくなるので、使っていないことを確認してから実施してください。
④ X-Pingbackヘッダを消して「窓口の宣伝」をやめる
WordPressは初期状態で、ページを返すたびに X-Pingback というHTTPヘッダを付けています。これは「うちはPingbackを受け付けますよ、窓口はここです」と外部に教えているようなもので、攻撃用のボットはこれを手がかりに xmlrpc.php を探しに来ます。
③と合わせて、このヘッダ自体も消しておくと、不要な探索アクセスを減らせます。functions.php に以下を追加します。
add_filter( 'wp_headers', function( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
} );なお「XML-RPCは残したいけれど、悪用されるPingback機能だけは確実に止めたい」という場合は、Pingback関連のメソッドだけを取り除くこともできます。
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );⑤ .htaccessやサーバー設定でxmlrpc.phpを遮断する
Apache系のサーバーなら、.htaccess に記述して xmlrpc.php へのアクセスそのものをブロックできます。WordPress本体に手を入れずにサーバー側でふさげるので、私はこの方法も併用しています。
<Files xmlrpc.php>
Require all denied
</Files>古いApacheや環境によっては、次の旧い書き方が必要な場合もあります。うまく効かないときは利用中のレンタルサーバーのマニュアルを確認してください（Nginxの場合は .htaccess ではなくサーバー設定ファイル側での記述になります）。
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>⑥ プラグインやWAF・CDNでまとめて守る
コードを触るのが不安なら、プラグインに任せるのが安全です。WordPress公式の「Disable XML-RPC Pingback」は、XML-RPC全体を止めるのではなく、悪用されるPingback関連の機能だけを取り除いてくれます。Jetpackなどを使いつつ攻撃だけ防ぎたい場合に向いています。
さらに、WordfenceのようなセキュリティプラグインやCloudflareのようなWAF・CDNを併用すると、Pingbackに限らず不審なアクセスをまとめて遮断できます。実際、CloudflareはWordPressのPingback攻撃をブロックする専用のWAFルールを用意しており、こうした上位レイヤーでの防御を一枚かませておくと、対策の取りこぼしを大きく減らせます。
出典：WordPress.org「Disable XML-RPC Pingback」 ／ Patchstack「Understanding XML-RPC in WordPress」
結局どれを選べばいい？
迷ったときの目安を、私なりに整理しておきます。
XML-RPCを特に使っていないサイト（＝大多数）なら、①でPingbackを止め、③④でXML-RPCを無効化＋X-Pingbackヘッダを削除、可能なら⑤の .htaccess 遮断まで重ねるのが一番確実です。窓口を閉じて、看板も外して、サーバーの入口でも止める、という多重防御の形になります。
スマホ連携やJetpackなどでXML-RPCを使っているサイトは、丸ごと無効化すると不都合が出るので、④のメソッド単位の停止か、⑥の「Disable XML-RPC Pingback」プラグインで、悪用されるPingback機能だけをピンポイントで取り除くのが安全です。
そして、どのパターンでも⑥のWAF・CDNを一枚かませておくと安心感が違います。
あわせて読みたい関連記事
WordPressのセキュリティは、Pingback対策だけで終わりではありません。攻撃の入口になりやすいポイントは合わせてふさいでおくのがおすすめです。
まとめ
Pingbackを悪用したDDoS攻撃は、自分のサイトが被害者ではなく加害者（踏み台）にされてしまう点が最大の特徴です。被害が見えにくいぶん、放置されやすい落とし穴でもあります。
そして2026年のいま、XML-RPCはREST APIにその役目を譲っており、多くのサイトにとっては「使っていないなら閉じておくべき古い窓口」になっています。まずやるべきは次の3つです。
- 「設定」→「ディスカッション」でPingbackの受け付けをオフにする（①②）
- XML-RPCを使っていないなら、
functions.phpで無効化しX-Pingbackヘッダも削除する（③④）。Apacheなら.htaccessでxmlrpc.phpも遮断する（⑤） - WordfenceやCloudflareなどのプラグイン・WAFを一枚かませておく（⑥）
コードが苦手なら、無理せず「Disable XML-RPC Pingback」プラグインだけでも入れておけば、最低限の踏み台対策にはなります。一番もったいないのは、初期設定のまま何もしないこと。5分の設定で、自分のサイトが知らぬ間に攻撃の片棒を担ぐ事態は十分に防げます。今日のうちに、ディスカッション設定のチェックを一つ外すところから始めてみてください。
