本文约 3,920 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：漏洞早就公布了，你只是没查
WordPress 生态里绝大部分成功入侵，利用的不是什么高深的 0day，而是几个月前就公开、补丁也已经发布、但站长没有更新的老漏洞。攻击者手里有自动化扫描器，他们用不了多久就能把全网跑一遍；而站长这边，往往连自己装的插件有没有漏洞都不知道。
原因很现实：WordPress 后台虽然有更新提示，但它只告诉你「有新版本可用」，不会告诉你「当前版本存在可被利用的漏洞」。这两者之间隔着一层信息差，而填补这层信息差需要主动去查漏洞库。
可用的公开漏洞库主要有三个：WPScan Vulnerability Database（由 Automattic 维护，漏洞条目最全）、Patchstack Database（原名 WP White Security，响应快、条目详细）、以及 Wordfence Intelligence。三者各有侧重，配合 WordPress.org 的官方安全公告使用效果最好。
本文给出三种可落地的查询方式：命令行批量扫描、API 程序化查询、网页库检索，并给出从「发现漏洞」到「确认修复」的完整流程。
原理分析：漏洞库记录的是什么
一条典型的 WordPress 插件漏洞记录包含这些字段：
| 字段 | 含义 | 用途 |
|---|---|---|
| Vulnerability type | 漏洞类型：SQLI、XSS、RCE、LFI、Auth Bypass、CSRF 等 | 判断危害等级 |
| Affected versions | 受影响的版本区间，如 <= 3.2.1 |
判断你的版本是否在内 |
| Fixed in | 哪个版本修的，如 3.2.2 |
确定要升到哪个版本 |
| CVE ID | 通用漏洞编号，如 CVE-2024-1234 |
跨库检索、合规报告 |
| CVSS score | 通用漏洞评分，0–10 分 | 判断紧急程度 |
| Auth required | 是否需要登录或特定权限 | 判断被利用的难度 |
| CWE | 弱点分类 | 理解成因 |
理解这几个字段，就能自己判断优先级，而不是看到「有漏洞」就恐慌。举个例子：一个 CVSS 5.4、需要管理员权限、且是 XSS 的漏洞，对于一个只有你一个管理员的个人站来说，实际风险很低；而一个 CVSS 9.8、无需登录的未授权文件上传漏洞，则必须在几小时内处理——这类漏洞通常几天内就会出现大规模自动化利用。
还有一个重要区分：漏洞库收录的是「已公开」的漏洞。厂商私下修复、未公开的漏洞（即 0day）不会在里面。所以漏洞库查询是必要动作，但不是充分保障，定期更新仍然不能省。
保姆级实操
第一步：安装 WPScan
WPScan 是 Ruby 编写的命令行工具，需要 Ruby 环境：
# 安装（Debian / Ubuntu）
sudo apt-get install ruby-full build-essential libcurl4-openssl-dev
sudo gem install wpscan
# 升级漏洞库
wpscan --update
第二步：对站点做完整扫描
推荐使用非侵入式扫描（aggressive 模式会发起大量请求并可能触发 WAF）：
wpscan --url https://example.com \
--enumerate vp,vt,tt,cb,dbe \
--api-token YOUR_API_TOKEN \
--format cli-no-color \
--output-file wpscan-report.txt
参数含义：vp 枚举有漏洞的插件、vt 有漏洞的主题、tt 枚举主题、cb 枚举配置文件备份、dbe 枚举可被公开访问的数据库导出文件。
输出里每条漏洞会标注 [!] Title、受影响版本、固定版本和参考链接。
第三步：用 API 批量查询指定插件
如果只想查某个插件的所有历史漏洞，可以直接调 WPScan 的 API：
curl -s "https://wpscan.com/api/v3/plugins/contact-form-7" \
-H "Authorization: Token token=YOUR_API_TOKEN" \
| python -c "
import sys, json
d = json.load(sys.stdin)
slug = list(d.keys())[0]
for name, v in d[slug]['vulnerabilities'].items():
fixed = v.get('fixed_in') or '未修复'
print(f\"{name} | 类型={v['vuln_type']} | 修复于={fixed} | CVSS={v.get('cvss',{}).get('score','-')}\")
"
免费账号每天有请求次数限制，批量查询建议缓存在本地。
第四步：交叉核对 Patchstack 数据库
# 直接检索插件 slug 对应的漏洞页（浏览器打开或 curl）
curl -s "https://patchstack.com/database/?search=elementor" -o /dev/null -w "%{http_code}\n"
Patchstack 的条目通常附 PoC 说明和利用条件，对判断「我这个配置会不会被打中」很有帮助。另外它提供 WordPress 版漏洞情报订阅，也可以安装其官方插件 Patchstack（原 WP White Security）来做站点侧的实时拦截。
第五步：核对 CVE 与 NVD
拿到 CVE 编号后去 NVD 查 CVSS 详细向量，用于内部风险评估报告和向客户说明：
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-1234" \
| python -c "import sys,json; d=json.load(sys.stdin);
v=d['vulnerabilities'][0]['cve'];
print(v['id'], v['metrics'].get('cvssMetricV31',[{}])[0].get('cvssData',{}).get('baseScore'));
print(v['descriptions'][0]['value'][:200])"
第六步：确认修复
# 更新到修复版本
wp plugin update plugin-slug --version=3.2.2
# 确认当前版本
wp plugin get plugin-slug --field=version
# 复扫确认漏洞已消除
wpscan --url https://example.com --enumerate vp --api-token YOUR_API_TOKEN
常见踩坑
-
只扫一次就完事：漏洞是持续新增的。建议每月至少全站扫一次，关键插件订阅其安全公告。
-
被 WAF 拦截导致扫描结果不准：很多站点前面有 Cloudflare 或安全狗，WPScan 的请求会被挡，表现为大量误报或超时。扫描时可以临时放行扫描 IP，或者用
--random-user-agent降低触发概率。 -
看到「版本区间包含我」就直接删插件：先看
Auth required和 CVSS。有些漏洞利用门槛极高，误删插件反而导致功能中断，风险更大。 -
忽略
Fixed in为空的条目：那意味着厂商还没修。此时要么换插件，要么自己做虚拟补丁（用 WAF 规则拦截对应请求路径）。 -
用过期本地漏洞库扫描：
wpscan --update必须跑，本地库不更新等于查旧账。 -
案例： 某站点使用的表单插件在公开漏洞库中出现一条 CVSS 9.8 的未授权任意文件读取漏洞，修复版本在披露当天就发布了。站长当时没订阅任何情报，两周后才发现站点
wp-config.php被拖走、数据库被导出、首页被替换成勒索页面。事后复盘：漏洞披露到被大规模自动化利用，通常只有 3–7 天窗口。教训是——高危及无权限要求的漏洞，必须当天处理。 -
扫描本身触发告警：对生产站扫描会产生大量请求，可能被主机商判定为攻击。先在预发布站或低峰期做。
总结
漏洞查询应该做成例行流程，而不是出事后的补救动作。建议固定成月度动作：
wpscan --update更新本地库；- 对生产站跑一次
--enumerate vp,vt； - 对 CVSS ≥ 7.0 或无需登录的漏洞当天处理；
- 处理完复扫确认；
- 无法立即更新的，用 WAF 加临时规则并排期。
优先级排序记住一条：无需认证 + 高 CVSS = 立即处理；需要管理员权限 + 中低 CVSS = 排期处理。全站插件的漏洞扫描结果出来后，如果某个插件反复出现高危漏洞，就该考虑换掉了——这往往也是判断 识别已弃用插件 的重要信号。另外，选插件阶段就该先查一遍漏洞历史，方法在 挑选插件的 8 条硬标准 里有说明。
