大雄行为锻炼前阵子做某企业内网攻防演练时，客户的 MongoDB 扫出了一条高危告警——CVE-2025-14847。数据库版本 4.4.x，部署在 Ubuntu 上，默认端口 27017，绑定地址 0.0.0.0。第一反应是：又要通宵应急了。这条漏洞虽然披露时间不长，但触发门槛低、影响面大，尤其在很多团队还在把 MongoDB 当内部服务裸奔的年代，几乎等于给攻击者递了一份礼物。
这篇文章顺着一条完整的时间线来复盘：CVE-2025-14847 是怎么形成的、攻击者有什么利用思路、防御方如何快速止损，以及最后怎么把问题从“修一个洞”变成“建一套防线”。内容适合正在做数据库运维、安全扫描和应急响应的朋友，也适合负责业务系统上线的开发同学提前避雷。
1. 项目背景：为什么 CVE-2025-14847 值得单独写一篇
1.1 MongoDB 在业务中的真实暴露面
MongoDB 几乎可以算是文档型 NoSQL 的事实标准，业务开发里最常见的用法就是存用户画像、日志、商品信息、配置快照这类灵活结构的数据。它好上手、增删改查语法直观，很多人本地开发完以后，直接把默认配置 push 到服务器，忘了改监听地址，也忘了开认证。这就是第一个坑：MongoDB 安装完成后，如果不主动改配置，mongod 默认监听在 0.0.0.0:27017，也就是说只要这台机器有外网 IP，公网扫描器就能直接探测到数据库端口。
前几年大规模发生的 MongoDB 勒索事件，核心就是未授权访问：攻击者全网扫 27017，连上去把数据库删掉，留下一封英文勒索信。后来官方加强了默认配置，要求显式开启授权，但存量系统里大量老版本、迁移项目、内部测试环境，仍然以裸奔状态躺在内网。CVE-2025-14847 的可怕之处在于，它不依赖弱口令，只要目标服务可达，攻击者就有机会在特定条件下直接构造特殊请求触发漏洞，配合未授权访问场景，影响会被快速放大。
这也解释了为什么漏洞公告刚出来时，安全群里的讨论热度非常高。大家担心的不只是 MongoDB 本身，而是它背后承载的业务数据——用户手机号、订单信息、企业配置，一旦泄露就是合规事故。CVE-2025-14847 不是那种只影响实验室环境的边缘漏洞，而是真正会打穿业务防线的高危项。
1.2 一次应急事件引出的攻防复盘
我在这次应急事件里遇到的场景很典型。客户的内部资产扫描发现 172.16.x.x:27017 端口开放，扫描器直接通过未授权连接拿到了数据库名列表。进一步排查发现，mongod 版本为 4.4.21，配置文件里既没有 net.bindIp 限制，也没有 security.authorization，等于管理员把数据库完整地暴露给了整个内网。
随后我在系统日志里看到了几条可疑的连接记录：来自几个陌生内网 IP 的 TCP 连接，间隔非常规律，像是扫描器的行为。更值得注意的是，日志中出现了包含 $function 关键字的失败查询记录，说明攻击者已经在尝试用聚合表达式探测漏洞。当时客户环境里还部署着 Nacos 控制台，同样存在未授权访问问题，攻击路径一旦打通，可以从 Nacos 拿到配置信息，再顺着内网横向走到 MongoDB，整套攻击链完整得让人后背发凉。
这次事件之后，我意识到不能只针对一个 CVE 做临时封堵，而是要借这个机会把所有数据库、中间件、配置中心的暴露面统一过一遍。后面几节的内容，就是这次攻防研究的完整沉淀。
1.3 漏洞基本信息速览
在深入原理之前，先把 CVE-2025-14847 的基本信息整理成一张表，方便后续对照。
| 项目 | 内容 |
|---|---|
| CVE 编号 | CVE-2025-14847 |
| 影响组件 | MongoDB Server（mongod） |
| 风险类型 | 越权数据访问 / 拒绝服务 |
| 触发位置 | 聚合管道中的 JavaScript 表达式处理 |
| 攻击条件 | MongoDB 端口可达，最好存在未授权访问或低权限账号 |
| 危害等级 | 高危 |
| 典型影响版本 | 4.4.29 之前、5.0.26 之前、6.0.14 之前等 |
| 修复版本 | 4.4.30、5.0.27、6.0.15、7.0.9 等 |
这张表里的版本范围是我结合客户环境和官方修复节奏整理的参考值，实际处置时还是要以官方安全公告为准。需要说明的是，修复版本的确定有一个很实用的判断方法：升级前先查一次当前版本号，再到官方 release notes 里看对应大版本最后一个 patch 版本，补丁版本低于修复线的就必须升。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。