2026年7月3日
2026年7月3日
WordPressプラグインの脆弱性をWPScanとNVDで追跡する方法
WordPressのプラグイン脆弱性を追うなら、まず「自分のサイトに何が何バージョンで入っているか」を一覧にし、それをWPScanの脆弱性データベースと照合するのが近道です。NVDは公式なCVE情報の確認先として補助的に使います。この記事では、WPScanのCLIとAPIの使い方、WP-CLIと組み合わせた定期チェックの仕組み、NVDの読み方、見つかった脆弱性への対応順までを説明します。
WPScanとNVDの役割の違い
WPScan はWordPress本体・プラグイン・テーマに特化した脆弱性データベースと、外部からサイトを診断するCLIツールです。プラグインのスラッグ(contact-form-7 のようなディレクトリ名)単位で「どのバージョンで修正されたか」が整理されているため、WordPressの運用ではもっとも扱いやすい情報源です。
NVD(米国国立標準技術研究所が運営する National Vulnerability Database)は、CVE番号ごとの公式な記録と深刻度(CVSS)を確認する場所です。ただしWordPressプラグインは製品の識別情報(CPE)の付与が遅れたり揺れたりしやすく、「スラッグとバージョンで機械的に照合する」用途には向きません。NVD側の分析待ちが長引いた時期もあったため、NVDだけに頼ると検知が遅れることがあります。
実際には、WordPressプラグインのCVEの多くはWordfence、Patchstack、WPScanといった、CVEを採番できる組織(CNA)が発行しています。日々の追跡はWPScanなどWordPress特化のデータベースで行い、深刻度や詳細の裏付けにNVDを見る、という分担が現実的です。
準備:APIトークンの取得と保管
WPScanのデータベースを使うには、wpscan.com でアカウントを作成してAPIトークンを発行します。無料枠には1日あたりのリクエスト数の上限があります(2026年10月現在)。その数や有料プランの内容は変わることがあるため、利用前に公式サイトで確認してください。
トークンは秘密情報として扱います。スクリプトに直書きせず、環境変数から読み込むようにすると、Gitに誤って含めてしまう事故を防げます。
# ~/.bashrc など、Webから見えない場所に設定する
export WPSCAN_API_TOKEN="your-api-token"
WPScan CLIで外部から診断する
WPScan CLIはRubyのgemかDockerイメージで導入できます。診断してよいのは自分が管理する、または許可を得たサイトだけです。他人のサイトへのスキャンは不正アクセスを疑われる行為になり得ます。
# gem で導入する場合
gem install wpscan
# Docker で実行する場合
docker run -it --rm wpscanteam/wpscan --url https://example.com --api-token "$WPSCAN_API_TOKEN"
# 脆弱性のあるプラグインとテーマを列挙する
wpscan --url https://example.com --api-token "$WPSCAN_API_TOKEN" \
--enumerate vp,vt --plugins-detection mixed
--enumerate vp は脆弱性が報告されているプラグイン、vt は同じくテーマを対象にします。--plugins-detection は既定の passive(ページのHTMLから推測)だと見落としが出やすく、mixed や aggressive にすると精度が上がる代わりにリクエスト数が増えます。WAFやセキュリティプラグインがスキャンを遮断して結果が空になることもあるため、「何も出なかった=安全」とは読まないでください。
外部診断は、攻撃者から見えている情報を把握するのに役立つ一方、管理画面で無効化しているプラグインや、外から痕跡が見えないプラグインは検出できません。自分のサイトの追跡には、次の内部照合が向いています。
WP-CLIで一覧を作りAPIと照合する
サーバーにSSHで入れるなら、WP-CLIで導入済みプラグインの正確な一覧を取り、WPScan APIに1件ずつ問い合わせる方法がもっとも漏れが少なくなります。以下のスクリプトは、導入バージョンが修正バージョンより古いもの、または修正版が出ていないものだけを表示します。jq が必要です。
#!/usr/bin/env bash
# 導入済みプラグインを WPScan API v3 と照合する
set -uo pipefail
TOKEN="${WPSCAN_API_TOKEN:?WPSCAN_API_TOKEN を設定してください}"
WP_PATH="/var/www/example.com/public_html"
wp plugin list --path="$WP_PATH" --fields=name,version --format=csv | tail -n +2 |
while IFS=, read -r slug ver; do
json=$(curl -s -H "Authorization: Token token=${TOKEN}" \
"https://wpscan.com/api/v3/plugins/${slug}")
echo "$json" | jq -r --arg s "$slug" \
'.[$s].vulnerabilities[]? | [.title, (.fixed_in // "none")] | @tsv' 2>/dev/null |
while IFS=$'\t' read -r title fixed; do
if [ "$fixed" = "none" ]; then
echo "[修正版なし] ${slug} ${ver}: ${title}"
elif [ "$(printf '%s\n%s\n' "$ver" "$fixed" | sort -V | head -n1)" != "$fixed" ]; then
echo "[要更新] ${slug} ${ver} -> ${fixed}: ${title}"
fi
done
sleep 1
done
ポイントは3つあります。
- 1プラグイン1リクエストを消費します。 プラグイン数が多いと無料枠を早く使い切るため、実行は週1回や更新作業の前など、間隔を空けて行います。
- **バージョン比較は
sort -Vに頼っています。**1.2.3-betaのような表記では誤判定することがあるので、出力は「確認の候補」として扱い、最終判断は詳細ページで行います。 - レスポンスの項目名は変わる可能性があります。
fixed_inなどのキー名は公式のAPIドキュメントで確認してから運用してください。
テーマは wp theme list と /api/v3/themes/{スラッグ}、本体は /api/v3/wordpresses/{ドットを除いたバージョン} で同様に照合できます。cronで定期実行し、出力があった場合だけメールやチャットに通知する形にすると、見落としを減らせます。
NVDでCVEの詳細を確かめる
WPScanの結果にCVE番号が付いていれば、NVDの検索画面やAPIで深刻度と影響範囲を確認できます。
# CVE番号を指定して1件取得する(APIキーなしでも利用できるが、制限が厳しい)
CVE_ID="CVE-YYYY-NNNNN" # 調べたいCVE番号に置き換える
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=${CVE_ID}" | jq '.vulnerabilities[0].cve.descriptions'
CVSSの数値だけで優先度を決めないことが大切です。たとえば「管理者権限が必要なXSS」は数値が中程度でも、投稿者アカウントを多く発行しているサイトでは影響が大きくなります。「誰が(未ログイン/購読者/管理者)」「何をできるか」を説明文から読み取り、自サイトの使い方に当てはめて判断します。
見つかったときの対応順
- 修正版がある場合:まずバックアップを取り、ステージング環境で更新して表示と主要機能を確認してから本番に反映します。未ログインで悪用できる種類なら、確認を短縮してでも早めに更新する判断もあります。
- 修正版がない場合:プラグインを無効化できるか検討します。代替プラグインへの移行、該当機能だけの停止、WAFでの該当リクエストの遮断(仮想パッチ)も選択肢です。
- 長く更新されていないプラグイン:WordPress.orgで公開停止になったものや、作者が更新をやめたものは、脆弱性が報告されても修正されない可能性があります。脆弱性の有無にかかわらず、置き換えを計画しておくと安心です。
WPScan以外にも、Patchstack や Wordfence Intelligence が脆弱性データベースや通知の仕組みを公開しています。また Jetpack Protect はWPScanのデータを使っているとされています。無料で使える範囲や提供形態は変わるため、導入時に各サービスの公式情報を確認してください。
まとめ
- 日々の追跡はWordPress特化のWPScanデータベースで行い、NVDはCVEの詳細と深刻度の確認に使う。
- 外部スキャン(WPScan CLI)は見え方の確認、WP-CLIの一覧とAPIの照合は漏れのない内部チェックとして使い分ける。
- APIトークンは環境変数で扱い、無料枠の上限を意識して実行間隔を決める。
- 対応は「バックアップ→ステージングで更新確認→本番反映」。修正版がなければ無効化・置き換え・WAFで守る。