Drupal 安全团队在 10 月 28 日发布 SA-CONTRIB-2026-254，Commerce Core 模块的授权保护有缺口，未登录访客可以绕过访问控制去改订单和实体字段，官方已确认这个洞正在被在野利用。
Drupal 安全团队在 10 月 28 日发布 SA-CONTRIB-2026-254，Commerce Core 模块的授权保护有缺口，未登录访客可以绕过访问控制去改订单和实体字段，官方已确认这个洞正在被在野利用。
这次漏的到底是什么
Commerce Core 是给 Drupal 做商城的模块，购物车、结账表单、以及解耦前端调用的接口都归它管。通报的措辞很直接：模块“没有充分保护某些路由和某些实体字段”，形成访问绕过，可能对商家造成资金损失。Drupal 自己的风险评分是 21/25，属于 highly critical；美国 CISA 数据管道给出的 CVSS 是 6.5，两个数字一个说“有多严重”，一个说“单点有多严重”，并不矛盾。
受影响范围是 2.x 分支 8.x-2.41 之前的版本，以及 3.x 分支 3.0.0 到 3.3.12。修复版对应 8.x-2.41 和 3.3.13。公告没有给任何变通方案，也就是只能升。官方给出的装机量是四万二千多个站点，其中不乏大企业和高校的电商站。
为什么“逐条检查都正常”反而危险
授权这件事是枚举式的：写一条路由，补一条权限检查。缺陷恰恰长在没被枚举进去的那几条上。拿着清单逐项复核的人不会出错，出错的是清单本身不完整。这也是为什么这类洞总出现在“边角接口”上——导出、批量操作、后台小工具，平时没人点，也就没人检查。
更麻烦的是后果落在钱上：订单状态可被改，折扣可被套，商品可能被白拿。安全事件和财务报表在这里是同一件事。
升级怎么做
先备份数据库和代码，再确认版本：composer show drupal/commerce。3.x 分支执行 composer require 'drupal/commerce:^3.3'，2.x 分支用 ^2.41，两条命令只按当前分支选一条。升完跑 drush updatedb -y 和 drush cr，再回读一次版本号，确认真的落在修复版上。如果 composer 的约束把版本卡在旧版，先松约束，别把冲突留成“以后再处理”。
补完之后要查订单
通报明确要求核对订单是否异常。事后动作是查业务数据，不是翻安全设备日志：找状态已完成但金额小于等于零的单，找短时间内被批量改价的单，找支付状态和发货状态对不上的单。用解耦前端的站，还要顺手过一遍哪些接口路由是公开的，未登录的写请求先在 WAF 上挡掉。
对站长的实际影响
国内跑 Drupal 商城的站不多，但外贸独立站、多语言站用 Commerce 的不少，这类站订单金额大、发货周期长，被改一次价可能要几周后对账才发现。不能马上升级的，至少先在边缘挡掉未登录的写请求，再排维护窗口——挡不是修，只是买时间。
另外提醒一句：Drupal 10 会在 12 月 9 日停止支持，还在 10 上的站，这次升 Commerce 顺手把大版本迁移排进日程更划算，省得 12 月再折腾一遍。
本文根据公开报道整理，主要参考：Drupal 安全公告 SA-CONTRIB-2026-254 与 dev.to 技术分析（2026-10-28）。
