哪吒监控安全事件 - 从中招到复盘

这几天 VPS 圈子里，哪吒监控（Nezha）基本被刷屏了。

有人说 CPU 被打满，有人发现机器里多了陌生 SSH 公钥，有人被云厂商发 abuse，还有人发现自己的小鸡被拿去挖矿、做代理、打流量。NodeSeek 上更直观，列表里隔几条就是一个哪吒相关帖子：求助、复盘、检测脚本、清理脚本、替代方案，什么都有。

我一开始也以为这只是“面板密码太弱”或者“SSH 被爆破”。后来越查越觉得不对。很多机器并没有对应时间段的 SSH 成功登录记录，但后门却几乎同时落地。这个现象很说明问题：攻击者很可能不是一台一台登录，而是先拿到了哪吒 Dashboard，然后通过 Agent 批量下发命令。

换句话说，平时的“集中管理”，出事时就变成了“集中沦陷”。

这篇简单记一下这次事件。不会写太深的漏洞分析，主要讲清楚几件事：为什么哪吒不是普通探针，漏洞大概怎么串起来，社区里看到了哪些中招痕迹，以及现在还在用的人该先做什么。

哪吒不是只读探针

很多人装哪吒，是为了看一个漂亮的服务器状态页。CPU、内存、流量、在线状态，一屏看完，确实舒服。

但哪吒不是只读工具。Dashboard 和 Agent 之间有控制通道，面板里能做不少运维动作：

• Web 终端
• 文件管理
• 计划任务
• 批量命令执行
• Agent 更新和配置下发

这些功能平时很方便。问题是，权限也很重。

如果 Dashboard 被接管，攻击者拿到的不是“看看监控”的权限，而是“让所有在线 Agent 执行命令”的权限。Agent 又通常是 root 跑的，所以面板里下发的一条命令，到了机器上可能就是 root 权限执行。

这也是这次事件影响范围容易扩大的原因。

公开漏洞

这次不是只有社区传言。哪吒官方已经有两个相关的 GitHub Security Advisory。

第一个是 GHSA-5c25-7vpj-9mqh：
https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh

这个漏洞影响 < 2.0.13。问题出在 Dashboard 的前端 fallback 路由处理上。旧版本判断 /dashboard 路径时不够严，攻击者可以构造类似这样的请求：

/dashboard../data/config.yaml

默认部署下，这可能读到 data/config.yaml。里面有 jwt_secret_key、agent_secret_key 这些敏感配置。

其中 jwt_secret_key 特别危险。旧版本里，攻击者拿到它之后，就可能自己签一个合法的 Dashboard 登录态。也就是说，强密码还在，但密码这关已经被绕过去了。

第二个是 GHSA-99gv-2m7h-3hh9：
https://github.com/nezhahq/nezha/security/advisories/GHSA-99gv-2m7h-3hh9

这个漏洞影响 >= 1.4.0, < 2.0.8。它和计划任务权限有关。低权限用户可能通过计划任务接口创建命令，并广播到所有服务器。Agent 收到后会执行，于是就变成了跨主机的远程命令执行。

把这两件事放在一起，大概链路就是：

Dashboard 暴露公网
-> 读取配置文件
-> 拿到 JWT 密钥
-> 伪造登录态
-> 进入 Dashboard
-> 创建恶意计划任务
-> 所有在线 Agent 执行命令

所以很多人看到的是“所有机器一起出事”。这不是巧合。一个 Dashboard 后面挂了多少 Agent，攻击者就可能一次打到多少台。

时间线

这次比较容易让人误解的一点是：漏洞不是今天才修，但爆发却集中在这几天。

按公开资料和社区反馈，大概是这样：

• 2026-05-17：官方发布 GHSA-99gv-2m7h-3hh9，计划任务权限问题被披露，修复版本是 2.0.8。
• 2026-05-31：官方发布 GHSA-5c25-7vpj-9mqh，路径穿越问题被披露，修复版本是 2.0.13。
• 2026-06 上旬：社区里已经有人反馈异常 Agent、异常任务、陌生 SSH 公钥。
• 2026-06 中下旬：更多 VPS 用户开始集中发现 CPU 异常、挖矿、流量代理、随机后缀 Agent 服务。
• 2026-06-20 前后：哪吒主控最新版本已经到 v2.2.6，Agent 最新是 v2.2.2。

这说明修复版本早就有了，但暴露在公网的旧面板并不会自动消失。攻击者可能早就扫过一轮，真正变现的时候，大家才看到 CPU 和流量异常。

“养鱼”和“收网”这种说法听起来很戏剧化，我不想把它写成定论。能确认的是：漏洞公开存在，修复版本已经发布，社区里确实出现了批量中招。

为什么 SSH 强密码和 UFW 没挡住

很多人第一反应是：我 SSH 密码很强，甚至只开了密钥登录，为什么还会中？

因为攻击可能根本没走 SSH。

如果攻击者控制的是 Dashboard，那被控机器只要能主动连上 Dashboard 就行。UFW 通常拦的是入站连接，而 Agent 连 Dashboard 是出站连接。

也就是说，攻击路径更像这样：

攻击者 -> Dashboard -> Agent -> 服务器本机执行命令

而不是：

攻击者 -> SSH 登录每台服务器

所以 SSH 强密码、改端口、禁密码登录，这些都很重要，但它们防的是 SSH 这条路。这次的问题大概率是从控制面进来的。

社区里看到的中招痕迹

不同人机器上的载荷不完全一样。下面这些是社区复盘里反复出现的现象，适合拿来做排查方向，但不要当成完整 IOC。

有人从中招的 SQLite 数据库里提取到过恶意计划任务，内容包括：

写入 /root/.ssh/authorized_keys
curl / wget 下载远程脚本并执行
拉取挖矿或代理变现程序

也有人发现机器上多了随机后缀的哪吒服务：

nezha-agent-xxxxxxx.service
nazha-agent-xxxxxxx.service

对应的配置文件可能长这样：

/opt/nezha/agent/config-xxxxx.yml

这种做法会增加清理难度。只停掉原本的 nezha-agent.service 不够，随机后缀的服务可能还在运行。

还有一些机器出现了挖矿和流量套利程序，比如 XMRig、c3pool，或者一些代理/带宽变现容器。这类东西不一定马上把业务搞挂，但会悄悄吃 CPU、带宽和云厂商信用。

更麻烦的是内存驻留进程。有些复盘提到伪装成 kworker 的用户态进程、memfd 内存马、执行路径显示为 (deleted) 的进程。查文件不一定能看到，得看 /proc、进程树和网络连接。

我觉得比较实用的排查顺序是：

1. 查 Nezha 计划任务和 Dashboard 数据库
2. 查 systemd 服务，尤其是随机后缀服务
3. 查 crontab 和 /etc/cron*
4. 查 authorized_keys 是否多出陌生公钥
5. 查高 CPU 进程、挖矿进程和代理程序
6. 查 /tmp、/dev/shm、/opt、/root 下近期新增文件
7. 查 memfd、deleted exe、伪装 kworker 进程
8. 查 Docker 容器和镜像

一键清理脚本可以止血，但不能证明系统已经可信。机器被 root 权限控制过之后，更稳妥的处理方式仍然是重装系统，然后轮换所有可能泄露的凭据。

现在该做什么

如果你用过受影响版本，或者 Dashboard 曾经暴露在公网，我会按这个顺序处理。

1. 堵住入口

   先升级 Dashboard，不要让面板直接暴露公网。访问入口可以收敛到 WireGuard、Tailscale、Cloudflare Access、内网反代或 IP 白名单。随后轮换 jwt_secret_key、agent_secret_key，清理旧登录态和旧 token。

2. 检查控制面

   重点看 Nezha 计划任务、Dashboard 数据库里的异常任务、通知配置、Webhook、OAuth 设置，以及是否存在陌生用户或异常登录痕迹。

3. 逐台检查节点

   查随机后缀的 nezha-agent-*.service，查 /opt/nezha/agent/config-*.yml，查挖矿进程、代理容器、/tmp、/dev/shm。如果有条件，再查 memfd、deleted exe、伪装 kworker 这类更隐蔽的进程。

4. 轮换凭据

   SSH key、面板密码、云服务 API key、对象存储、邮件、支付、AI 服务等，只要这台机器上可能读到，都应该按泄露处理。

如果已经出现陌生 SSH key、挖矿进程、异常流量，或者你不确定机器到底被做过什么，别太相信“清理干净了”。备份必要业务数据后重装系统更稳。

以后还用不用这类面板

这次事件不是简单的“哪吒能不能用”。真正的问题是，所有“监控 + 控制”一体化面板都要按高危入口对待。

如果一个面板可以打开终端、管理文件、批量执行命令，那它就不只是监控面板，而是运维控制台。它不该直接暴露在公网，也不该和普通状态页一个安全级别。

监控最好尽量只读。能不用远程执行，就不要开远程执行。能让 Agent 低权限运行，就不要 root。能放内网，就别放公网。

说到底，漂亮 UI 不是安全边界。生产环境里，少一个控制入口，往往比多一个炫酷面板更值钱。

Note: 本文大多数由 GPT 5.5 生成，因此 AI 味十足，不过本质就是一个事故复盘，重要的是信息准确，所以我也懒得改了。

参考资料

• Aska あすか：哪吒监控安全事件复盘
  https://x.com/Asuka_Makina/article/2067017819099983926

• NodeSeek：哪吒探针漏洞攻击全记录
  https://www.nodeseek.com/post-786371-1

• NodeSeek：哪吒面板漏洞被批量植入后门全过程
  https://www.nodeseek.com/post-779143-1

• GitHub Security Advisory：GHSA-5c25-7vpj-9mqh
  https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh

• GitHub Security Advisory：GHSA-99gv-2m7h-3hh9
  https://github.com/nezhahq/nezha/security/advisories/GHSA-99gv-2m7h-3hh9