从 CHANGELOG.md 到插件版本识别：WP Featherlight 变更记录与 WPScan ChangeLog 动态查找器解析

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

导读

本文以 WPScan 仓库中 WP Featherlight 插件的 CHANGELOG.md 为核心，完整梳理该插件从 0.1.0 到 1.3.0 的版本变更史，并深入解析 WPScan 如何将这份变更日志作为"版本指纹"实现插件版本自动检测：包括dynamic_finders.yml中的查找器配置、BodyPattern的底层匹配逻辑、被动/主动两种检测路径以及测试验证机制。读完本文，你将既掌握 WP Featherlight 插件各版本的功能演进与维护要点，也理解 WPScan 基于 ChangeLog 的插件版本识别原理，能够在自己的 WordPress 安全扫描与插件分析工作中直接复用这套方法。

一、文档定位：一份"双重身份"的 CHANGELOG

在 WPScan 仓库中，这份 CHANGELOG.md 具有双重身份：

• 插件侧：它是 WP Featherlight（一款超轻量级 jQuery 图片/画廊 lightbox 插件）随插件分发的版本变更记录，完整记录了 0.1.0 至 1.3.0 共 8 个版本的功能特性、缺陷修复与内部重构；
• 扫描器侧：它是 WPScan 动态查找器（Dynamic Finder）体系的测试夹具（fixture）。WPScan 会在攻击性扫描中请求目标站点上的wp-content/plugins/wp-featherlight/CHANGELOG.md，用正则提取其中的版本号，从而在不依赖 readme.txt 的情况下确认插件版本。

同一目录下的 wp-featherlight.pot（翻译模板文件，头部标注Project-Id-Version: WP Featherlight 1.2.0）与这份 ChangeLog 共同构成了针对该插件的多条版本检测证据链。

二、WP Featherlight 版本史：完整变更记录解析

1.3.0：Gutenberg 支持与所有权变更

1.3.0 本质上是维护版本，但引入了一个新特性：支持 Gutenberg 画廊。除此之外：

• 特性：Gutenberg 支持；
• 微调：插件整体代码清理；
• 开发：将底层 Featherlight 库更新到1.7.13；
• 项目层面：插件发生所有权变更。

1.2.0：图片说明支持 HTML

同样以维护为主，新增特性：允许在 lightbox 图片说明（caption）中显示 HTML。此外将 Featherlight 更新到1.7.9、jQuery Detect Swipe 更新到2.1.4。

1.1.0：可访问性与管理后台稳定性

得益于核心 Featherlight 脚本的改进，插件可访问性显著提升：lightbox 元素对屏幕阅读器有了更合适的焦点管理，关闭按钮也更易访问。

同时修复了一个潜在的管理后台兼容问题：在 1.0 版本中，非正常情况下尝试向发布 metabox 添加禁用复选框时可能抛出致命错误。

• 微调：改进可访问性（可访问的关闭按钮、更好的焦点管理）；
• 修复：防止当其他插件在发布 metabox 上 unset 了WP_Post对象时发生致命错误；
• 开发：Featherlight 更新至1.7.0。

1.0.0：不兼容变更的里程碑

虽然是主版本号跳跃，但本质仍是维护版本。跳至 1.0.0 的原因是改动可能破坏与自定义扩展/集成的向后兼容性：

• 对普通站点使用者：直接更新即可，无需额外处理；
• 对开发者：若编写了扩展 WP Featherlight PHP 侧的代码，务必在更新前测试；插件废弃了部分内部方法，改动主要集中在类初始化环节。

具体变更：

• 微调：改进画廊内图片之间的过渡；
• 微调：将"禁用 lightbox"复选框移入发布 meta box，简化管理后台；
• 微调：样式更激进，确保元素在不同主题下默认表现一致；
• 修复：减少对"使用图片扩展名但实际并未链接到图片的 URL"的误报；
• 开发：Featherlight 更新至1.5.1，jQuery Detect Swipe 更新至2.1.3；
• 开发：废弃部分内部方法；
• 开发：重新组织类的实例化方式与插件动作（action）的触发顺序。

0.3.0：自动说明、多语言与内部重构

该版本包含大量内部改动，同时带来前端新特性：

新特性

• 为 WordPress 图片与画廊项目自动生成说明文字（含 Jetpack 画廊）；
• 西班牙语翻译。

增强

• Featherlight 更新至1.3.3；
• 改进桌面端与移动端画廊样式，精简整体样式；
• 新增 SVG 图标，保证跨平台视觉一致；
• 简化管理 metabox 文案以方便翻译。

缺陷修复

• 改进某些缓存插件启用时的图片处理；
• 防止画廊箭头被 WP Emoji 劫持；
• 修复可通过键盘命令打开多个 lightbox 的 bug。

开发者事项

• 仅在需要时加载语言文件，降低开销；
• 改进管理 metabox 的保存例程；
• 新增wp_featherlight_captions过滤器控制自动说明功能（过滤为 false 可禁用说明）；
• 重构插件内部代码结构并废弃插件常量；
• 引入 Grunt 与 Bower 便于后续更新与发版。

新增语言支持：德语、西班牙语、法语、巴西葡萄牙语、秘鲁西班牙语。

0.2.0：外部图片自动 lightbox 与视觉加载器

本版本的核心特性是新增视觉加载器，并自动对站外图片启用 lightbox。此前仅 WordPress 主机域内的图片会被自动 lightbox，使用 CDN 的站点会因 URL 被视为外部而无法触发。同时：

• 新增 Jetpack Tiled Galleries 支持；
• 改进 URL 处理以自动匹配更多图片实例；
• 修复 textdomain 路径错误；
• 改进管理 metabox 标记；
• 修复主样式表脚本句柄（handle）的拼写错误。

0.1.1：画廊行为修正

修复了导致所有WordPress 画廊都在 lightbox 中打开的 bug。现在只有设置为"链接到媒体附件"的画廊才会使用 Featherlight 打开。

0.1.0：初始发布

插件首个公开发布版本。

三、WPScan 中的 ChangeLog 动态查找器：配置与原理

3.1 查找器配置：一份 YAML 即一条检测证据

WPScan 的插件版本动态查找器配置统一维护在 spec/fixtures/db/dynamic_finders.yml（生产数据通过数据库更新机制下发，结构一致）。其中wp-featherlight的配置如下：

wp-featherlight: QueryParameter: files: - css/wp-featherlight.min.css - js/wpFeatherlight.pkgd.min.js version: true TranslationFile: class: BodyPattern path: languages/wp-featherlight.pot pattern: !ruby/regexp /"Project\-Id\-Version:\ WP Featherlight (?<v>\d+\.[\.\d]+)/i version: true ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?<v>\d+\.[\.\d]+)/ version: true Readme: path: readme.txt

针对同一插件，WPScan 配置了四条相互独立的检测途径：

其中 ChangeLog 查找器的关键三要素是：

• class:BodyPattern—— 表明该查找器复用"响应体正则匹配"实现（在 base.rb 中，BodyPattern是允许的动态查找器类之一）；
• path:CHANGELOG.md—— 攻击性扫描时请求的插件内相对路径；
• pattern:/\#\# (?<v>\d+\.[\.\d]+)/—— 匹配 Markdown 二级标题中的版本号，命名捕获组v即提取出的版本值。

3.2 底层实现：passive 与 aggressive 两条路径

动态查找器的通用基类 finder.rb 定义了两种检测模式：

def passive(opts = {}) return if self.class::PATH homepage_result = find(target.homepage_res, opts) # ...若首页无结果则尝试 404 页 find(target.error_404_res, opts) end def aggressive(opts = {}) return unless self.class::PATH find(Browser.get(target.url(self.class::PATH)), opts) end

• 被动检测（passive）：仅当配置中没有path时才执行，且只分析首页与 404 页响应。QueryParameter查找器即属于此类——它从页面引用的 CSS/JS 资源 URL 的?ver=参数中直接读取版本。
• 主动检测（aggressive）：仅当配置中存在path时才执行。ChangeLog查找器带path: CHANGELOG.md，因此只会走主动路径：直接请求http://<目标>/wp-content/plugins/wp-featherlight/CHANGELOG.md并对响应体做正则匹配。

对应的匹配实现位于 body_pattern.rb：

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. 404 防护：响应码为 404 时直接放弃匹配——CHANGELOG.md 文件不存在（例如插件未安装、目录被改名）时不会产生误报；
2. 版本提取：Regexp.last_match[:v]取正则中命名捕获组v的内容，即## 1.3.0中的1.3.0；
3. 证据记录：interesting_entries会记录实际请求的 URL 与完整匹配文本，作为审计证据输出到扫描报告。

生成的版本对象由 version/finder.rb 的create_version完成，found_by与confidence会被自动填充（BodyPattern的默认置信度为 60）。

四、期望结果与测试验证：数据是怎么被校验的

4.1 期望值定义

expected.yml 中记录了wp-featherlight各查找器的期望检出结果：

wp-featherlight: QueryParameter: number: 1.2.0 found_by: Query Parameter (Passive Detection) confidence: 20 interesting_entries: - http://wp.lab/wp-content/plugins/wp-featherlight/css/wp-featherlight.min.css?ver=1.2.0 - http://wp.lab/wp-content/plugins/wp-featherlight/js/wpFeatherlight.pkgd.min.js?ver=1.2.0 TranslationFile: number: 1.2.0 found_by: Translation File (Aggressive Detection) interesting_entries: - 'http://wp.lab/wp-content/plugins/wp-featherlight/languages/wp-featherlight.pot, Match: ''"Project-Id-Version: WP Featherlight 1.2.0''' ChangeLog: number: 1.3.0 found_by: Change Log (Aggressive Detection) interesting_entries: - 'http://wp.lab/wp-content/plugins/wp-featherlight/CHANGELOG.md, Match: ''## 1.3.0'''

这份期望数据揭示了两个关键事实：

• ChangeLog 检出的是最新版本 1.3.0（匹配文件顶部的## 1.3.0标题），而翻译文件与?ver=参数停留在 1.2.0——版本证据来源不同、检出结果可以不一致，这正是多证据交叉验证的价值所在；
• 三条检测途径的found_by命名规范统一为"<查找器名> (Passive|Aggressive Detection)"，ChangeLog 的检出类型明确标记为Change Log (Aggressive Detection)。

4.2 测试如何自动生成

WPScan 的插件版本动态查找器测试是全自动生成的： plugin_version_spec.rb 遍历versions_finders_configs中的每一个插件/查找器组合，动态创建describe块并分别测试#passive与#aggressive：

• 对带path的 ChangeLog 查找器，#passive期望返回nil（因为return if self.class::PATH）；
• #aggressive则 stub 插件目录下CHANGELOG.md的响应（即当前这份 CHANGELOG.md 夹具），并断言返回的WPScan::Model::Version的number、found_by、interesting_entries与 expected.yml 完全一致。

当某个查找器测试失败时，官方建议用rspec -e "<Full Description>"定位，例如：

rspec -e "WPScan::Finders::PluginVersion::WpFeatherlight::ChangeLog#aggressive"

大量生成用例会被标记为slow，仅在主分支的完整测试套件中运行（参见 plugin_version_spec.rb 的说明）。

4.3 配置→类的动态装配

从 YAML 配置到实际运行的查找器类，装配逻辑在 plugin.rb 中完成：

• maybe_create_module(slug)将 slug（如wp-featherlight）分类化为WpFeatherlight常量模块（plugin.rb）；
• create_versions_finders(slug)遍历该插件的查找器配置，通过version_finder_super_class(klass)（即WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern）调用create_child_class动态生成子类（plugin.rb），子类继承PATTERN、PATH等常量（finder.rb）；
• 若配置中的class未在allowed_classes白名单内（base.rb），则跳过而非报错，保证"数据库更新了但工具版本较旧"时扫描仍可运行（plugin.rb）。

五、实战要点：ChangeLog 版本检测的应用与边界

5.1 为什么 CHANGELOG.md 是可靠的版本指纹

• 分布广泛：主流插件普遍随包分发CHANGELOG.md或changelog.txt，且文件名几乎不随版本变化；
• 格式稳定：版本标题通常以## 1.3.0或Version 1.0等强规律格式书写，适合正则提取；
• 补充 readme：许多插件在 readme.txt 中不写 Stable Tag 或版本信息不完整时，ChangeLog 提供了第二条证据链。

5.2 正则选择与误报控制

wp-featherlight的 ChangeLog 正则为/\#\# (?<v>\d+\.[\.\d]+)/，只匹配 Markdown 二级标题形态的版本号。对比同仓库wp-featherlight-disabled插件的配置（dynamic_finders.yml）：

wp-featherlight-disabled: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /Version (?<v>\d+\.[\.\d]+)/i version: true

该插件采用Version 1.0风格标题，因此正则改为大小写不敏感的Version (?<v>...)。这说明ChangeLog 格式因插件而异，正则必须按目标文件的真实格式定制。同时由于采用命名捕获组与version: true标记，只要新版本标题形如## 2.0.0，无需改动配置即可自动检出——这是版本向前兼容的关键设计。

5.3 检测流程回顾（以 wp-featherlight 为例）

1. WPScan 加载数据库中的dynamic_finders.yml，发现wp-featherlight的ChangeLog查找器（class: BodyPattern、path: CHANGELOG.md）；
2. 扫描器确认站点存在wp-featherlight插件（通过其他查找器，如 QueryParameter 或主动枚举）；
3. 主动检测阶段请求wp-content/plugins/wp-featherlight/CHANGELOG.md；
4. BodyPattern#find校验响应非 404，并对响应体执行/\#\# (?<v>\d+\.[\.\d]+)/匹配；
5. 命中## 1.3.0后，以v = 1.3.0构造WPScan::Model::Version，found_by记为Change Log (Aggressive Detection)，置信度取默认 60，匹配 URL 与文本写入interesting_entries；
6. 结果与 expected.yml 中的期望值逐一比对，由自动生成的 rspec 用例守护正确性。

六、延伸：从变更日志反推安全信息

从本文这份 CHANGELOG 还可以读出对安全扫描有参考价值的信息：

• 依赖版本追踪：Featherlight 底层库在 0.3.0→1.3.0 间从1.3.3演进到1.7.13，若底层库存在已知漏洞，可通过插件版本反查受影响范围；
• 修复信号：1.1.0 修复管理后台致命错误、0.3.0 修复键盘多开 lightbox、0.1.1 修复画廊误触发——这些"修复"条目正是判断插件补丁版本、评估旧版本风险暴露面的直接依据；
• 兼容性边界：1.0.0 明确声明废弃内部方法、可能破坏自定义扩展——审计自定义代码时需关注该版本边界。

结语

一份看似普通的 CHANGELOG.md 在 WPScan 体系中同时扮演着"插件历史档案"与"版本检测证据"两个角色：它既记录了 WP Featherlight 从轻量图片 lightbox 到支持 Gutenberg 画廊、多语言与可访问性的完整演进路径，也是 ChangeLog 动态查找器（BodyPattern+ 版本标题正则）的实战样本。理解这套"YAML 配置 → 动态装配查找器类 → 正则提取版本 → 期望值比对"的流水线，你便掌握了 WPScan 插件版本识别机制的一个完整切片，可直接迁移用于分析其他以 ChangeLog 为版本指纹的 WordPress 插件。

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