事件概述
CISA 在 2026 年 8 月 11 日将 Metabase 的 SQL 注入漏洞 CVE-2026-72898 加入已知被利用漏洞目录。Metabase 官方在 GitHub 安全公告中确认，该漏洞属于严重级别问题，攻击者不需要登录，只要能够通过 HTTP 或 HTTPS 访问受影响的 Metabase 实例，就可能通过密码重置 API 端点向 Metabase 应用数据库注入 SQL。成功利用后，攻击者可能获得实例管理员权限，并进一步修改应用配置、查看连接数据库凭据、读取可访问的数据或导出数据。
这类漏洞之所以值得中小企业、站长和运维团队重点关注，不只是因为 CVSS 分数高，还因为 Metabase 往往连接着企业的 MySQL、PostgreSQL、数据仓库或业务报表库。很多团队把它部署在内网，也有不少为了远程办公、客户看板或临时数据分析把它放到公网。一旦入口暴露，风险就不再只是一个报表系统被登录，而是可能牵出后端数据库访问权限和敏感业务数据。
影响范围
根据 Metabase 官方安全公告和 runZero 的整理，受影响的是部分 Metabase On-Premises 版本，包括 x.63.0 至 x.63.4、x.62.0 至 x.62.8、x.61.0 至 x.61.10、x.60.0 至 x.60.16、x.59.0 至 x.59.20、x.58.0 至 x.58.23。Metabase 官方给出的修复版本分别为 x.63.5、x.62.9、x.61.11、x.60.17、x.59.21 和 x.58.24，使用对应分支的团队应升级到相应补丁版或更新版本。
如果企业使用的是容器部署、Jar 包部署或由第三方平台托管的自建实例，排查重点都是先确认实际运行版本，而不是只看安装文档或镜像名称。对通过反向代理发布到公网的实例，还要确认外部是否可以访问 Metabase 的登录页和 API 路径。即便实例只在内网开放，也不能忽视风险，因为内网钓鱼、弱口令终端、被攻陷的办公电脑或 VPN 账号都可能成为攻击跳板。
为什么风险不止是一个 SQL 注入
普通 SQL 注入常见影响是读取、修改或破坏某个应用自己的数据库；但 Metabase 的业务定位让这个漏洞更敏感。它本身保存用户、会话、配置、数据源连接信息和报表查询记录，并且通常被授予访问多个业务数据库的权限。攻击者一旦获得 Metabase 管理员权限，就可能从看板入口继续横向了解企业的数据结构、业务指标、表名字段和连接方式。
官方公告还明确提到，如果相关端点曾经公网可访问，升级之后仍应检查 API Key、管理员账号、活动会话、数据仓库日志以及 Metabase 活动和查询历史。这说明修补程序只是第一步，后续的凭据轮换和入侵排查同样重要。对依赖 BI 看板的公司来说，攻击者不一定要立刻破坏系统，只要安静导出数据，就足以造成严重损失。
排查思路
第一步是盘点所有 Metabase 实例，包括生产、测试、临时演示和历史遗留环境。很多风险不在主系统，而在某台临时云服务器、旧容器或没人维护的内网机器上。运维可以从资产管理、容器编排平台、反向代理配置、域名解析、云安全组和负载均衡配置中反查是否存在 Metabase 服务。
第二步是确认版本和暴露面。受影响版本应优先升级；公网开放的实例应提升处理优先级。没有必要在公开文章中复现漏洞请求，也不建议管理员为了验证风险去尝试攻击载荷。更稳妥的方式是以版本、官方公告和访问控制状态为依据判断是否处于风险窗口，并同步检查访问日志里是否出现异常的密码重置 API 请求、陌生来源 IP、异常管理员登录、批量导出、异常查询或新增 API Key。
修复和临时缓解
官方建议是尽快升级到对应分支的修复版本：x.63.x 升级到 x.63.5 或更高，x.62.x 升级到 x.62.9 或更高，x.61.x 升级到 x.61.11 或更高，x.60.x 升级到 x.60.17 或更高，x.59.x 升级到 x.59.21 或更高，x.58.x 升级到 x.58.24 或更高。升级前应先备份 Metabase 应用数据库和部署配置，在测试环境验证镜像、插件、数据库连接和关键看板后，再安排生产窗口发布。
如果暂时无法立即升级，Metabase 官方给出的临时缓解思路是阻断 /api/session/reset_password 端点。这个动作建议在反向代理、WAF 或网关层做精确规则，并先评估业务是否依赖相关密码重置流程。临时封堵不能替代升级，尤其在漏洞已被确认利用、并被 CISA 加入 KEV 的情况下，补丁仍应作为最终处理目标。
升级完成后，还需要做一次事后清理：撤销当前活动会话，检查并删除不认识的 API Key，核对管理员账号是否有异常新增或权限变化，轮换已连接数据库的凭据，审查数据仓库访问日志、Metabase 活动记录和查询历史。如果发现异常导出、陌生管理员账号、批量查询或来自异常 IP 的访问，应按入侵事件处理，而不是只把系统升级完就结束。
给站长和运维的额外提醒
BI、监控、CI/CD、备份、堡垒机这类“辅助系统”经常被低估，但它们往往握着更高价值的凭据和数据入口。Metabase 这次漏洞提醒我们，企业内部工具不应默认暴露到公网；确实需要远程访问时，应使用 VPN、零信任访问、IP 白名单、多因素认证和最小权限账号，并定期清理不再使用的数据源连接。
如果业务看板跑在云服务器上，建议把 Metabase、数据库和反向代理的安全组分开设计，只开放必要端口。像 速维云云服务器 这类环境承载报表或管理后台时，也应把安全组、访问日志、快照备份和数据库账号权限一起纳入日常巡检，而不是只关注 CPU、内存和带宽是否够用。
后续还要关注 Metabase 官方公告、GitHub Advisory、CISA KEV 目录和安全厂商分析是否披露新的利用细节或检测规则。当前可确认的重点很明确：受影响版本尽快升级，公网实例优先处理，升级后必须查会话、API Key、管理员账号和数据库日志。对已经暴露过的实例，凭据轮换和日志审计应和补丁同等优先。
