Drupal 在 10 月 14 号挂了条核心安全公告，SA-CORE-2026-014，定级 Critical——他们自家的评分给了 19 分（满分 25），漏洞类型一栏写的是远程代码执行，CVE-2026-108097。

第一眼没什么特别的，Drupal 这两年 Critical 也没少发。真让我多看了两眼的是它给的临时缓解措施：把核心自带的 field_ui（Field UI）模块卸掉。一份安全公告，给的应急办法是让你卸一个随核心一起装上的模块，这不太常见。

问题出在反射这一步，归在 CWE-470，unsafe reflection。大意是有一段代码拿外部可控的输入去决定用哪个类、走哪条代码路径，反射执行的时候没把住关。公告点名的位置是核心的 Field UI 模块——就是后台「管理字段」「管理表单显示」那套界面，跑 Drupal 的站基本都开着它。

公告自己也承认：一个干干净净、没装额外东西的 Drupal 核心，这个洞直接打不动。后半句才是重点——配上贡献模块，存在多条实打实的利用路径，其中至少有一条不需要登录。自研代码也可能把这段功能暴露出去。说难听点，装了某些第三方模块的站，这风险不是「理论上可能」。

版本按你自己的分支对：

  • Drupal 11.4.x → 11.4.10
  • Drupal 11.3.x → 11.3.19
  • Drupal 10.6.x → 10.6.19

11.2.x 及更早、10.5.x 及更早，官方标了 EOL，不再发安全更新；8 和 9 更早就是 EOL。公告里受影响区间写得清楚：>=8.9.0 <10.6.19、>=11.0.0 <11.3.19、>=11.4.0 <11.4.10，再加 12.0.0 的 alpha/beta（到 beta2 为止）。

自查两条命令：

drush core:status                                 # 先看清自己的 Drupal 版本
drush pm:list --status=enabled | grep field_ui    # Field UI 是不是启用的
# 没装 drush：/admin/reports/status 看版本，/admin/modules 找 Field UI 的开关

版本落在上面那几行区间里，就在范围内。

赶不上打补丁的，可以先把 field_ui 卸了顶着，公告明说这能提供保护。但卸之前心里得有数：Field UI 管的就是后台「结构 → 内容类型 → 管理字段」那一整套界面，卸了它，这些入口会一起消失。对一个已经上线的站，这不是随手能做的决定。我当时跟同事说的是「先别急着卸，先数数还有几个人在用字段管理页」——回答基本都是没有，可真要确认，还是得一个个去问。另外用了 Drupal Steward 的也别太放心：公告写明了 Steward 只挡已知的一部分攻击路径，覆盖不全。

同一波反射注入，还单独发了个贡献模块的公告 SA-CONTRIB-2026-218（CVE-2026-108099），打的是 Entity List 模块，NVD 记的受影响区间是 0.0.0 到 3.0.10。装了这个模块的，升到最新。

这种「补丁在核心、入口在插件」的洞最容易漏。你盯着 drupal/core 的版本，以为升到 10.6.19 就交差了，可真正的入口在某个贡献模块、或者在你自己的代码里，那它跟核心升没升一点关系都没有。跟之前 PHP2Shell 那波从公开到被利用只隔了几天、Node.js 那个「只负责解压」的库被写穿 是一回事：账要一笔一笔对，先弄明白自己装了什么、各自什么版本。

我们这边现在的做法，是把 field_ui 这种「核心自带、又是 UI 入口」的模块也塞进清单里定期过一遍。说起来挺滑稽的，平时最不设防的往往就是这些「顺手开着」的东西。

来源：Drupal 安全公告 SA-CORE-2026-014、SA-CONTRIB-2026-218；NVD CVE-2026-108097、CVE-2026-108099。