WordPressのバグバウンティ対応方法：脆弱性の報告や報奨金の要求が届いたときの判断と返信

WordPressサイトにバグバウンティ（脆弱性の報告と報奨金の要求）が届いたら、支払いや返事の約束をする前に、報告内容をステージング環境で検証し、実際の影響で対応を決めます。報奨金制度を公開していないサイトに届くメールの多くは、WordPressの仕様や軽微な設定の指摘で、支払う義務はありません。一方で、本物の脆弱性が含まれていることもあるため、内容を見ずに無視するのも危険です。この記事では、届いたときの最初の確認、WordPressでよく届く指摘ごとの判断と修正方法、返信の書き方、プラグイン開発者が報告を受けたときの進め方を解説します。

バグバウンティの報告が届く3つのパターン

バグバウンティは、脆弱性を見つけて報告した人に報奨金を支払う制度です。WordPressの運用者や開発者のところに来る連絡は、おおむね次の3つに分かれます。

• 報奨金制度を公開していないのに「脆弱性を見つけた。報奨金はいくらか」と連絡が来る。いわゆる「ベグバウンティ（beg bounty）」と呼ばれるもので、自動スキャンの結果をそのまま送っている例が多く見られます。
• 自社が HackerOne や Bugcrowd などのプラットフォームで運営している制度に報告が来る。この場合は、公開している規約と報奨金の基準に沿って対応します。
• プラグインやテーマの開発者に、Wordfence・Patchstack・WPScan などから脆弱性の連絡が来る。これらの事業者は研究者向けの報奨金制度や報告窓口を持っており、研究者からの報告を確認したうえで開発者に連絡します。

どのパターンでも、最初にやることは「内容が本物か、影響はどの程度か」を確かめることです。

届いたメールで最初に確認すること

まず、メール自体の安全を確認します。

• 添付ファイルやリンク先の「検証用スクリプト」を、業務用のパソコンや本番サーバーで開かない。マルウェアの配布に使われることがあります。
• 具体的なURL、再現手順、想定される影響が書かれているか。「重大な脆弱性があるので先に報奨金の額を提示してほしい」とだけ書かれたものは、内容が伴っていないことがほとんどです。
• 期限を区切って支払いを求めたり、支払わなければ公開すると書いたりしている場合は、報告ではなく恐喝の可能性があります。支払わずに記録を残し、社内の責任者や必要に応じて警察・弁護士に相談します。

内容が具体的な場合は、ステージング環境で再現を試みます。本番環境で試すと、データの破損や他の利用者への影響が出るおそれがあります。

対応の記録として、受信日時、送信者、指摘の内容、判断、返信内容を残しておきます。同じ指摘が別の人から届くことも多いため、記録があると判断が速くなります。

WordPressでよく届く指摘と判断の目安

よく届く指摘と、それぞれの実態・対応の目安をまとめます。

ユーザー名の列挙

/wp-json/wp/v2/users や /?author=1 からユーザー名が分かる、という指摘は特に多く届きます。WordPressでは、公開済みの投稿があるユーザーの情報は投稿者アーカイブなどで公開される仕様です。ユーザー名が分かっても、パスワードが推測されにくく、二要素認証が設定されていればログインはできません。

それでも REST API からの一覧取得を止めたい場合は、ログインしていない訪問者に対してユーザーのエンドポイントを外します。

// 子テーマの functions.php か mu-plugins に追加
add_filter( 'rest_endpoints', function ( $endpoints ) {
	if ( ! is_user_logged_in() ) {
		unset( $endpoints['/wp/v2/users'] );
		unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
	}
	return $endpoints;
} );

ユーザー情報を REST API から読む外部サービスやプラグインがあると動かなくなるため、ステージング環境で確認してから反映します。設定後、ログアウトした状態で /wp-json/wp/v2/users を開き、rest_no_route のエラーが返れば制限できています。

xmlrpc.php が有効

XML-RPC は、外部のアプリやサービスから投稿するための古い仕組みです。1回のリクエストで多数のログインを試せるため、パスワード総当たりに使われることがあります。Jetpack や一部のスマートフォンアプリなど、XML-RPCを使う連携がなければ、Webサーバーでアクセスを拒否します。

# Nginx
location = /xmlrpc.php {
    deny all;
}

# Apache（.htaccess）
<Files xmlrpc.php>
    Require all denied
</Files>

設定ファイルを変更する前にバックアップを取り、反映後に https://example.com/xmlrpc.php が 403 になることを確かめます。

バージョン番号やセキュリティヘッダー

readme.html や HTML の generator タグからバージョンが分かる、という指摘は情報の露出にとどまります。古いバージョンを使っていること自体が問題なので、本体とプラグインを更新するのが本来の対策です。

クリックジャッキング対策のヘッダーがない、HSTS がない、といった指摘も影響は大きくありませんが、Webサーバーの設定で比較的簡単に追加できます。なお、WordPressはログイン画面と管理画面には、ほかのサイトの iframe に埋め込まれないようにするヘッダーを標準で送っています。

本物の脆弱性だった場合

XSS、SQLインジェクション、権限確認の不備、既知の脆弱性がある古いプラグインの使用などが再現できた場合は、すぐに対応します。原因が独自コードなら修正し、プラグインが原因なら更新するか、修正版が無ければ一時的に停止します。すでに悪用された形跡がないかをアクセスログで確認し、形跡があれば侵害への対応に切り替えます。

返信の書き方

報奨金制度を公開していない場合でも、正当な指摘をくれた人には、修正したことと感謝を伝えるのが望ましい対応です。支払うかどうかは、事前に社内で方針を決めておき、その方針に沿って返信します。

【有効な指摘だった場合】
ご報告ありがとうございます。ご指摘の内容を確認し、〇月〇日に修正しました。
当サイトでは報奨金制度を設けていないため、金銭でのお礼はお支払いしておりません。
ご希望であれば、謝辞ページにお名前を掲載いたします。

【仕様や対象外の指摘だった場合】
ご連絡ありがとうございます。ご指摘の動作は WordPress の仕様によるもので、
現時点で利用者への影響は確認できなかったため、対応の対象外と判断しました。
具体的な悪用手順や影響がございましたら、あらためてお知らせください。

支払いを決める前に検証を終えること、口止めの対価としては支払わないことが基本です。金額の交渉に応じる前提で返信すると、同じ指摘が繰り返し届く原因にもなります。窓口と方針をあらかじめ公開しておくと、こうしたやり取りを減らせます。

プラグイン・テーマの開発者が報告を受けた場合

自作のプラグインやテーマについて、Wordfence や Patchstack などから脆弱性の連絡が来た場合は、次の流れで進めます。

1. 報告を受け取ったことを返信し、修正の見込みを伝えます。
2. ローカルやステージング環境で再現し、同じ書き方をしている箇所がほかにないかも探します。nonce、current_user_can() による権限確認、サニタイズとエスケープの漏れが原因になっていることが多いです。
3. 修正版をリリースし、変更履歴にセキュリティ修正であることを書きます。利用者が更新の必要性を判断できるようにするためです。
4. 公開の時期を連絡元と調整します。脆弱性情報は、修正版の公開後にデータベースへ掲載されるのが一般的です。

WordPress.org で配布しているプラグインは、修正されないまま放置されると、プラグインチームによって配布が停止されることがあります。連絡が来たら早めに返事をし、修正に時間がかかる場合もその旨を伝えておきます。

自社で報奨金制度を始める場合

報奨金を支払う制度を始めたい場合は、先に脆弱性開示ポリシー（VDP）と受付・修正の体制を整えます。報告を受けても修正できる人がいなければ、報奨金を払っても安全にはなりません。

制度を始めるときは、対象範囲、対象外の指摘、深刻度ごとの報奨金の基準、年間の予算を決めます。HackerOne や Bugcrowd などのプラットフォームを使うと、報告の受付や報告者とのやり取り、支払いの手続きを任せられます。手数料や契約条件はプラットフォームと契約内容によって異なるため（2026年10月現在）、見積もりを取って比較してください。最初は招待した研究者だけに公開する非公開の制度から始めると、報告の量を調整しやすくなります。

まとめ

• バグバウンティの報告が届いたら、支払いの約束をせず、ステージング環境で再現して影響を確かめます。添付ファイルは本番や業務用のパソコンで開きません。
• ユーザー名の列挙、xmlrpc.php、バージョン表示、セキュリティヘッダーの指摘は、WordPressの仕様や軽微な設定であることが多く、必要に応じて低コストの対策を入れます。
• XSS・SQLインジェクション・権限の不備などの本物の脆弱性は、優先して修正し、悪用の形跡も確認します。
• 報奨金の方針は事前に決め、正当な指摘には修正内容と感謝を伝えます。脅しを伴う要求には支払わず、記録を残して相談します。
• 開発者は、再現・修正・変更履歴への記載・公開時期の調整の順に進め、自社で制度を始める場合は先にVDPと修正体制を整えます。

• WordPressサイトの脆弱性開示ポリシー（VDP）の設定方法
• WordPressのHTTPセキュリティヘッダーを強化する方法