Trends

なぜWordPressが狙われるのか：ボットがWPサイトを標的にする技術的理由

2月 25, 2026 · 4 min read

WordPressサイトは、運営者が意識していなくても、日常的に自動化された攻撃リクエストを受けている。Wordfenceをはじめとするセキュリティベンダーは、WordPressサイトへの攻撃リクエストが高頻度で発生していることを継続的に報告している。

攻撃が集中する理由は、WordPressが「弱い」からではない。構造が標準化されているからだ。

WordPressはWebの約43%を支えている（W3Techs、2026年3月）。しかし、市場シェアだけが標的になる理由ではない。本当の問題は、WordPressが統一されたディレクトリ構造、標準的なAPIエンドポイント、予測可能なフォーム構造を持っており、1つのスクリプトで修正なしに大量のサイトを攻撃できることにある。

この記事では、ボットがWordPressサイトをどのように特定し、どの技術的パターンを悪用するのかを解説した上で、実務で即実行できるWordPressセキュリティ対策を体系的に整理する。

なぜWordPressが狙われるのか：「開発者体験の良さ」が攻撃者にも恩恵を与えている

WordPressのセキュリティに関する議論は、古いプラグインや弱いパスワードに焦点が当たりがちだ。それらも重要だが、根本的な問題を見落としている。

WordPressの最大の強みは、開発者体験（Developer Experience）の良さだ。統一されたディレクトリ構造、充実した公式ドキュメント、標準化されたREST API、一貫性のあるフック体系——これらが世界中の開発者に選ばれる理由になっている。

しかし、この「わかりやすさ」は攻撃者にも同じ恩恵を与えている。WordPressは、APIの仕様を公式ドキュメントで完全公開している数少ないCMSだ。開発者がドキュメントを読んでプラグインを作るのと同じように、攻撃者もドキュメントを読んでエクスプロイトを作れる。1つのスクリプトで多数のサイトに対して同じ攻撃を試みることができるのは、この標準化の直接的な帰結だ。

もちろん、RailsやDjangoにも規約ベースの予測可能性はある。しかしWordPressは、標準化の度合い × 市場シェアの規模の掛け算で、他のCMS・フレームワークと一線を画している。攻撃者にとっての費用対効果が、構造的に高い。

攻撃の経済性

インターネットの43%に対して機能するスクリプトを1本書くことは、攻撃者にとって圧倒的に効率的だ。ターゲットあたりのコストはほぼゼロに下がる。WordPressが狙われるのは、弱いからではなく、均一だからだ。

技術的解説：ボットがWordPressサイトをマッピングする手法

自動スキャナーがあなたのドメインにアクセスしたとき、何をするのかを具体的に見ていく。攻撃者の手法を理解することが、WordPressセキュリティ対策の第一歩だ。

1. フィンガープリンティング：WordPressであることの特定

ペイロードを送信する前に、ボットはターゲットがWordPressを実行していることを確認する。HTTPリクエスト1回で完了する。

GET / HTTP/1.1
Host: example.com

レスポンスに含まれる手がかり：

Metaジェネレータータグ: <meta name="generator" content="WordPress 6.x" />
標準パス: /wp-content/、/wp-includes/、/wp-admin/
CSSクラス名: .wp-block-、.entry-content、.wp-post-image
スクリプトハンドル: wp-embed.min.js、jquery-migrate

HTMLに対する単一の正規表現（wp-content|wp-includes|WordPress）で、高い確度でサイトを特定できる。一部のボットはホームページをスキップし、/wp-login.phpや/xmlrpc.phpに直接アクセスする。どちらかが200を返せば、WordPressだ。

2. REST APIの列挙

WordPressはバージョン4.7（2016年12月）以降、デフォルトでWP REST APIが有効になっている。ルートエンドポイントは常に同じ場所にある。

GET /wp-json/ HTTP/1.1

この1つのリクエストで、サイトが公開している登録済みルートの一覧を記述したJSONドキュメントが返される。攻撃者にとって、サイト構成を把握するための効率的な手がかりとなる。

ボットが抽出する情報：

ユーザー列挙: GET /wp-json/wp/v2/usersは、多くの環境でユーザー名のリストを認証なしで返す。攻撃者はこれを使って、ブルートフォースログインのための有効なユーザー名を取得する。
コンテンツエンドポイント: /wp-json/wp/v2/posts、/pages、/commentsは一般公開されている。ボットはこれらを使ってスパムコメントを注入したり、入力ポイントを特定したりする。
プラグインが登録したルート: Contact Form 7のようなプラグインは独自のRESTルート（例：/wp-json/contact-form-7/v1/contact-forms/）を登録する。これにより、どのプラグインがインストールされているかが攻撃者に伝わる。
WordPressのバージョン: APIレスポンスにはバージョン情報が含まれ、バージョン固有のエクスプロイト選択に利用される。

{
  "name": "Example Site",
  "namespaces": [
    "wp/v2",
    "contact-form-7/v1",
    "wc/v3"
  ],
  "authentication": [],
  "routes": { ... }
}

namespaces配列はプラグインのインベントリとして機能する。contact-form-7/v1はCF7の存在を、wc/v3はWooCommerceの存在を確認させる。

3. ユーザー列挙の悪用

これは実環境で最も頻繁に悪用されるWordPressの攻撃パターンの1つだ。

多くのデフォルト環境では、非認証のGETリクエストでユーザーデータが公開される。

GET /wp-json/wp/v2/users

レスポンス：

[
  {
    "id": 1,
    "name": "admin",
    "slug": "admin",
    "link": "https://example.com/author/admin/"
  }
]

このエンドポイントを無効にしていても、古い列挙方法が機能するケースは多い。

GET /?author=1

これは/author/admin/にリダイレクトされ、ユーザー名が漏洩する。ボットは?author=1、?author=2、?author=3と反復して完全なユーザーリストを取得し、wp-login.phpへのブルートフォース攻撃に利用する。

4. XML-RPCによるブルートフォース増幅攻撃

REST APIが注目を集める一方で、XML-RPC（/xmlrpc.php）は依然として攻撃ベクトルとして機能している。WordPress 3.5以降でデフォルト有効だ。

system.multicallメソッドは特に危険で、攻撃者が数百〜数千回のログイン試行を単一のHTTPリクエストにまとめることができる。リクエスト数（認証試行数ではなく）をカウントするレート制限を実質的に無効化する。

<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value>
        <array>
          <data>

          </data>
        </array>
      </value>
    </param>
  </params>
</methodCall>

1つのリクエストに数百〜数千回のパスワード推測。ほとんどの基本的なレート制限はこれを単一のリクエストと見なし、通過させてしまう。ただし、WAF（Web Application Firewall）やFail2Banを適切に設定している環境では、この攻撃はブロックされるケースも増えている。

5. 予測可能なフォーム構造（CF7スパム対策の起点）

WordPress上のコンタクトフォームは認識可能なパターンに従う。1,000万以上のアクティブインストールを持つ最も人気のあるフォームプラグイン、Contact Form 7を例に取る。

CF7のフォームは予測可能なマークアップでレンダリングされる。

<form class="wpcf7-form" action="/wp-json/contact-form-7/v1/contact-forms/123/feedback" method="post">
  <input type="text" name="your-name" class="wpcf7-form-control" />
  <input type="email" name="your-email" class="wpcf7-form-control" />
  <textarea name="your-message" class="wpcf7-form-control"></textarea>
  <input type="submit" value="Send" class="wpcf7-submit" />
</form>

クラス名は文書化されており、エンドポイントのパターンは既知。デフォルトのフィールド名（your-name、your-email、your-message）は、多くのサイトでそのまま使用されている。

ボットは個別のフォームを解析する必要がない。/wp-json/contact-form-7/v1/contact-forms/{id}/feedbackに標準のフィールド名でポストし、フォームIDを反復するだけだ。同一のスクリプトで短時間に多数のサイトへスパムを送信できる。

6. wp-cronの攻撃対象領域

WordPressはシステムレベルのcronジョブを独自の疑似cronであるwp-cron.phpで代替している。すべてのページ読み込みがスケジュールされたタスクのチェックをトリガーし、このエンドポイントは公開アクセス可能だ。

GET /wp-cron.php

DoSのベクトルとして悪用されることがある。主要な攻撃ベクトルではないが、無効化してシステムcronに置き換えることでパフォーマンスの安定化にもつながるため、対策コストに対してメリットが大きい。

攻撃ベクトルの優先順位：2026年に最も危険なのはどれか

上記で解説した攻撃ベクトルは、すべてが同じ危険度ではない。2026年の実環境における優先順位を整理する。

優先度	攻撃ベクトル	理由
最優先	フォームスパム（CF7等）	ヘッドレスブラウザ＋AI記入の普及により、従来のフィルタリングでは防ぎきれなくなっている。ビジネスへの直接的な実害（スパム処理コスト、正規リードの埋没）が最も大きい。
最優先	REST API経由のユーザー列挙	ブルートフォース攻撃の起点。デフォルト設定で公開されている環境が多く、対策も容易なため、未対策の場合は即対応すべき。
高	XML-RPCブルートフォース増幅	依然として有効だが、WAF・Fail2Banの普及により防御されている環境も増加。使用していなければ無効化一択。
中	バージョン情報のフィンガープリント	自動スキャンのコストを上げるが、執拗な攻撃者には効果が限定的。
低	wp-cronの公開アクセス	補助的なDoSベクトル。対策コストが低いので実施推奨だが、優先度は最後でよい。

状況は悪化している

3つのトレンドが問題を複合的に悪化させている。

ヘッドレスブラウザの普及。 PuppeteerやPlaywrightなどのツールが完全なChromiumインスタンスを起動し、JavaScriptを実行し、基本的なボット検知をパスする。ネットワークレベルでは実際のユーザーとの区別がつかない。

AIを活用したフォーム記入。 大規模言語モデルが文脈に合ったフォーム回答を生成できるようになった。従来の明らかなスパム文面ではなく、本物の問い合わせのように読めるメッセージが送信されるため、コンテンツベースのフィルタリングだけでは対処しきれなくなっている。

攻撃ツールのコモディティ化。 WordPress専用のスキャンツールが誰でも利用可能で、ユーザー、プラグイン、脆弱性の列挙が容易になっている。参入障壁が消失した。

WordPressセキュリティ対策：実践チェックリスト

単一の修正策で解決する問題ではない。以下のチェックリストに沿って、多層的に対策を講じることが重要だ。

① REST API無効化・アクセス制限

機密性の高いエンドポイントへの非認証アクセスを制限する。

判断基準：

全閉じしてよいケース：通常のブログ・コーポレートサイトで、外部からREST APIを利用する機能がない場合。管理画面（ログイン済みユーザー）からのアクセスは引き続き動作する。
選択的に開放するケース：ヘッドレスCMSとして使用している、外部アプリからコンテンツを取得している、WooCommerceのストアフロントAPIを使用している場合。必要なルートだけをホワイトリストに登録する。
絶対に閉じるべきエンドポイント：/wp-json/wp/v2/users（ユーザー列挙）。これを公開したままにする正当な理由はほぼない。

テーマのfunctions.phpまたはカスタムプラグインに以下を追加：

add_filter('rest_authentication_errors', function ($result) {
    if (true === $result || is_wp_error($result)) {
        return $result;
    }

    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            __('You are not currently logged in.'),
            array('status' => 401)
        );
    }

    return $result;
});

② XML-RPC無効化

外部パブリッシングツールやWordPressモバイルアプリを使用していないなら、XML-RPCを完全に無効にする。

add_filter('xmlrpc_enabled', '__return_false');

サーバーレベルでのブロックがより効果的だ。Nginxの場合：

location = /xmlrpc.php {
    deny all;
    return 403;
}

③ バージョン情報の削除

ジェネレーターメタタグとバージョンクエリ文字列を除去する。

remove_action('wp_head', 'wp_generator');

add_filter('style_loader_src', function ($src) {
    return remove_query_arg('ver', $src);
}, 10, 1);

add_filter('script_loader_src', function ($src) {
    return remove_query_arg('ver', $src);
}, 10, 1);

これ単体で執拗な攻撃者は止まらないが、自動フィンガープリンティングのコストを引き上げる。

④ ユーザー列挙の無効化

著者アーカイブの列挙をブロックする。

if (!is_admin() && isset($_REQUEST['author'])) {
    wp_redirect(home_url(), 301);
    exit;
}

REST APIのユーザーエンドポイントについては、上記①で制限するか、選択的に無効にする専用プラグインを使用する。

⑤ フォームスパム対策

コアインフラの堅牢化はしていても、コンタクトフォームがデフォルトのフィールド名のまま、行動検証なしで放置されているケースは多い。フォームの保護手段の選定は、次のセクションの比較表を参考にしてほしい。

⑥ wp-cronの公開アクセス無効化

WordPressの疑似cronを実際のシステムcronジョブに置き換える。

wp-config.phpに以下を追加：

define('DISABLE_WP_CRON', true);

その後、システムのcronエントリを追加：

*/15 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

フォームスパム対策の比較：用途別の推奨構成

フォーム保護の選択肢を正しく比較することが、CF7スパム対策の第一歩だ。

	reCAPTCHA v3	Cloudflare Turnstile	hCaptcha	多層型ハニーポット
ユーザーへの摩擦	なし（バックグラウンド）	ほぼなし	あり（パズル表示）	なし（完全不可視）
単純ボットへの有効性	高い	高い	高い	高い
高度なボットへの有効性	中程度（スコア操作可能）	中程度	中程度	限定的（単体の場合）
ページパフォーマンス影響	大きい	軽微	中程度	なし
外部サービス依存	Google	Cloudflare	hCaptcha	なし
GDPR対応	グレーゾーン	対応	対応	問題なし
導入コスト	無料	無料プランあり	無料プランあり	プラグインにより異なる
CF7実装例	公式インテグレーション	Simple Cloudflare Turnstile等	hCaptcha for WP	Samurai Honeypot for Forms

用途別の推奨パターン

用途	推奨	理由
LP・問い合わせフォーム	多層型ハニーポット	コンバージョン率への影響がゼロ。パフォーマンスペナルティもなし。外部依存がないためGDPRリスクも回避。
会員登録・ログイン	Cloudflare Turnstile	摩擦が最小限でありながら、ブルートフォース攻撃への抑止力を提供。無料プランで十分。
管理画面・決済	Turnstile + 2FA	高リスクページは多要素認証との併用が前提。CAPTCHAやTurnstileは補助レイヤーとして機能。
EU向けサービス	ハニーポット or Turnstile	reCAPTCHAはGDPRグレーゾーン。外部サービスへのデータ送信がないハニーポットが最もリスクが低い。

単一の手法に依存するよりも、用途に応じた使い分けと多層防御が効果的だ。CAPTCHAは単体で十分な防御とは言えなくなってきているが、他の手法と組み合わせることで依然として有効なレイヤーになりうる。

現実的なセキュリティ態勢

WordPressは本質的にセキュアでないわけではない。本質的に予測可能なのだ。この区別は重要だ。

WordPressが既知のディレクトリ構造、標準的なAPIエンドポイント、文書化された規約を使用しているという事実は変えられない。それらはWordPressを強力で開発しやすいものにしている要素でもある。

変えられるのは、その予測可能性のうち、非認証の訪問者や自動スクリプトにどれだけ公開されているかだ。上記のすべての堅牢化ステップは、ボットが利用できる情報を減らし、自動攻撃のコストを引き上げ、攻撃者にサイトごとの個別努力を強いるものだ。

侵害されるサイトは、ほとんどの場合、エンドポイントがロックダウンされた最新環境ではない。すべてがデフォルト設定のまま運用されているサイトだ。なぜなら、そもそもどこに攻撃対象があるかを誰も教えていなかったからだ。

攻撃対象の場所はわかった。対策を実行しよう。

よくある質問（FAQ）

WordPressのREST APIは無効にすべきですか？

完全に無効にする必要があるかはサイトの構成による。通常のブログ・コーポレートサイトであれば、非認証アクセスを全体的に制限しても問題ないケースが多い。ヘッドレスCMSやWooCommerceを使用している場合は、必要なルートだけをホワイトリストに登録する構成が推奨される。ただし、/wp-json/wp/v2/usersは例外なく制限すべきだ。

XML-RPCを無効にしても問題ありませんか？

外部パブリッシングツール（Windows Live Writer等）やWordPress公式モバイルアプリを使用していなければ、無効にしても影響はない。Jetpackプラグインを使用している場合はXML-RPCに依存するため、事前に確認が必要だ。

CAPTCHAとハニーポット、どちらを使うべきですか？

排他的な選択ではない。高リスクページ（ログイン、決済）にはTurnstileや2FA、一般的なお問い合わせフォームにはハニーポット＋時間分析という使い分けが実務的だ。上記の「用途別の推奨パターン」を参考にしてほしい。

Contact Form 7のスパム対策として最低限やるべきことは？

まず、デフォルトのフィールド名（your-name、your-email等）を変更すること。次に、何らかのボット検出手段（ハニーポット、Turnstile等）を導入すること。REST APIでCF7のルートが公開されている場合は、必要に応じてアクセスを制限する。

wp-cronは本当に攻撃に使われますか？

主要な攻撃ベクトルではないが、DoS攻撃の補助的な手段として悪用されるケースはある。無効化してシステムcronに置き換えることで、パフォーマンスの安定化にもつながるため、対策コストに対してメリットが大きい。

参考文献

Wordfence: WordPress Attack Statistics（2026年） https://www.wordfence.com/
W3Techs: WordPress Market Share（2026年3月） https://w3techs.com/technologies/details/cm-wordpress
Sucuri: Brute Force Amplification Attacks Against WordPress XMLRPC（2015年） https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
WordPress.org: Contact Form 7 Plugin https://wordpress.org/plugins/contact-form-7/
WordPress.org: WordPress 4.7 “Vaughan”（2016年12月） https://wordpress.org/news/2016/12/vaughan/
WP Engineer: XML-RPC Enabled by Default in WordPress 3.5 https://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/
Patchstack: State of WordPress Security in 2026 https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/

Contact Form 7のセキュリティ対策をさらに深く知りたい方は、開発者レベルのカスタマイズ技術を解説したContact Form 7をハックする：wpcf7_skip_mailフックの活用ガイドをご覧ください。

← すべてのコラム