10 月 28 日，Drupal 安全团队发布 SA-CONTRIB-2026-254，修复 Commerce Core 的一处授权缺失漏洞，编号 CVE-2026-118539，Drupal 自评风险 21/25（Highly critical），并在公告里明确写了「正在被在野利用」。受影响的是 Commerce Core 0.0.0 到 2.41、以及 3.0.0 到 3.3.13。修这个洞要升 Commerce Core，不是升 Drupal 核心 —— 这是本周最容易踩的坑。
事件概述
Commerce Core 不是 Drupal 本体，而是给 Drupal 装上购物车、结账流程和 API 结账能力的贡献模块。Drupal 官方统计超过 4.2 万个站点在用，其中不乏大型企业和高校站点。修复版本是 3.x 分支的 3.3.13，以及更早分支的 8.x-2.41。
同一天，Commerce Core 还修了 SA-CONTRIB-2026-255 到 259 五个低到中危问题（信息泄露、访问绕过、跨站请求伪造），Commerce License、Commerce Shipping、Commerce Stripe 也各自发了公告。维护方建议这几个一起升，避免版本互相卡住。
技术细节
Drupal 的公告只有一句话：模块没有充分保护某些路由和实体字段，导致 access bypass，可能给商家带来财务损失。翻成工程语言就是 NVD 记录的 CWE-862（授权缺失），表现是 forceful browsing —— 攻击者不去破密码、不去绕加密，而是直接请求一个本该被拦下的路由或字段，应用放行了。
风险向量给得很干脆：AC:None / A:None / CI:Some / II:Some / E:Exploit / TD:All。匿名可达、不需要任何账号、所有模块配置都可被利用、已有在野利用代码、部分非公开数据可被读取、部分数据可被修改。NVD 在 10 月 29 日收录该 CVE，标注 CWE-862，CVSS 尚未评分 —— 这种情况下 Drupal 自己的 21/25 比 NVD 的空白更有参考价值。
维护方 Centarro 与 Drupal 安全团队联合发布的说明提供了最有用的部分：线索来自两家商户上报的可疑订单。手法按复杂程度分四档：
- 不走支付流程直接下单；
- 订单看起来已付款，但背后没有对应的支付记录（主要出现在允许 JSON:API 写入的站点）；
- 结账前修改商品价格，报告里出现了 0.01 美元这类明显异常的价格；
- 塞进店方没设过的折扣、费用或其他调整项。
还有一条容易被忽略的时间线：这个洞在理论上可利用已久 —— JSON:API 站点自 8.x-2.18（2020 年 5 月）起，其他站点自 8.x-2.25（2021 年 6 月）起。也就是说，补丁打得再快，历史订单也得往前翻。
影响评估
损失落在商户侧。攻击者拿到的是「货已发出、权限已开通，但钱没收够」，而不是数据库里的用户名密码。对客单价高的站来说，一次成功的伪造订单就可能顶掉几个月的利润。
Centarro 截至 10 月 29 日表示，尚不认为该漏洞已被脚本化、也没看到扩散到最初上报站点之外的证据。该 CVE 未进入 CISA KEV。但这是 5 月以来 Drupal 生态第三个被标记为在野利用的漏洞，模块生态正在被系统性盯上。
修复建议
升级是唯一彻底的办法，Composer 环境下的操作：
composer require drupal/commerce:^3.3.13
composer update drupal/commerce --with-dependencies
drush updatedb && drush cr更早的分支要指定 drupal/commerce:2.41（即 8.x-2.41）。升级后按维护方清单审计订单：查是否存在未经过支付流程的订单、宣称已付款但无支付流水的订单、单价与商品原价不符的订单、以及没有人工操作记录却出现的折扣与费用调整。重点看近期，同时对历史上线时间更早的站点做抽样回溯。
临时缓解手段有限。WAF 侧可以对 /checkout、/cart 和 JSON:API 的写入路径加规则，但这只能提高利用门槛，挡不住已经知道字段名的人。真正要做的还是升级，并且顺手把 Commerce 相关模块的版本统一到同一批次。