mongodb 7.0 未新增内存保护机制防密码泄露，cve-2025-14847漏洞存在于7.0.0–7.0.27全系列，修复仅在7.0.28中实现；明文密码驻留内存源于配置项、连接字符串及ops manager agent缓存，禁用zlib压缩可临时缓解，升级至7.0.28为唯一根治方式。
MongoDB 7.0 本身没有新增“内存保护机制”来防止密码泄露——这是个常见误解。CVE-2025-14847（MongoBleed）漏洞在 7.0.0–7.0.27 全系列中均存在，而官方修复仅在 7.0.28 中发布。所谓“新机制”并不存在，7.0.x 的防护完全依赖外部配置干预或升级。
为什么 mongod 进程内存里会存密码？
MongoDB 本身不主动“加密存储密码到内存”，但以下场景会让明文密码驻留堆内存：
-
net.tls.certificateKeyFilePassword、security.kmip.clientCertificatePassword等配置项值，在进程启动时被读入内存，且未做零填充（zero-out）处理 - 使用
mongosh或驱动连接时，若连接字符串含密码（如mongodb://user:pass@host/），该密码可能残留在进程堆或日志缓冲区 - Ops Manager Agent 启用
enableLocalConfigurationServer: true后，完整配置（含密码字段）缓存在 Agent 内存中，mongod通过本地 HTTP 请求动态拉取——此时密码始终以明文形式存在于 Agent 进程内存
禁用 Zlib 压缩是唯一有效的临时缓解手段
攻击者利用 CVE-2025-14847 不需要认证，也不需要触发业务逻辑，只要能发一个畸形压缩包即可读取堆内存。而该漏洞只在启用 Zlib 压缩时触发。
在 mongod 启动参数或配置文件中显式关闭它：
net:
compression:
compressors: [snappy, zstd] # 排除 zlib
# 或更彻底：
net:
compression:
compressors: disabled
注意：networkMessageCompressors 是旧版参数名（4.2–4.4），7.0+ 必须用 net.compression.compressors；设为 disabled 后，所有客户端必须同步禁用压缩，否则握手失败。
避免密码进入内存的实操底线
不是靠 MongoDB 自身“保护”，而是从源头掐断明文注入路径：
- 绝不在配置文件中写
net.tls.certificateKeyFilePassword—— 改用操作系统密钥环（如 Linuxsystemd的LoadCredential=）或环境变量注入，启动脚本中用${MONGODB_TLS_PASS}替换，确保密码不落地也不硬编码 - 连接时禁用 URI 中的密码：用
mongodb://user@host/+ 外部凭据提供器（如mongosh --username user --password交互输入，或驱动的authMechanismProperties指向凭证文件） - 若用 Ops Manager，不要开启
enableLocalConfigurationServer: true—— 尽管它声称“把配置放内存更安全”，但实际让密码在 Agent 进程中长期驻留，且一旦 Agent 崩溃或 Ops Manager 不可达，mongod将无法重启（见知识库“影响 MongoDB 部署的可用性”）
真正起效的只有升级到 7.0.28
补丁已修复 message_compressor_zlib.cpp 中的长度校验逻辑：不再用 output.length() 分配缓冲区，而是严格依据解压后真实长度。这是唯一根治方式。
升级前务必验证：
- 确认所有
mongos、mongod、mongoCLI、mongosh均更新，任一组件残留旧版本都可能成为入口 - 检查驱动版本兼容性（如 Node.js 的
mongodb包 v6.7+ 已适配 7.0.28 协议变更） - 禁用 Zlib 后若业务性能明显下降，说明已有客户端重度依赖压缩——升级后需重新压测，不能跳过
别信“内存加固”“运行时加密”的第三方方案，MongoDB 7.0 没有提供此类 API；任何声称能“自动清理密码内存”的 wrapper 工具，本质都是在赌 GC 行为，不可靠。
