2026年8月——开源商业智能工具Metabase的密码重置接口被披露存在一处CVSS满分（10.0）的未认证SQL注入漏洞（CVE-2026-72898）。CISA已于8月11日将其列入已知被利用漏洞（KEV）目录并确认在野利用，要求联邦机构在8月14日前完成修复。该漏洞已造成实际数据泄露：工作流自动化平台n8n、AI编程工具厂商Kilo Code以及Framework、Anaconda等多家Metabase云租户先后披露客户数据遭访问。
漏洞技术细节
漏洞存在于Metabase的密码重置流程中。该流程接受一个发往/api/session/reset_password端点的POST请求，包含重置令牌与新密码。出于功能设计，该端点天然无需认证——密码重置本就服务于被锁在门外的用户。
问题出在请求到达服务器后的处理环节。Bishop Fox的分析将根因归结为重置令牌处理中的特殊字符净化不当（CWE-89）：来自未认证请求的数值未经妥善净化，便流入针对Metabase自身应用数据库的SQL查询。技术层面，该漏洞由Clojure的映射合并语义、JSON键名关键字化处理与HoneySQL的:raw逃生舱三者叠加造成，使攻击者的输入直接拼接进SQL语句。
攻击者不需要有效令牌、有效邮箱或任何既有账户，单个精心构造的请求即可注入任意SQL：直接改写数据库记录，包括决定“谁是管理员”的表——本该帮用户找回访问权的端点，成了把钥匙交给陌生人的端点。
为何影响远超一个“报表工具”
Metabase通常并非孤立部署，而是直连企业真实数据：生产Postgres、数据仓库，甚至多个客户数据库。这些连接串（常含活凭证）就存储在Metabase应用数据库内。
通过该漏洞取得管理员权限的攻击者能做的远不止篡改一张图表：读取全部已存储的连接串、导出所有已连接数据源暴露的数据集，甚至悄悄将自己添加为永久管理员——使事后修补SQL注入也无法移除其访问权。工具的爆炸半径由它连接了什么决定，而非由它看起来是干什么的决定。
“未认证”这一属性也在推高严重性：没有钓鱼步骤、无需先窃取凭证、没有社工环节，任何能在网络上触达Metabase实例的人，当天就能实施攻击。
受害企业与泄露情况
多家Metabase云租户已披露在补丁窗口期前的数据访问事件：
- n8n：攻击者获取了136条客户记录，包括用户名、邮箱、5条bcrypt哈希密码；另有25个云账户因一个已于2023年4月修复的历史漏洞以明文存储密码，n8n已出于预防目的联系相关用户，尚无实际被访问的证据；
- Kilo Code：部分用户的客户记录与Slackbot令牌暴露，泄露窗口约为8月2日的4小时；
- Framework与Anaconda亦披露了客户数据遭未授权访问。
安全研究人员还注意到攻击者在ShinyHunters泄露站上的挂名，但该归属尚未获证实。各受害企业均已采取缓解措施：轮换受影响凭证与API密钥、重置用户密码、吊销Slackbot令牌、删除入侵管理员账户。
影响版本与修复
漏洞影响0.58/1.58至0.63.4/1.63.4之间的全部版本（开源版与企业版同受影响），每条受影响分支均有同主版本的修复版，升级无需跨大版本：
- 0.58 / 1.58分支：0.58.24 / 1.58.24
- 0.59 / 1.59分支：0.59.21 / 1.59.21
- 0.60 / 1.60分支：0.60.17 / 1.60.17
- 0.61 / 1.61分支：0.61.11 / 1.61.11
- 0.62 / 1.62分支：0.62.9 / 1.62.9
- 0.63 / 1.63分支：0.63.5 / 1.63.5
除版本升级外，还应审计现有管理员账户（无法说明创建来历的按可疑处理），并在实例曾有互联网暴露的情况下轮换全部已连接数据源的凭证。需要强调：升级只封堵新攻击，不会清除攻击者已获得的管理员权限——疑似补丁前被入侵的实例应按完整安全事件处置。
事件启示
密码重置与账户找回流程持续成为“其他方面安全做得不错”的应用的软肋，原因正在于它们必须为尚未认证的用户服务。这一设计约束意味着更少的环节能被登录校验拦截、更多请求内容必须依赖手工验证——而一旦验证漏掉一种情况，缺陷就绕过了应用其余部分赖以运作的全部访问控制。
任何带未认证找回流程的内部工具——无论是Metabase、自研管理面板还是商业产品——都应把这类端点列入下一轮安全评审，而非默认“只是个密码重置接口，风险不大”。