2026 年 8 月下旬，CISA 在一次常规更新里把 Metabase 的一个 SQL 注入漏洞塞进已知被利用漏洞（KEV）目录，编号 CVE-2026-72898，CVSS 评分被打到满分 10.0。Metabase 不是那种会登上热搜的明星软件，它是企业里那个默默工作的开源 BI 工具——挂着 Apache License，被无数小团队和创业公司拿来跑内部看板、接数据库、出报表。正因为它太普通，这个满分漏洞的杀伤力才被严重低估：攻击者甚至不需要登录，只要对着一个为「找回密码」设计的接口发几个请求，就能把整个应用数据库的权限和每一个连接的库都攥在手里。
一、它的暴露面：一个为「忘记密码」而生的接口，成了未授权入口
Metabase 的架构并不复杂。它是一层夹在浏览器与业务数据库之间的分析层：通过 JDBC 连 MySQL、PostgreSQL、MongoDB 等数据库，用卡片（card）、问题（question）和仪表盘（dashboard）把查询结果做成可视化。这层「夹心」决定了它的安全边界——所有指向后端数据的逻辑，都得先经过 Metabase 自身的认证与应用数据库。
这次出问题的，是 reset_password 数据库端点的调用链。这个端点原本承担「用户忘记密码后重设」的正当功能，需要接收数据库连接信息才能完成密码重置。问题恰恰在于：这个端点被设计成在认证之前就可以访问。攻击者把恶意 SQL 拼进普通请求，让这个本该只读写「用户表」的重置流程，变成一次对应用数据库的任意语句执行。
用研究者的话说，这是「把管理员钥匙挂在外面，却只在门口放了一块『请勿打扰』的牌子」。Metabase 的研究员在官方说明里承认，问题源于对输入拼接缺乏足够的参数化处理——一个在 2026 年几乎被称为安全常识的要求，因为出现在一条不那么起眼的恢复链路上，就漏了过去。
二、漏洞成色：CVE-2026-72898 到底能造成什么
先在 CVE 目录里看它的官方定性和修复范围。CVE 记录与 CISA KEV 页面给出的受影响版本段是：>= x.58.0, < x.58.23、>= x.59.0, < x.59.20、>= x.60.0, < x.60.1。也就是说，从 58 到 60 三个主干版本，只要没升到对应补丁号，都在射程内。
漏洞的类型是 SQL 注入（CVE 目录归到 CWE-89）。结合它出现在 reset_password 链路的事实，攻击者可以直接向 Metabase 应用数据库注入任意 SQL，利用它拿到管理员权限，进一步做三件事：
改配置：篡改应用设置，把原本安全的连接配置指向攻击者可控的地方；
偷凭据：读取 Metabase 内部保存的、用于连接后端数据库的账号和口令；
导出数据：通过这条链路，把读取权限范围内的所有业务数据批量拉走。
Dataminr 的情报简报把这起事件定性为「暴露了数千个自托管实例」，CriminalIP 与 XanySec 的分析也都指向「高评分 CVE + 海量暴露面」的组合。对企业最致命的一点是：它要的权限是零。不需要合法的 Metabase 账号，不需要已认证的会话，只需要知道目标对外暴露了 3000 端口（Metabase 默认端口）就能开始尝试。对攻击者来说，这几乎是互联网上最标准的「拉网式」目标。
三、在野利用与时间线：漏洞不是被「发现」的，是 CISA 用 KEV 把它「定性」的
一个漏洞被放进 CISA KEV 目录，并不等于 CISA 在当天发现了它。KEV 目录的收录规则是「必须掌握该漏洞被真实利用的证据」。CVE-2026-72898 进入 KEV，意味着在公开补丁发布之后、甚至之前，已经有人用它打进了真实的 Metabase 实例。
让我们把时间线摆开：
补丁发布：Metabase 官方随版本修复放出了更新；
证据收集：安全研究机构捕获到利用流量，CISA 据此评估；
进入 KEV：CVE-2026-72898 被写入目录，联邦机构的修复合入监管流程。
链路上的第三方研究各有侧重。Metabase 官方公告以「what happened」为题复盘了过程；Dataminr 的简报强调暴露面规模；CriminalIP 用攻击面测绘展示了「有多少自托管实例挂在公网上」；XanySec 则给出了利用思路的推演。综合起来，这不是一次「漏洞一公开就被打」的教科书剧情，而是「漏洞存在很久、利用门槛极低、暴露面巨大、最终被真实利用」的经典附录。
四、为什么满分评分不夸张：从一次点击到全库失守的真实路径
很多人看到 CVSS 10.0 会觉得「是不是评分虚高了」。我们拆一下评分的四个维度：攻击向量 AV 为网络（攻击者无需物理接触）；攻击复杂度 AC 为低（无需特殊条件即可稳定触发）；所需权限 PR 为无（未认证即可发起）；用户交互 UI 为无（受害者无需做任何事）。不需要对方点链接、不需要诱导某个管理员、不需要内网位置、不需要提前累积权限——只要目标暴露在外，一个请求就能开始注入。这一组取值组合出来的就是 10.0。对一个把「数据分析」当核心功能的平台来说，10.0 不是极限值，而是它应该直接拉响的警报值。
更值得警惕的是注入链路带来的连锁效应。Metabase 应用数据库一旦失守，攻击者改掉管理员口令、把 SMTP 配置换成自己的、把后端数据库连接定向到新地址——这些动作都在「正常的管理员工作流」外观下进行，传统基于签名和特征的检测看不到，因为行为本身就是合法的管理操作，只是执行者是攻击者。
五、防范与排查：别等到 KEV 里出现你的名字才动手
对 Metabase 使用者，尤其是自托管用户，修复路径很直接：
立即升级到受影响版本的补丁号（x.58.23、x.59.20、x.60.1 及以上），这是唯一彻底的解法；
缩小暴露面：不需要公网访问的实例，务必用防火墙或准入策略把 3000 端口挡在内网，别让它们成为互联网上的公开靶标；
排查入侵痕迹：对疑似被利用的实例，重点看管理员账号是否有异常变更、数据库连接配置是否被改、是否有未授权的数据导出活动；
轮换凭据：如果环境里曾存在暴露版本，建议对 Metabase 应用数据库及相关业务数据库的连接口令做一次轮换，因为你无法确定对方是否已经把口令抄走了。
从更大的视角看，CVE-2026-72898 是「受管软件遗忘死角」的又一记警钟。诸如 BI、CRM、协作这类「够用就行」的开源工具，往往因为不被安全团队重点盯防，成了真实环境里最容易被忽略的入口。Metabase 这条满分链路提醒每个团队：安全清单不应该只覆盖显得重要的服务器，还应该覆盖每一个「夹在用户和数据之间」的中间平台——因为它们常常是同一张门的钥匙。
参考：CISA KEV 目录、CVE 记录、Metabase 官方漏洞说明、GitHub Security Advisory（GHSA-vwf4-m7j8-wcjf）、CriminalIP 与 XanySec 分析。