WPScan 插件版本识别实战：基于 Change Log 文件与 BodyPattern 动态查找器的版本检测

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI

WPScan 在扫描 WordPress 站点时，经常需要通过插件目录中的各类文件来确定插件版本。很多插件不提供readme.txt的稳定标签（Stable Tag），却会在仓库里保留格式规整的CHANGELOG.md——本文以debug-bar-rewrite-rules插件的变更日志为例，剖析 WPScan 如何借助「Dynamic Finder（动态查找器）+ BodyPattern」机制，从 Change Log 文件的标题行中可靠提取版本号，并给出可复用的规则配置、源码级原理与排查建议。读完本文，你将掌握 WPScan 指纹库的配置格式、版本提取正则的编写要点，以及如何用仓库内测试数据验证一条 Change Log 规则是否生效。

一、为什么选择 CHANGELOG.md 作为版本指纹

在 WPScan 的动态查找器数据库中，一个插件能否被精准识别版本，取决于能否找到一个「稳定存在且内容含版本号」的文件。对debug-bar-rewrite-rules这类以 Debug Bar 为前缀的调试类插件，其官方发布包中通常没有可用的readme.txt稳定标签（仓库中同类插件如debug-bar-query-tracer、debug-bar-remote-requests均走Readme: path: readme.txt路线，而本插件例外），但根目录下的CHANGELOG.md以## 0.5这类格式连续记录了各版本，恰好形成天然的版本指纹。

从 WPScan 的数据库配置 spec/fixtures/db/dynamic_finders.yml 可以看到该插件的完整规则：

debug-bar-rewrite-rules: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?<v>\d+\.[\.\d]+)/ version: true

这条配置的含义是：以ChangeLog查找器类型注册，使用BodyPattern实现类，请求插件根目录下的CHANGELOG.md，用正则\#\# (?<v>\d+\.[\.\d]+)/在正文中捕获版本号，并将该文件标记为版本来源（version: true）。

二、规则字段逐项拆解

结合 lib/wpscan/db/dynamic_finders/base.rb 与插件自身的 YAML 条目，dynamic_finders.yml中一条 Change Log 规则各字段的作用如下：

三、BodyPattern 的底层实现原理

debug-bar-rewrite-rules的 Change Log 规则最终由 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb 中的BodyPattern类执行，核心逻辑仅一个find方法：

def find(response, _opts = {}) return unless response.code != 404 && response.body =~ self.class::PATTERN create_version( Regexp.last_match[:v], interesting_entries: ["#{response.effective_url}, Match: '#{Regexp.last_match}'"] ) end

其执行链路可以拆成三步：

1. 响应有效性检查：只要 HTTP 状态码不是 404，就对响应体执行规则中声明的PATTERN正则匹配；
2. 命名捕获组取版本：正则命中后，通过Regexp.last_match[:v]取出(?<v>...)命名捕获组的内容作为版本号。这就是为什么pattern里必须出现(?<v>...)——版本号完全依赖这个命名组回填；
3. 记录命中证据：把响应 URL + 完整匹配文本作为interesting_entries写入结果，便于审计。对应当前插件的真实命中记录为：

http://wp.lab/wp-content/plugins/debug-bar-rewrite-rules/CHANGELOG.md, Match: '## 0.5'

也就是说，WPScan 抓取CHANGELOG.md后，正则扫描出第一个（也是全部）满足## <版本号>格式的标题行，取最大的版本号作为该插件当前版本。

四、debug-bar-rewrite-rules 的 CHANGELOG.md 全文解读

规则所依托的指纹文件正是仓库中的 CHANGELOG.md，其内容完整如下：

0.5

• [minor changes] - Localization Changes.
• [improvement] - New Icon (for wordpress.prg) and tags.
• [code refactoring] - Minor code changes.

0.4

• [improvement] - Added track for PHP__invokemethods (callable objects)
• [bugfix] - Added fix for plugin loaded via symlinks
• [code refactoring] - Code of PHP and JS refactored.

0.3

• [ui] UI Change - Domain input box width calculated with JS
• [bugfix] - e.preventDefault()
• [bugfix] - Double check for empty array in filters UI

0.2

• Code refactored from version 0.1

0.1

• Non Public Release

对照 WPScan 的规则正则\#\# (?<v>\d+\.[\.\d]+)，可以验证其匹配行为：

• ### 0.5、### 0.4等行符合##前缀 + 数字版本格式，均能命中并进入候选集合；
• 该正则要求版本号以\d+\.开头，即必须形如x.y或x.y.z...，0.1~0.5全部满足；
• 排序取最大版本，因此最终判定版本为0.5，与 expected 结果完全一致。

值得注意：CHANGELOG 中各版本条目提到的功能点（如 0.4 对 PHP__invoke可调用对象的追踪支持、通过符号链接加载插件的修复；0.3 对前端过滤器 UI 空数组的二次校验等）反映的是插件自身演进，WPScan 并不关心这些语义，只关心标题行格式的稳定可解析性——这正是指纹设计的关键：版本号格式比内容语义更重要。

五、测试与验证：规则如何被证明有效

WPScan 对每条动态查找规则都维护了期望输出数据，存放在 spec/fixtures/dynamic_finders/expected.yml，对应条目为：

debug-bar-rewrite-rules: ChangeLog: number: '0.5' found_by: Change Log (Aggressive Detection) interesting_entries: - 'http://wp.lab/wp-content/plugins/debug-bar-rewrite-rules/CHANGELOG.md, Match: ''## 0.5'''

这份期望数据同时校验了三件事：

1. 提取结果：number: '0.5'，证明从多条版本标题中取到了最大版本；
2. 检测方式：found_by: Change Log (Aggressive Detection)，表明该规则归入 Aggressive（积极）检测模式，仅在主动探测阶段生效；
3. 审计信息：interesting_entries记录了命中的 URL 与正则匹配文本'## 0.5'，与 BodyPattern 源码中"#{response.effective_url}, Match: '#{Regexp.last_match}'"的拼接逻辑一一对应。

此外，仓库中针对readme.txt解析路径的测试 spec/app/finders/plugin_version/readme_spec.rb 也验证了同类 ChangeLog 语义：当 readme 正文存在== 版本号 ==形式的变更日志区块时，会以ChangeLog Section方式给出置信度 50 的版本推断（from_changelog_section实现见 app/finders/plugin_version/readme.rb）。两种机制一为独立文件规则、一为 readme 内嵌区块，互为补充。

六、实战排查与规则调优要点

6.1 确认指纹文件路径是否可达

先核对插件实际目录中是否存在规则声明的文件。对本例而言即检查插件根目录下是否有CHANGELOG.md；若插件同时存在readme.txt，WPScan 会优先走 Readme 查找器（见 app/finders/plugin_version/readme.rb），Change Log 规则只在 readme 无稳定标签时才作为补充来源。

6.2 正则编写检查清单

• 必须使用命名捕获组(?<v>...)，否则Regexp.last_match[:v]取不到值；
• 版本号模式建议带\d+\.前缀，避免误匹配v2、beta等非语义标题；
• 若变更日志同时包含## Unreleased、## 1.0.0-beta等行，需确认正则不会捕获非发布版本；
• 保持锚定。当前正则未锚定行首，若正文中##出现在其他语境（如代码示例）可能造成误报，调优时可改为^##\s+(?<v>\d+\.[\.\d]+)并配合multiline语义测试。

6.3 验证匹配效果

用仓库测试数据的思路离线验证：取 CHANGELOG.md 内容，套用正则/\#\# (?<v>\d+\.[\.\d]+)/提取全部版本号并排序取最大，结果应为0.5；再对照 expected.yml 中的期望输出即可判断规则是否调优成功。

七、小结

通过debug-bar-rewrite-rules的 Change Log 规则，可以完整看到 WPScan 动态版本识别的一条典型链路：插件目录中格式稳定的CHANGELOG.md→dynamic_finders.yml中以BodyPattern类声明的 ChangeLog 规则 → 运行时对响应体做命名捕获组正则匹配 → 取最大版本作为插件版本并附带命中证据。对安全测试人员而言，理解这一机制有助于在扫描结果中解读found_by: Change Log (Aggressive Detection)的来源；对规则维护者而言，本仓库的 YAML 配置、BodyPattern 源码与 expected 期望数据共同构成了一套可复制、可验证的版本指纹编写范式。

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI