MongoDB未授权访问漏洞存在，即直连成功且无密码提示：执行mongosh --host IP --port 27017后出现>提示符，并能运行show dbs列出数据库；该方式比查配置更可靠，因配置可能未生效或被运行时参数覆盖。
能直接连上且不弹密码提示，基本就是未授权访问漏洞已存在。
用 mongosh 或 mongo 命令直连测试最可靠
这是验证漏洞最贴近真实攻击链的方式，比查配置文件更直接——因为配置可能改了但没重启，或被运行时参数覆盖。
- 在任意可访问目标的机器上执行：
mongosh --host 172.20.0.100 --port 27017（替换为实际 IP） - 如果终端立刻返回
>提示符，且能直接输入show dbs并列出数据库，说明漏洞确认存在 - 注意：新版 MongoDB 已弃用
mongoshell，推荐用mongosh；若提示 command not found，需先安装官方 CLI 工具 - 某些环境会因 TLS/SSL 配置失败而报错，此时加
--tlsAllowInvalidCertificates再试，避免误判
用 nmap 扫描端口 + 脚本检测快速批量筛查
nmap 自带的 mongodb-info 脚本能主动探测认证状态，适合对大量资产做初筛，但依赖服务响应指纹，不如直连准确。
- 执行：
nmap -p 27017 --script mongodb-info 172.20.0.100 - 关键判断依据是输出中是否出现
Authentication disabled或auth: false - 若脚本报错或超时，不代表安全——可能是防火墙拦截了探测包，仍需人工直连验证
- 该脚本对 MongoDB 4.4+ 版本支持较好，但对启用了
net.bindIp但未开 auth 的实例，有时会漏报
检查 mongod.conf 配置项是否真生效
光看配置文件内容不等于漏洞不存在——常见陷阱是改了配置但没重启服务，或被命令行参数覆盖。
- 登录服务器后，先确认配置路径：
ps aux | grep mongod，找--config参数指向的文件（常见为/etc/mongod.conf） - 重点检查两处：
net.bindIp是否为0.0.0.0（暴露风险），security.authorization是否为enabled - 即使配置里写了
authorization: enabled，也要执行sudo systemctl status mongod看最近重启时间，确认改动已加载 - 特别注意：MongoDB 3.0 以前版本，即使开了 auth，从
127.0.0.1连接仍可绕过认证——必须结合直连测试验证
别忽略本地回环接口的“伪安全”假象
很多运维以为只绑 127.0.0.1 就绝对安全，但容器、云主机或开发环境里，这个“本地”可能等同于整个内网段。
- 在 Docker 容器中，
bindIp: 127.0.0.1对宿主机或其他容器无效，实际仍可通过容器 IP 访问 - 云平台（如 AWS EC2）若安全组放通了 27017，即使 bindIp 是
127.0.0.1，只要应用和 DB 在同一台机器，攻击者拿下 Web 服务后就能本地直连 - 真正安全的组合是：bindIp 限定内网 IP + firewall 限制源 IP + authorization 启用 —— 三者缺一不可
