阅读前置说明本文不堆砌官方漏洞公告话术全程以红蓝对抗实战视角落地。针对CVE-2026-72898全网在野0day攻击拆解漏洞底层成因、完整攻击链路、临时止血方案、深度溯源方法、全维度加固策略。所有脚本、配置、排查指令均线上实战验证可直接复制用于企业应急响应。全文规避模板化表述所有处置逻辑基于漏洞本质推导无冗余空话。漏洞核心定位CVE-2026-72898是Metabase史上危害等级最高的漏洞之一CVSS满分10.0。漏洞核心缺陷为未授权接口存在参数可控SQL注入攻击者无需任何账号权限无需绕过登录公网触达即可直接注入数据库语句窃取Metabase元数据、管理员会话、全量数据源凭证最终接管整个BI平台横向入侵所有关联业务数据库。目前全网已出现批量扫描器、公开POC、自动化攻击脚本中小厂、互联网企业暴露资产被攻陷比例极高。一、漏洞底层原理第一性原理拆解拒绝表层科普绝大多数运维、安全人员处置漏洞只做升级补丁完全不清楚漏洞根源导致后续同类漏洞依旧无法规避。我直接从代码逻辑层面讲透为什么这个漏洞可以做到零权限、全自动、一键接管。Metabase作为开源BI数据分析平台核心架构分为两层前端业务接口层、后端元数据库层。所有用户配置、管理员账号、登录会话、数据源账号密码、数据库连接密钥全部加密/明文存储在Metabase自带的元数据库中默认PostgreSQL部分自建部署使用MySQL。本次漏洞触发点为/api/session/reset_password密码重置接口。官方设计逻辑中该接口本应校验用户邮箱、验证码、会话权限仅允许已认证用户发起密码重置请求。但开发阶段权限校验逻辑缺失接口完全对外开放未做任何身份认证、参数过滤。更致命的核心缺陷接口接收的email参数直接拼接至后端SQL查询语句中无预编译、无转义、无过滤。攻击者可控的恶意参数可以直接落地执行SQL语句查询、修改、删除元数据库核心数据。市面上多数SQL注入漏洞仅能查询普通数据危害有限。该漏洞的毁灭性在于两点第一注入点直接对接Metabase核心元数据库所有业务数据源凭证全部存储于此第二注入后可伪造合法管理员会话直接登陆后台实现持久化控制而非单次数据查询。攻击者利用链路非常清晰恶意构造email参数注入SQL → 查询超级管理员账号信息 → 伪造合法会话Session → 调用前台用户信息接口校验会话有效性 → 成功获取管理员权限 → 导出所有数据源配置 → 横向入侵MySQL、PG、数仓等核心业务库。1.1 漏洞影响范围精准锁定不模糊描述版本范围直接给出可落地的判定标准企业可一键自查受影响开源版本0.58.0 ~ 0.63.4 全版本受影响企业版本1.58.0 ~ 1.63.4 全版本安全修复版本0.58.24、0.59.21、0.60.17、0.61.11、0.62.9、0.63.5企业版版本号与开源版一致豁免资产Metabase Cloud官方云托管实例官方已统一修复无需用户操作仅自托管服务器、Docker、K8s部署的实例存在风险。1.2 对抗式风险判定为什么必须紧急处置站在攻击者视角该漏洞具备绝佳的批量入侵价值这也是目前在野攻击爆发的核心原因。第一无门槛。无需注册、无需登录、无需任何交互单一POST请求即可触发适配全网批量扫描工具黑客可批量探测公网Metabase资产。第二收益极高。一次利用即可获取企业所有业务数据库的连接账号密码涵盖用户库、订单库、财务库、数据仓库等核心资产直接造成大规模数据泄露。第三隐蔽性强。攻击者可伪造会话、新增隐藏管理员、植入持久化API密钥常规后台巡检无法发现异常失陷后可长期潜伏。第四工具化成熟。目前公开POC、批量扫描脚本、自动化接管工具已全网传播黑产7×24小时扫描公网资产暴露即被探测。二、整体攻击与应急处置架构流程图为方便大家直观理解攻击链路和处置对应关系我梳理了完整的攻防链路架构图所有应急动作均精准对应攻击节点。攻击者公网边界Metabase服务Metabase元数据库下游业务数据库安全运维人员批量扫描公网Metabase资产放行恶意POST请求调用reset_password接口注入恶意参数执行恶意SQL语句返回管理员账号、会话、凭证数据伪造会话登录后台窃取下游数据库凭证横向入侵、导出核心数据WAF/网关拦截漏洞接口升级安全版本、修复漏洞清理恶意会话、非法账号全量轮换数据库凭证、收紧权限加固网络边界、开启持续监控攻击者公网边界Metabase服务Metabase元数据库下游业务数据库安全运维人员三、企业资产快速自查方案0-10分钟落地应急响应第一优先级不是修复是快速判定资产是否暴露、是否存在被攻击痕迹。我提供两套无门槛自查方案适配不懂代码的运维和专业安全人员。3.1 版本快速检测脚本Linux服务器一键执行适配Docker、Jar包、服务器原生部署所有场景自动识别版本、判定是否高危。#!/bin/bash# Metabase CVE-2026-72898 漏洞自查脚本echo Metabase漏洞版本检测开始 # 检测Docker部署版本docker_ps$(dockerps|grepmetabase)if[-n$docker_ps];thenecho检测到Docker部署Metabase正在获取版本...docker_version$(dockerexec$(dockerps|grepmetabase|awk{print $1})java-jar/app/metabase.jar version2/dev/null)echo当前Docker版本$docker_versionfi# 检测Jar包部署版本jar_process$(ps-ef|grepmetabase.jar|grep-vgrep)if[-n$jar_process];thenecho检测到Jar包部署Metabase正在获取版本...jar_version$(java-jar$(echo $jar_process|awk{print $NF})version2/dev/null)echo当前Jar包版本$jar_versionfi# 漏洞风险判定check_vuln(){ver$1if[[-z$ver]];thenecho无法识别版本请手动核查returnfi# 匹配受影响版本区间if[[$ver~^0\.5[89]|^0\.6[0-3]]];thenif[[$ver!0.58.24$ver!0.59.21$ver!0.60.17$ver!0.61.11$ver!0.62.9$ver!0.63.5]];thenecho-e\033[31m【高危】当前版本存在SQL注入漏洞可被在野利用\033[0melseecho-e\033[32m【安全】当前版本已修复漏洞\033[0mfielseecho-e\033[32m【安全】当前版本不在漏洞影响范围\033[0mfi}check_vuln$docker_versioncheck_vuln$jar_versionecho 版本检测结束 echo开始检测公网暴露状态...# 检测端口暴露ss-tulpn|grep-E3000|metabaseecho若3000端口对公网开放且版本高危必须立即止血修复3.2 攻击痕迹快速筛查脚本日志级排查该脚本专门匹配在野攻击的特征流量精准识别是否有攻击者尝试利用漏洞适配Nginx、Caddy、原生端口访问日志。#!/bin/bash# Metabase在野攻击痕迹筛查脚本LOG_PATH./access.logecho 攻击痕迹筛查开始 echo筛查日志路径$LOG_PATH# 1. 筛查漏洞接口恶意POST请求echo-e\n1. 漏洞接口访问记录grep-iPOST /api/session/reset_password$LOG_PATH# 2. 筛查完整攻击链路核心指纹注入后校验会话echo-e\n2. 完整攻击利用指纹记录grep-B2-A2POST /api/session/reset_password$LOG_PATH|grepGET /api/user/current# 3. 筛查异常高频访问、畸形请求echo-e\n3. 异常高频扫描IP统计grepreset_password$LOG_PATH|awk{print $1}|sort|uniq-c|sort-nrecho-e\n 筛查结束 echo出现上述记录即代表资产被探测/攻击需立即溯源处置3.3 资产暴露人工核查要点自动化脚本无法覆盖所有场景补充人工核查核心项。第一确认3000默认端口是否对公网放行很多企业仅映射端口未做域名隐藏。第二确认WAF、防火墙是否拦截/api/session/reset_password接口。第三确认实例是否存在内网穿透、临时端口映射的情况内网暴露同样可以被横向攻击者利用。四、0-2小时紧急止血处置最高优先级失陷/未失陷通用很多团队应急犯错的核心问题直接升级补丁跳过止血步骤。正在被扫描、被攻击的资产升级补丁的几分钟窗口期依旧会被攻陷。所有高危资产必须先止血、再修复、再排查。4.1 网络层临时阻断1分钟落地零业务影响该漏洞唯一攻击入口就是/api/session/reset_passwordPOST接口直接全网拦截该接口即可100%阻断攻击无需下线服务、无需停机。Nginx拦截配置生产环境直接写入配置文件reload生效# Metabase漏洞临时防护规则 location /api/session/reset_password { deny all; return 403; } # 禁止所有未授权恶意参数请求 if ($request_method POST) { if ($request_uri ~* /api/session/reset_password) { return 403; } }Cloudflare/阿里云WAF/腾讯云WAF防护规则自定义URL拦截匹配路径/api/session/reset_password拦截所有POST请求规则优先级调至最高。注意事项该规则会临时禁用密码重置功能属于可接受的临时牺牲漏洞修复升级完成后立即删除规则恢复业务。4.2 高危资产隔离策略公网直接暴露且无法立即修复的资产直接通过防火墙封禁0.0.0.0/0访问仅保留企业办公出口IP、运维白名单IP访问。杜绝全网扫描器探测攻击。内网Metabase资产无需网络阻断但需要立刻排查日志内网攻击者可利用该漏洞横向渗透核心数据库风险同样极高。4.3 紧急版本升级根治漏洞唯一方式临时拦截仅为过渡手段无法长期防护必须升级至官方安全版本。不同部署环境升级方案如下Docker部署停止旧容器拉取对应分支安全TAG禁止使用latest模糊标签避免版本不固定。# 示例升级0.63系列安全版本dockerpull metabase/metabase:v0.63.5dockerstop metabasedockerrmmetabase# 重新启动容器保留原有挂载数据卷dockerrun-d-p3000:3000-v/metabase-data:/metabase-data--namemetabase metabase/metabase:v0.63.5Jar包部署停止Java进程替换官方安全版本jar包重启服务重启前备份元数据库防止升级报错数据丢失。K8s部署修改镜像TAG为安全版本滚动更新Pod更新后核查版本号确保无旧版本Pod残留。4.4 失陷资产紧急取证保全只要资产版本高危、公网暴露无论是否查到攻击痕迹一律按疑似失陷处理保全证据。攻击者的恶意操作可以做到无日志残留不能依靠日志判定是否被入侵。第一打包保全所有访问日志、应用日志、Nginx日志、审计日志禁止清空、覆盖日志。第二对Metabase元数据库做全量快照备份。第三冻结所有管理员账号权限变更、数据源配置变更操作禁止人工修改配置覆盖攻击痕迹。五、深度溯源排查2-12小时全维度取证对抗式排查常规排查只看后台登录日志极其片面。我从攻击者最终控制目标出发拆解全套排查流程覆盖会话、账号、密钥、数据源、下游数据库、主机六层维度彻底排查潜伏后门。5.1 元数据库核心数据排查最关键溯源步骤所有攻击落地结果都会留存于元数据库直接执行以下SQL排查所有后门痕迹连接Metabase对应的PostgreSQL/MySQL元数据库执行。-- 1. 排查所有登录会话陌生会话为攻击者持久化后门SELECTid,user_id,session_id,created_at,updated_atFROMcore_sessionORDERBYcreated_atDESC;-- 2. 排查所有超级管理员账号检测新增、篡改后门账号SELECTid,email,first_name,last_name,is_superuser,active,created_atFROMcore_userWHEREis_superusertrueORDERBYcreated_atDESC;-- 3. 排查所有API密钥攻击者常植入永久API后门SELECTid,name,key,creator_id,created_atFROMapi_keyORDERBYcreated_atDESC;-- 4. 排查所有数据源配置检测是否被篡改、窃取SELECTid,name,engine,details,creator_idFROMmetabase_databaseORDERBYcreated_atDESC;-- 5. 排查后台操作日志检测批量导出、数据查询、配置修改SELECTid,user_id,action,model,created_atFROMaudit_logORDERBYcreated_atDESCLIMIT100;5.2 后台业务行为排查登录Metabase后台逐项核查异常行为。检查用户管理列表确认无陌生账号、无匿名管理员账号。检查数据源配置核对所有数据库连接地址、账号、密码是否被篡改。检查任务中心查看是否存在批量数据导出、定时报表订阅、异常同步任务。检查系统配置核查SMTP邮件配置、LDAP登录配置是否被恶意修改防止攻击者劫持通知链路。5.3 下游业务数据库溯源排查该漏洞最大危害不是沦陷BI平台是下游所有业务数据库凭证泄露。攻击者获取数据源凭证后会直接登录业务库拖库、删库、篡改数据。逐项核查关联的MySQL、PostgreSQL、Oracle、数据仓库查看数据库登录日志筛查陌生IP、非常规运维IP登录记录。查询全表批量查询、批量导出、delete、truncate等高风险操作记录。核查数据库账号权限是否存在新增陌生账号、权限提升行为。核查数据变更记录确认核心业务数据无泄露、篡改、删除。5.4 服务器/容器主机层排查部分攻击者会利用Metabase服务权限植入主机后门需要排查主机层风险。查看服务器外联连接检测陌生IP外联、反向shell连接。排查定时任务、开机自启脚本确认无恶意持久化任务。排查容器进程检测异常恶意进程、逃逸行为。核查服务器日志筛查异常登录、文件篡改记录。六、失陷后全面清理与凭证轮换必须100%执行这里纠正全网90%团队的错误认知升级补丁不代表风险解除。补丁只能堵住漏洞入口无法回收攻击者已经窃取的数据库凭证、会话密钥、API密钥。只要漏洞暴露过所有凭证必须全量轮换。6.1 强制清理所有恶意会话清空所有历史会话踢除攻击者所有持久化登录权限所有用户强制重新登录。-- 清空所有会话彻底清除攻击者后门会话TRUNCATETABLEcore_session;6.2 账号体系清理重置删除所有排查发现的陌生管理员、普通用户账号。重置所有超级管理员账号密码启用强密码策略字母数字特殊符号长度16位以上。清理所有无效、陌生API密钥所有业务在用API密钥全部重新生成、替换业务配置。关闭匿名访问、游客权限禁止未授权用户查看数据。6.3 全量数据源凭证轮换核心保命操作逐项轮换所有被Metabase关联的数据源账号密码无例外。MySQL、PostgreSQL、Oracle业务数据库账号密码全量重置。数据仓库、大数据平台、缓存服务连接密钥重置。LDAP、SMTP、云服务AK/SK、第三方接口令牌全部轮换。凭证轮换后同步收紧数据库权限遵循最小权限原则。Metabase专用数据库账号仅授予查询、只读权限禁止授予删除、修改、建表、超级管理员权限。数据库白名单仅放行Metabase固定业务IP拒绝所有陌生IP访问。6.4 业务风险评估与上报完成清理后评估数据泄露范围。确认是否存在用户隐私数据、订单数据、财务数据泄露。评估是否需要合规上报、用户告知。记录所有失陷时间窗口、攻击行为、处置动作留存合规证据。七、长期永久加固方案杜绝同类漏洞复现应急处置完成后必须落地常态化加固避免后续新漏洞、同类漏洞再次被攻陷。所有加固方案贴合企业生产环境无无效摆设配置。7.1 网络架构加固彻底禁止Metabase公网直接暴露这是最核心的加固手段。所有外部访问必须通过VPN、ZTNA零信任网关、企业办公白名单IP转发。关闭服务器3000端口公网监听仅内网IP监听。防火墙、WAF永久保留漏洞接口监控规则持续拦截异常扫描、攻击流量。7.2 权限体系加固拆分管理员权限区分超级管理员、普通运维、查看用户禁止全员超级权限。所有数据源账号严格最小权限杜绝高权限账号对接BI平台。定期清理冗余用户、冗余API密钥、冗余数据源配置每月迭代清理一次。开启账号登录异地告警、异常IP登录告警、高频操作告警。7.3 日志与监控体系加固将Metabase访问日志、审计日志、元数据库日志统一接入SIEM日志平台。配置核心告警规则/api/session/reset_password接口任意访问告警、新增超级管理员账号告警、批量数据导出操作告警、陌生IP管理员登录告警、数据源配置修改告警。建立版本巡检机制每月自动核查Metabase版本同步官方安全公告提前修复高危漏洞。7.4 迭代运维规范加固禁止使用latest、stable等模糊镜像标签部署生产服务所有服务固定安全版本TAG。生产环境禁止开启调试模式、匿名访问、测试接口。所有配置变更、账号新增、权限变更执行双人复核制度留存操作日志。定期开展红蓝对抗自查模拟漏洞利用攻击检验防护体系有效性。八、企业分级处置标准适配不同风险资产为适配不同企业资产状态我划分三级风险等级对应不同处置力度避免过度处置或处置不足。8.1 一级风险已确认失陷特征日志捕获完整攻击链路、存在陌生管理员/会话/API密钥、出现异常数据导出行为。处置要求立即隔离资产、全量取证、清空后门、100%轮换所有凭证、全维度溯源、输出正式应急报告、复盘整改。8.2 二级风险高危暴露未失陷特征版本高危、公网暴露、无明确攻击痕迹。处置要求立即网络拦截、升级安全版本、全量排查后门、轮换核心凭证、开启持续监控、加固网络边界。8.3 三级风险内网隔离资产特征版本高危、仅内网访问、无公网暴露、边界严格管控。处置要求限期升级补丁、内网安全扫描排查、收紧内网访问权限无需全量凭证轮换。九、常见应急误区复盘实战踩坑总结我整理了全网企业处置该漏洞的高频错误帮大家规避风险避免二次沦陷。误区一只升级补丁不轮换凭证。攻击者已窃取的数据库凭证不会随补丁失效依旧可以横向入侵业务系统。误区二仅看后台登录日志不查元数据库。攻击者可伪造合法会话后台日志无异常记录仅靠前台日志无法发现后门。误区三内网资产放松警惕。内网横向渗透中该漏洞是高频利用入口沦陷后可批量控制内网数据库资产。误区四长期使用WAF拦截替代补丁修复。临时拦截规则存在绕过风险只能作为过渡方案不能永久防护。误区五不做证据保全直接修复。失陷后直接修复会覆盖攻击痕迹无法溯源攻击链路、评估泄露范围。互动提问欢迎评论交流1、你们企业的Metabase资产是否存在公网暴露、未及时升级补丁的情况落地本次加固方案时遇到了哪些适配问题2、除了本文的排查脚本和加固策略你在实战应急中还用到了哪些高效溯源、止血的技巧