凌晨三点，服务器CPU突然飙到100%。你以为是业务高峰，其实是有人在用你的电费赚比特币。开源工具青龙面板（Qinglong）——这个在GitHub攒了1.9万星的中文开发者心头好，2026年初成了黑客的免费矿机。

一张图看懂：攻击怎么绕过了登录

打开网易新闻 查看精彩图片

青龙面板是个自托管的定时任务调度台，支持Python和JavaScript脚本。很多开发者拿它跑签到、抢券、数据同步，顺手就扔在云服务或家里的NAS上，Docker一键部署，图个方便。

方便的不只是你。2026年2月7日前后，一批用户的面板开始异常发热。BleepingComputer的记录显示，服务器负载直接顶满，罪魁祸首是个叫.fullgc的进程——名字伪装成Java垃圾回收，实际在狂挖加密货币。

攻击者没偷你的密码，也没暴力破解。他们找到了两条更野的路：

【漏洞一】CVE-2026-3965：URL重写规则的认知错位

青龙的安全中间件默认：/api/* 需要认证，/open/* 可以公开访问。但Express.js的路由重写有个坑——/open/* 的请求会被映射到 /api/* 的处理逻辑上。

黑客发一条请求到 /open/auth/init，实际命中的是 /api/auth/init。这是初始化接口，本不该暴露。一条请求，管理员密码重置，面板归他了。

【漏洞二】CVE-2026-4047：大小写敏感的"不敏感"

中间件检查 /api/* 时认的是小写。但Express.js的路由匹配不区分大小写，/aPi/、/API/、/ApI/ 都能走到同一个处理器。

中间件放行，后端执行。远程代码执行，无需任何凭证。

Snyk的研究员把这两个漏洞的根因说得很直白：安全中间件的假设和框架实际行为对不上。开发团队以为拦住了，实际漏了个缝。

时间线：从第一例报告到全面沦陷

2月7-8日：首批用户在论坛喊CPU炸了，.fullgc进程删不掉

2月10日：感染面扩大，社区有人呼吁官方发安全公告

2月27日：研究员公开披露两个认证绕过漏洞的技术细节

3月1日：维护者确认漏洞，敦促用户升级

这二十天里，GitHub上出现过民间补丁——尝试过滤恶意输入。但治标不治本，中间件的认证逻辑没动，绕过的方式可以换花样。

最终修复是直捣黄龙：改掉中间件和路由的协作方式，让安全假设和实际行为对齐。

为什么偏偏是青龙？

1.9万GitHub星，中文开发者圈子的渗透率极高。很多人拿它当"个人自动化中枢"，部署场景却极其暴露：云服务器公网IP、家庭NAS端口转发、Docker默认桥接。

自托管工具的安全责任完全在用户。没有厂商推送补丁，没有安全团队7×24监控，升级按钮得自己点。

更微妙的是使用心态。定时任务面板不像数据库或支付系统那样让人警惕，"就是个跑脚本的"——这种轻视让它成了软目标。

攻击者的挖矿脚本命名.fullgc，蹭的是Java开发者熟悉的垃圾回收术语。排查时扫一眼进程列表，很容易误以为是正常JVM行为，调查被拖延，矿多挖几小时。

数据收束

2.20.1及更早版本全部中招。两个CVE，一条重写规则，一个大小写陷阱，换来的是全球范围内未知数量的服务器沦为矿机。维护者在3月1日的公告里只说了两个字：升级。

你的面板版本号是多少？