哪吒监控面板（Nezha Monitoring）是一款开源的一体式服务器监控与运维面板，在华人 IT 圈中非常热门，因其简洁的界面设计、安装的便捷性与易用性而广为流传，相较于 Zabbix / Prometheus + Grafana 等专业 DevOps 监控工具更为亲民。与前两者不同的是，哪吒监控面板所能执行的权限非常高，它可以免密码 / 免 SSH Key 直接通过网页控制面板的后台，一键使用 root 账号登录至被控服务器的 tty，这样的设计下，一旦面板 Web 端被攻破，主控下的所有被控端服务器都能被轻松操控，后果不堪设想。
正因如此高的潜在风险，任何主控端 Web 面板的漏洞都具有极高风险。近日，编号为 CVE-2026-53519 的严重漏洞被披露。该漏洞是一个典型的预认证路径穿越（Pre-auth Path Traversal）漏洞，攻击者无需登录后台，只需发送一个精心构造的 GET 请求，即可实现对整个面板的完全接管。
1. 漏洞核心：前缀混淆与路径穿越
漏洞根源在于主控端处理前端静态资源的 fallbackToFrontend 函数中。为了方便用户访问，开发者实现了一个逻辑：如果请求的 URL 以 /dashboard 开头，则将其视为对管理后台前端资源的请求，并从本地目录读取文件返回。
漏洞版本（< 2.0.13）中相关的代码片段：
if strings.HasPrefix(c.Request.URL.Path, "/dashboard")
{
stripPath := strings.TrimPrefix(c.Request.URL.Path, "/dashboard")
localFilePath := path.Join(singleton.Conf.AdminTemplate, stripPath)
if checkLocalFileOrFs(c, frontendDist, localFilePath, http.StatusOK)
{
return
}
}这段逻辑存在一个致命的疏忽：此处使用 strings.HasPrefix 进行简单的字符串匹配，而不是基于路径段（Path Segment）进行校验。
通常情况下，如果我们尝试使用 /dashboard/../data/config.yaml 来进行路径穿越，Go 标准库的 http.ServeFile 会触发内置的安全拦截机制，直接返回 400 Bad Request。
然而，攻击者可以利用一个巧妙的技巧：将点号紧跟在前缀之后。
当请求路径为 /dashboard../data/config.yaml 时，会发生这些步骤：
- 绕过拦截：对于 Web 服务器而言，第一个路径段是 dashboard.. 而不是 dashboard。因为它不包含独立的 .. 片段，因此顺利绕过了 Go 标准库的 URL 拦截。
- 前缀匹配：strings.HasPrefix(path, “/dashboard”) 返回 true。
- 路径拼接：strings.TrimPrefix 将 /dashboard 部分去除，剩下 ../data/config.yaml。
- 最终路径：path.Join(“admin-dist”, “../data/config.yaml”) 经过规范化处理后，指向服务器根目录下的 data/config.yaml。
通过这种方式，攻击者可以绕过所有防御，直接读取主控端运行目录下的任意文件。
2. 攻击链
在此案例中，路径穿越漏洞是整个攻击链的第一环。攻击者可以通过以下步骤实现权限跃迁：
第一步：获得 JWT 密钥
通过请求 /dashboard../data/config.yaml，攻击者可以直接获取该文件的明文内容。其中包含 jwt_secret_key。这是面板用于签署会话 Token 的 HS256 对称加密密钥。
第二步：定位管理员账户
利用漏洞请求 /dashboard../data/sqlite.db 下载整个数据库文件。通过分析 SQLite 数据库中的 users 表，攻击者可以获取管理员的 user_id 以及其他标识信息。
第三步：伪造管理 Token
由于 HS256 是对称加密算法，只要拥有了 jwt_secret_key，任何人都可以自行签署合法的 JWT Token。攻击者可以使用该密钥伪造一个包含管理员 user_id 的 Token，并将其放入 Cookie (nz-jwt) 中发送给服务器。
第四步：接管面板，控制服务器
此时，主控端会认为请求者是合法且经过认证的管理员。因此，攻击者拥有了对面板的完整控制权，可以随意修改配置、添加用户，甚至利用前文提到的 root 登录功能，一键接管所有被控端服务器。
3. 修复与防御
该漏洞在 v2.0.13 版本中已得到修复。官方采取了更为严格的路径校验方案：
- 强化前缀检查：将匹配条件改为 /dashboard/（强制要求斜杠），避免 dashboard.. 这种混淆攻击。
- 引入路径清洗：在访问文件系统之前，使用 path.Clean 处理路径，并明确禁止结果中出现
..或试图跳出根目录的行为。
对于所有哪吒监控面板的用户，建议立即执行以下操作：
- 升级版本：尽快将主控端更新至 v2.0.13 或更高版本。
- 检查日志：审计 Web 日志中是否存在包含 /dashboard.. 关键字的异常请求。
- 更换密钥：如果你怀疑已被攻击，在升级后请务必修改 jwt_secret_key，因为之前的密钥一旦泄露，即使更新了代码，旧的伪造 Token 在有效期内依然可能有效。
4. 检查服务器是否被注入恶意脚本
即便及时更新或停止了面板，或者服务器的资源占用率与往常一样，仍然不能掉以轻心地认为服务器未被攻破。这里提供两种方式供大家检测。
初步检测
通过运行该脚本，能够探测服务器中是否包含常见的非 ATP 定向攻击脚本特征：
- 寻找是否存在名为 kworker 但不在 /sbin/init 下的进程，或占用 CPU 极高的随机字符串进程。
- 寻找是否有连接到已知矿池 IP 或非常规端口的外出连接。
- 寻找包含 curl … | sh 或 wget … -O- | bash 的定时任务，这是典型的后门植入方式。
- 对比已知公钥，检查是否有不明条目。
- 检查 /tmp 下是否存在具有执行权限的二进制文件。
- 查看是否后台执行了下载脚本的操作。
echo -e "\n\033[1;32m=== [VPS SECURITY CHECK REPORT] ===\033[0m"; \
echo -e "\n\033[1;34m[1. Top CPU Processes]\033[0m"; ps aux --sort=-%cpu | head -n 15; \
echo -e "\n\033[1;34m[2. Network Connections]\033[0m"; ss -tunlp || netstat -tunlp; \
echo -e "\n\033[1;34m[3. User CronJobs]\033[0m"; crontab -l 2>/dev/null || echo "No user crontab"; \
echo -e "\n\033[1;34m[4. System Crontab]\033[0m"; cat /etc/crontab 2>/dev/null; \
echo -e "\n\033[1;34m[5. SSH Authorized Keys]\033[0m"; cat ~/.ssh/authorized_keys 2>/dev/null || echo "No authorized_keys found"; \
echo -e "\n\033[1;34m[6. Suspicious Tmp Files]\033[0m"; ls -la /tmp /var/tmp | grep -v '^total' | head -n 20; \
echo -e "\n\033[1;34m[7. Recent Bash History]\033[0m"; tail -n 50 ~/.bash_history 2>/dev/null || echo "No history found"; \
echo -e "\n\033[1;32m=== [END OF REPORT] ===\033[0m"针对此次哪吒面板漏洞的定向检测
该版本收录自各大论坛热心网友的发帖，该脚本只读、只报警、不会进行删改操作。为了让全球各地的网友都能访问到这个脚本，我将其放置于本人的全球 CDN 中，直接运行下列命令即可。
需要注意的是，由于需要检测是否有被注入的 SSH Key 等操作，务必使用含 root 权限的账户运行下列脚本。
版本1:
curl -s https://global.ecdn.ltd/enblog/public_dl/20260618/nezha_inspector.sh | sudo bash版本2:
curl -s https://global.ecdn.ltd/enblog/public_dl/20260618/nezha_inspector_v2.sh | sudo bash
发表回复