wpscan 仅适用于 WordPress 站点，无法扫描裸 PHP 或其他框架站点；需先确认目标含 wp-content 等特征，再更新数据库、指定根 URL 并启用 --enumerate vp 扫描插件漏洞。
wpscan 无法扫描 PHP 站点本身？先搞清定位
wpscan 不是通用 PHP 漏洞扫描器，它只针对 WordPress 构建的站点。如果你输入的是一个裸 PHP 网站（比如手写 index.php、基于 ThinkPHP/Laravel/CMS 自研系统），wpscan 会直接报错或返回 “Not a WordPress site” —— 这不是配置问题，是工具边界。
常见错误现象：
- 扫描后输出
[!] The target does not appear to be a WordPress site -
--enumerate无响应，或大量 403/404 - 误以为目标“没漏洞”，其实是工具用错了
正确做法：
- 先确认目标是否真为 WordPress：检查 HTML 源码是否有
wp-content、wp-includes、/wp-login.php路径 - 若非 WordPress，换用
nikto、gau+ffuf、或手动审计phpinfo()、文件包含点、反序列化入口等
用 wpscan 扫插件漏洞前必须做的三件事
wpscan 默认不主动探测插件漏洞，需显式启用枚举 + 漏洞检查，且依赖本地数据库更新。
立即学习“PHP免费学习笔记（深入）”；
必须步骤：
- 运行
wpscan --update（否则插件指纹库过期，漏掉已知 CVE） - 使用
--url指向根路径（如https://www.php.cn/link/b05edd78c294dcf6d960190bf5bde635），不能只扫子目录（https://www.php.cn/link/b05edd78c294dcf6d960190bf5bde635/wp-admin会跳过主题/插件发现） - 加上
--enumerate vp（v=vulnerabilities,p=plugins），单独--enumerate p只列插件名，不查 CVE
性能影响：
-
--enumerate vp比--enumerate p多耗时 3–5 倍，因要逐个比对 WPScan DB 中的 CVE 映射 - 若网络慢或目标响应延迟高，可加
--throttle 3避免被封
绕过 WAF 或登录态限制的实操要点
很多 WordPress 站启用了 Cloudflare、Wordfence 或自定义 WAF，wpscan 默认请求容易被拦截（返回 403 / 503 / 验证码页面）。
有效应对方式：
- 添加可信 User-Agent：
--user-agent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36" - 若目标需登录才能访问 wp-admin，用
--cookie注入已登录会话：--cookie="wordpress_logged_in_abc123=..." - 避免高频扫描：
--max-rate 1或--random-user-agent降低触发阈值 - 不要强行加
--force：它只会重试 HTTP 请求，对 WAF 无效，反而暴露扫描行为
注意：wpscan 不支持自动处理验证码或 JS 挑战，遇到 Cloudflare “Checking your browser…” 页面，得换人工识别或换代理池。
结果里看到 CVE 编号，下一步不是直接利用
wpscan 输出类似 [+] Name: contact-form-7 → [!] Vulnerable Versions: → [!] Possible CVEs: CVE-2021-24384，这仅表示“该版本存在公开 PoC”，不代表当前环境可打。
你需要验证：
- 目标实际运行的插件版本是否真在漏洞范围内（有些站点改了
readme.txt但未更新代码） - CVE 对应的攻击面是否存在（如 CVE-2021-24384 需开启邮件功能且未禁用附件上传）
- 是否有补丁被绕过（例如某些厂商“修复”只是隐藏报错，实际仍可 SSRF）
别跳过手工验证环节。一个 curl -I https://www.php.cn/link/2d821f9d210b3b0ec98f18bf84253c0f 查版本，比盲打 PoC 更可靠。
WordPress 插件漏洞的上下文依赖太强，同一 CVE 在不同配置下可能完全不可利用。
