Mercury 最新RCE审计：一个逗号如何清空访问控制层

0x01 公告事实核对 下表是公告陈述与核对结果的对照。转述类稿子最常见的毛病是把公告没写的东西当成公告里写了的，技术上的计算错误反而是少数，所以这一节全部按"能否在原始数据里找到"来判定。 项目 公告 / 转述稿 核到的原始值 判定 GHSA 编号 — GHSA-f8c7-rwf9-fmgm ， type=reviewed ，GitHub 已审阅 A CVE 编号 CVE-2026-111057 identifiers 里确有该 CVE；但 nvd_published_at = null A（NVD 侧尚无记录） 标题 未认证 RCE Mercury: Unauthenticated Remote Code Execution in /api/terminals - access control bypass A 严重性 critical severity = critical A CVSS 10.0 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0；CVSS v4 字段为空 A CWE — CWE-185 （Incorrect Regular Expression）+ CWE-284 （Improper Access Control） A 影响版本 3.0.0–3.2.3 vulnerable_version_range = ">= 3.0.0, <= 3.2.3" ， package.name = mercury （pip） A 修复版本 3.2.4 first_patched_version = "3.2.4" A 公开时间 — published_at = 2026-10-19T17:00:54Z A 成因 一个缺失的逗号 公告原文 A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list A（陈述）→ 本文 0x03 执行验证 PoC 环境 本地 Docker，Mercury 3.2.3，默认配置 公告 Details 段原文如此 B（研究者陈述，本文不复现） 实测 uid=0(root) 有 公告 PoC 段附了输出 B（同上） 已进 CISA KEV 部分转述稿暗示 KEV 目录 catalogVersion = 2026.10.16 、1748 条， 不含 CVE-2026-111057 A（否定了这个暗示） 表里有两处需要展开说。 第一处是包名。转述稿写的是 mljar/mercury （仓库名），PyPI 上的包名是 mercury ，不是 mljar-mercury 。查 mljar-mercury 时 PyPI 返回 {'message': 'Not Found'} 。这个差别在写自动化自查脚本时会变成"包扫不到、以为没装"。 第二处，"CVE 已分配"和"NVD 已发布"是两件事。 nvd_published_at = null 意味着此刻这个编号只在 GHSA 侧成立。如果漏洞管理流程以 NVD 同步为准，这条漏洞现在还在"厂商已确认、NVD 未收录"的窗口里，这类窗口恰恰最容易漏。 另外纠正传播中的一处说法：有稿子把影响版本写成"3.x 全系列"。公告写的是 <= 3.2.3 ，3.2.4 起已修；而 3.2.5 又往清单里加了一条（见 0x0a）。"全系列"既夸大了受影响面，也掩盖了"3.2.4 修得不完整"这个更有价值的信息。 0x02 审计环境与取证口径 源码坐标 mkdir -p src && cd src git clone --no-checkout https://github.com/mljar/mercury.git mercury git -C mercury worktree add ../mercury-v323 v3.2.3 git -C mercury worktree add ../mercury-v324 v3.2.4 用 --no-checkout 加 worktree，而不是 clone 两次，是为了让两个版本共享同一份对象库，同时行号在两个版本上都能独立解析。本文所有 file:line 指的是 src/mercury-v323/... 或 src/mercury-v324/... 下的真实文件。 第三方依赖同样落盘，因为根因的一半在依赖里： 目录 来源 版本 src/jupyter-deps/jupyter_server-2.18.2/ pip download jupyter_server --no-deps + 解包 2.18.2 src/jupyter-deps/jupyter_server_terminals-0.5.4/ 同上 0.5.4 src/jupyter-deps/tornado-6.4.2/tornado/routing.py 从验证用 venv 里拷出 6.4.2 中间踩过一个坑： terminals 的处理器并不在 jupyter_server/terminals/ 下。2.x 之后它搬到了独立的 jupyter_server_terminals 包，而 jupyter_server 2.18.2 的 METADATA 第 60 行强制依赖 jupyter-server-terminals>=0.4.4 。最初按 1.x 的路径去 grep jupyter_server/terminals ，扑了个空，最后是从 auth/utils.py:55-60 里硬编码的终端 URL 正则反推出真实位置的。 证据分级 A 级 — 在本机源码上直接读到，或本机执行算出（规则条数、合并后的正则文本、路径匹配结果、traitlets 特征值、git 提交日期、PyPI 上传时间、GHSA 字段）。 B 级 — 公告与研究者的陈述。引用，不复现、不背书。 C 级 — 想确认但没确认到的。写出来标着，不猜。 探针清单与执行范围 六支探针加一次自查复跑，脚本随文附在 scripts/ ，完整输出在 mercury-repro-output.txt （探针 1–5 采集于 2026-10-20T06:28:07Z，探针 6 采集于 2026-10-20T07:11:11Z，自查 A 转录采集于 2026-10-20T07:37:55Z；tornado 6.4.2，Python 3.9.6）。 编号 脚本 证明了什么 级别 探针 1 probe_shapes.py 两个版本运行时各 3 / 4 条规则；合并文本 98 字符；3.2.3 相对 3.2.4 少拦住 6 条路径形状 A 探针 2 probe_blocklist.py 16 条路径 × 2 版本， re.fullmatch 与 tornado PathMatches 零分歧 A 探针 3 probe_router.py 按 app.py:116-119 原样装配 Rule 后， /api/terminals 与 /lab 落到上游处理器 A 探针 4 交叉验证 v3.2.4 自带的测试跑在 v3.2.3 源码上 → 2 f