「プラグインはちゃんと更新している。だから大丈夫」

この状態でも、実務では事故が起きます。理由はシンプルで、脆弱性対応は「更新したかどうか」だけではなく、どの情報源を見て、どの優先度で、どのタイミングで処理したかで結果が変わるからです。

WordPressの脆弱性は、発見から悪用までのリードタイムが短くなる傾向にあります。特にB2Bサイトでは、問い合わせフォーム、会員管理、SEO、バックアップなど、業務に直結するプラグインが多く、1つの脆弱性が「情報漏えい」「改ざん」「停止」につながりやすい構造です。

本記事では、2026年4月時点の公開情報をベースに、Web担当者・エンジニア寄りの中級者が明日から実行できるよう、次の順で整理します。

  • どの情報源をどう使い分けるか（WPScan / JVN / WordPress公式 / Patchstack / Wordfence）
  • 導入前と運用中で何をチェックするか
  • CVE番号とCVSS v3（Base / Temporal / Environmental）をどう判断に落とすか
  • 自動化できる部分と、手作業で見るべき部分

先に全体像：脆弱性検知の情報源マップ

まずは「どこを見れば何が分かるか」を1枚で押さえます。

情報源 主な強み 無料/有料 実務での使い方
WPScan Vulnerability Database WordPress特化の脆弱性DB、CLI/API連携がしやすい 非商用は無料枠あり、商用APIは有料（Enterprise等） 日次スキャンとCI連携の中核
JVN / JVN iPedia 日本語での整理、国内実務で説明しやすい 無料 稟議・社内説明・日本語一次確認
WordPress公式（Plugin Handbook / Plugins Team） クローズ理由・報告導線・運用ルールが分かる 無料 「閉鎖プラグイン」をどう扱うかの判断基準
Patchstack 脆弱性DB + vPatching/防御寄りの設計 無料プランあり・保護機能は有料 「今すぐ更新できない」期間のリスク緩和
Wordfence Intelligence / Scanner 脆弱性DB・Webhook・運用実績、CLIやプラグイン選択肢 DB/APIは無料利用可能、製品機能は無料/有料混在 監視・通知・検知オペレーション

結論だけ先に言うと、単一ソース依存は危険です。
最低でも「WPScan系 + WordPress公式 + JVN（日本語確認）」の3系統は並行監視にしておくのが実務的です。

なぜ今、プラグイン脆弱性の「見抜く力」が必要か

攻撃者は「古いWordPress」だけを狙っていません。現在は、プラグインの脆弱性情報が公開された直後に、対象サイトを機械的に探索する動きが一般化しています。

加えて、現場では次のような事情で対応が遅れます。

  • 検証環境がなく、更新をすぐ本番適用できない
  • 依存プラグインが多く、互換性確認に時間がかかる
  • 情報源ごとに表記が違い、深刻度判断がぶれる

このため、必要なのは「脆弱性ゼロ」ではなく、検知の速さと、判断の一貫性です。

情報源の使い分け（前半）

1) WPScan：運用の中核にしやすい理由

WPScanは、WordPressコア・プラグイン・テーマの脆弱性情報を扱う特化型DBと、wpscan CLIを持つのが強みです。2026年4月時点で公式サイト上でも、Researcher向け無料枠（API 25 calls/day）とEnterprise中心の商用利用導線が明示されています。

無料版と有料版（API）の違い

  • 無料（Researcher枠）
  • 非商用前提でAPI利用可能
  • 1日25 APIコール上限（目安）
  • CLI自体はAPIなしでも実行可能（ただし脆弱性データ連携は限定）
  • 有料（Enterprise等）
  • 商用利用向け
  • 最新エンドポイント、Webhook、詳細データ（PoCやCVSS項目など）を含む構成

実務ポイントは、1回のスキャンで必要なAPIコール数です。WPScan公式説明どおり、概ね「WordPress本体1 + プラグイン数 + テーマ数」の請求イメージになります。サイト数が増えると無料枠では足りなくなります。

CLIの基本例（wpscan）

インストール例（macOS / Homebrew）:

brew install wpscanteam/tap/wpscan

基本スキャン:

wpscan --url https://example.com

脆弱性データをAPI連携して確認:

wpscan --url https://example.com --api-token YOUR_WPSCAN_TOKEN

脆弱性のあるプラグイン列挙を明示:

wpscan --url https://example.com -e vp --plugins-detection mixed --api-token YOUR_WPSCAN_TOKEN

環境変数でトークンを読む運用も可能です（WPSCAN_API_TOKEN）。

API連携の実務例（curl）

プラグインslugで脆弱性情報を取得:

curl -H "Authorization: Token token=YOUR_WPSCAN_TOKEN" \
  https://wpscan.com/api/v3/plugins/contact-form-7

この結果を、サイト内のインストールプラグイン一覧と突き合わせれば、夜間バッチの自動監視が組めます。

2) JVN / JVN iPedia：日本語情報源としての価値

JVNは注意喚起の速報性、JVN iPediaは広範な脆弱性DB検索性が強みです。特に日本企業の現場では、英語ソースだけだと非エンジニア層への説明が詰まりやすいため、JVN系の日本語整理は意思決定を早めます。

探し方（WordPress関連）

  • JVNで「WordPress用プラグイン」をキーワード検索
  • JVN iPediaでキーワード + ベンダ/製品 + CVSS帯で絞り込み
  • 重要案件はCVE番号で逆引きして原典（NVD/ベンダ）も確認

JVN iPediaのヘルプには、CVSS表示の読み方や公開日/更新日の意味が明示されており、監視運用の基準化に使えます。

実務で効くポイント

  • 社内報告書にそのまま使える日本語粒度
  • 「なぜ急ぐのか」を非技術部門に説明しやすい
  • 日本語の製品名表記で検索できる

注意点として、JVN iPedia側は「収集・整理の都合で反映まで時間差が出る」旨が案内されています。速報は海外ソース、確定運用はJVNで補強という使い分けが現実的です。

3) WordPress公式情報：Plugin Securityと閉鎖プラグインの解釈

WordPress公式のPlugin Handbookには、セキュリティ報告フローが明示されています。ポイントは以下です。

  • 脆弱性報告先は plugins@wordpress.org
  • 公開前の過度な拡散を避ける方針
  • 多くのケースで「修正まで新規ダウンロード停止（close）」運用

加えて Alerts and Warnings / Plugin Developer FAQ には、閉鎖プラグイン表示の意味が整理されています。

  • クローズ表示は「Author request / Guideline violation / Licensing / Security issue」等の区分
  • 閉鎖後60日で大分類の理由が公開されるケースがある
  • 詳細理由は原則非公開

つまり、This plugin has been closed... を見たら、「即アンインストール」ではなく「リスク評価を即開始」が正しい反応です。

4) Patchstack / Wordfence Intelligence：補完情報としての強み

Patchstack

  • オープンな脆弱性DBを公開
  • 無料プランあり（検知中心）
  • 有料で保護機能（vPatching / RapidMitigate）を強化
  • API連携やホスト向け機能が豊富

「更新パッチは出ているが、今夜は本番反映できない」場面で、緩和策を持てる点が強みです。

Wordfence Intelligence

  • 脆弱性DBをAPI/Webhookで提供
  • 2026年3月9日以降、V3 APIは無料のままAPIキー認証が必須化
  • プラグイン版Wordfence利用者への影響とは別軸（Intelligence API側の変更）

運用観点では「無料で取り込みやすいが、仕様変更時の追従を必ず自動テストする」が重要です。

CVE番号とCVSS v3を実務判断に落とす

CVE番号の読み方

CVE-2026-12345 は「年 + 連番（4桁以上）」です。連番は可変長で、件数増に合わせて桁が増える仕様です。

CVSS v3（Base / Temporal / Environmental）の使い分け

FIRSTのCVSS v3.1仕様では、次の3層でスコアを扱います。

  • Base: 脆弱性そのものの本質的深刻度
  • Temporal: exploit公開状況や修正公開状況など時間変化
  • Environmental: 自社環境（公開範囲、権限設計、防御策）を反映

実務ではBaseだけ見て終わりがちですが、B2BサイトではEnvironmentalの重みが大きいです。たとえば同じCVSS 6.xでも、管理画面露出・権限設計・WAF有無で優先度は変わります。

どのスコアなら即対応か（運用目安）

CVSS v3.1の定性区分は以下です。

  • 9.0–10.0: Critical
  • 7.0–8.9: High
  • 4.0–6.9: Medium
  • 0.1–3.9: Low

WP運用の実務目安:

  • Critical（9.0+）: 原則即日。営業時間内に一次対処（更新/無効化/アクセス制限）
  • High（7.0–8.9）: 24〜72時間以内。公開サイトで悪用可能なら当日扱い
  • Medium（4.0–6.9）: 条件付きで優先。認証不要・PoC公開・攻撃観測ありなら前倒し
  • Low（0.1–3.9）: 定期更新タイミングで処理。ただし複合リスクは別評価

重要なのは「スコア」より「攻撃前提条件」です。
未認証で到達可能、かつ公開PoCありなら、Mediumでも実務上はHigh相当で扱うべきケースがあります。

実際のチェック手順（中盤）

導入前チェックリスト（プラグイン選定時）

導入前に最低限見るべき項目を固定化しておくと、事故率が下がります。

項目 合格目安 見る場所
最終更新日 直近6か月以内が目安 WordPress.org pluginページ
アクティブインストール 母数が十分あるか WordPress.org pluginページ
Tested up to 現行WPに追随しているか WordPress.org pluginページ
サポート応答 未解決放置が常態化していないか サポートフォーラム
脆弱性履歴 修正頻度・再発傾向 WPScan / Wordfence / Patchstack / JVN
開発者信頼性 既存実績、運営主体の明確さ 公式サイト・リポジトリ

実務では、以下のようにゲート化すると判断がぶれません。

  • Gate A: 2年以上未更新なら原則不採用
  • Gate B: 重大脆弱性の修正遅延が繰り返されるなら不採用
  • Gate C: 代替候補があるなら保守性の高い方を採用

運用中の定期チェック（週次/月次）

週次ルーチン（15〜30分）

  • インストール済みプラグイン一覧を取得
  • WPScanまたはWordfence/Patchstackで差分照合
  • 「閉鎖プラグイン」有無を確認
  • High/Criticalのみ先にチケット化

月次ルーチン（60分程度）

  • 不要プラグイン削除
  • 代替候補の棚卸し
  • 権限ロール見直し（管理者アカウント最小化）
  • 復旧手順（バックアップからのロールバック）を演習

「閉鎖プラグイン」を見つけた時の対応フロー

  1. そのプラグインを使っている全サイトを列挙
  2. WPScan / Wordfence / JVNでCVE有無を確認
  3. 悪用条件（未認証か、権限要件は何か）を判定
  4. 当日できる一次対策を実施（無効化、WAFルール、アクセス制限）
  5. 代替プラグインの検証計画を立てる

「使えているから様子見」は、最も危険な意思決定です。

自動化とツール比較（後半）

どこまで自動化できるか

自動化しやすい領域:

  • 脆弱性データ取得（API）
  • インストール済みプラグインとの突合
  • CVSSや条件での優先度分類
  • Slack/メール通知

人が判断すべき領域:

  • 事業影響（止められない機能か）
  • 互換性リスク（更新時の副作用）
  • 代替プラグイン移行判断

比較：Wordfence Vulnerability Scanner / Patchstack / Jetpack Protect

ツール 無料/有料 強み 向いている運用
Wordfence（Plugin/Intelligence/CLI） 無料あり・有料機能あり WP運用での導入実績、脆弱性DB/API/Webhook、CLIも選べる 既存Wordfence運用を拡張したいチーム
Patchstack 無料あり・保護は有料中心 検知だけでなくvPatchingで緩和策を取りやすい 更新即適用が難しい多拠点運用
Jetpack Protect 無料あり（有料Scanあり） 導入が簡単、日次スキャン、WPScanデータ基盤 小〜中規模でまず監視を始めたいケース

API連携の最小構成（例）

1. 夜間バッチでサイトごとのプラグイン一覧を収集
2. WPScan API / Wordfence APIで脆弱性情報取得
3. CVSS + 攻撃条件で優先度付け
4. Slack通知 + チケット自動起票
5. 翌営業日朝に担当者レビュー

この形なら、担当者1名でも「見逃し」と「属人化」をかなり減らせます。

2026年運用での推奨ポリシー（実践テンプレ）

最後に、現場でそのまま使える最小ポリシーを置いておきます。

  • 監視ソースは最低3系統（WPScan系 + 公式 + JVN）
  • High以上は24時間以内に一次判断
  • Criticalは即日一次対処
  • 閉鎖プラグインは全サイト横断で当日棚卸し
  • 「更新不能期間」には緩和策（WAF/vPatching/機能停止）を必ず用意

脆弱性対応は、パッチ作業ではなく運用設計です。
どの情報を、誰が、何時間以内に、どこまで判断するか。ここが決まっているチームほど、事故を小さくできます。

まとめ：見抜く力は「情報収集力」ではなく「運用力」

WordPressプラグインの脆弱性は、今後も増え続けます。重要なのは、完璧なツールを探すことではありません。

  • 情報源を分散する
  • 優先度判断を標準化する
  • 自動化で見逃しを減らす
  • 人が判断すべき部分を明確にする

この4点を回し続けることが、結果的に最も強い防御になります。

WP Axisでは、WordPressの復旧・高速化・運用保守に加え、脆弱性監視と更新判断を含む保守運用を提供しています。
「監視はしているが、判断と実行が追いつかない」「担当者依存から抜けたい」という場合は、運用設計から一緒に見直すことが可能です。

まずは、現在のプラグイン構成と監視フローの棚卸しから始めてみてください。そこが、攻撃を受ける前に先回りする第一歩です。

参考情報（2026年4月確認）