3000多台生产环境的Nginx-UI实例正在互联网上裸奔。安全研究员dapickle上周丢出的PoC代码，把一个叫CVE-2026-33026的漏洞变成了点击即用的攻击工具。这不是什么边缘案例——你的备份文件本身就是攻击入口。
信任模型塌得像纸牌屋
Nginx-UI的备份机制设计得像把家门钥匙藏在门垫下面。系统用AES-256-CBC加密备份包，听起来很安全，但加密用的密钥和初始化向量（IV）直接通过HTTP响应头扔给客户端。
更荒诞的是，用来校验文件完整性的SHA-256哈希值，也被同一把密钥加密后塞进了备份包。攻击者拿到密钥后，整个加密体系就成了摆设——你能解密，我也能解密；你能算哈希，我也能算哈希。
dapickle在GitHub上公开的PoC脚本把这套流程自动化了：提取token、解密ZIP、修改配置、重新打包、伪造哈希、上传恢复。六步操作，全程不需要猜密码、不需要绕过防火墙。
攻击者甚至不需要先入侵系统。只要有备份恢复权限的账户，或者能诱导管理员导入"测试备份"，就能在目标机器上执行任意命令。
CVSS 4.0给了这个漏洞满分。不是因为某个环节特别难防，而是每个环节都没防。
旧补丁打了个寂寞
这个漏洞其实是个"二进宫"。GitHub安全公告GHSA-fhh2-gg7w-gwpq早在之前就记录过类似问题，当时的补丁限制了未授权用户下载备份文件，但根本没碰底层加密设计。
结果就是把门锁上了，钥匙还挂在门把手上。攻击者换个姿势——不是偷备份，而是自己造一个"合法"备份——照样能进门。
dapickle的PoC演示了一种典型攻击路径：在app.ini配置里注入StartCmd = bash。Nginx-UI恢复备份时会执行这个启动命令，攻击者就拿到了宿主机的shell。后续还能往Nginx路由里塞后门，动静小、权限高、难以排查。
恢复流程的完整性校验也是个摆设。系统会警告哈希不匹配，但允许用户强制继续。设计者的假设大概是"用户看到警告会停手"，但攻击者根本不会给你看警告的机会——他们算的是"正确"的哈希。
PoC正在扩散
Shodan扫描显示，暴露在互联网的Nginx-UI实例超过3000个。这个数字不包括内网部署——而内网往往是更高价值的目标。
dapickle的Python脚本已经在安全社区流传。脚本功能很完整：自动从HTTP头提取安全token、用pycryptodome解密AES-256-CBC、重新计算并替换SHA-256哈希、按原格式重新打包。整个工具链不需要自定义加密算法，用的全是标准库。
这意味着攻击门槛极低。不需要懂密码学，不需要逆向工程，复制粘贴改几个路径就能用。
企业安全团队的麻烦在于：备份恢复通常是运维高频操作，很难直接禁用。而Nginx-UI的设计初衷就是降低Nginx配置门槛，用户群体恰恰是那些对安全细节不太敏感的小团队。
临时缓解方案包括限制备份恢复权限、网络层隔离管理接口、监控异常的配置变更。但核心修复只能等官方补丁——把密钥管理搬回服务端，引入非对称签名或HMAC校验，彻底拆掉这个圆形信任链。
dapickle在披露时提到，这个漏洞的"优雅"之处在于它利用了系统自身的合法功能。没有内存破坏、没有竞争条件，纯粹是架构设计把机密当成了便利。这种漏洞最难防，因为日志里看起来一切正常：用户上传了备份，系统执行了恢复，流程完整闭环。
最后一个细节：PoC脚本里留了一行注释，建议测试时先把原备份复制一份，"免得把自己锁在外面"。连攻击工具都在提醒备份的重要性——只是Nginx-UI的备份，现在成了最需要防备的东西。
你的备份策略里，有没有哪一环是把密钥交给潜在攻击者的？
热门跟贴