漏洞概述
Nginx-UI 备份恢复机制中被披露存在一个高危安全漏洞（CVE-2026-33026）。该漏洞允许威胁攻击者在恢复过程中篡改加密备份文件并注入恶意配置。随着公开的 PoC 利用代码发布，未打补丁的系统面临被完全攻陷的即时风险。
加密缺陷利用原理与 PoC
该漏洞的根本原因在于应用程序备份架构中存在严重缺陷的循环信任模型。当 Nginx-UI 生成备份时，会将文件压缩为 ZIP 归档并使用 AES-256-CBC 加密，但系统未能维护可信根信任。AES 密钥和初始化向量（IV）作为备份安全令牌直接提供给客户端，而非在服务端保护加密参数。
更严重的是，包含加密文件 SHA-256 哈希值的完整性元数据文件也使用相同密钥加密。由于攻击者拥有密钥，可轻松绕过所有加密安全控制。此外，恢复过程未执行严格的完整性验证，即使哈希不匹配触发系统警告，恢复操作仍会继续。
安全研究员 'dapickle' 成功演示了如何利用这一架构弱点。公开的 PoC 包含可自动解密和重建 Nginx-UI 备份文件的 Python 脚本。攻击流程包括：
- 生成标准备份并从 HTTP 头提取安全令牌
- 使用解密脚本解压归档并修改内部配置文件
app.ini - 注入恶意命令（如
StartCmd = bash） - 使用重建脚本压缩修改后的文件，计算新的合法哈希值，更新元数据，并使用原始令牌重新加密整个包
- 上传篡改后的备份至 Nginx-UI 恢复接口，系统将盲目接受并执行注入的负载
影响与回归分析
该漏洞被评为严重级别，在多个影响指标上获得 CVSS 4.0 最高分。成功利用可使攻击者永久篡改应用配置、在 Nginx 路由中植入后门，并在主机上实现任意命令执行。
值得注意的是，该漏洞是 GitHub 公告 GHSA-fhh2-gg7w-gwpq 中记录的前期漏洞的回归。虽然早期补丁解决了备份文件的未授权访问问题，但完全未能解决底层加密设计缺陷，使系统仍面临归档修改的根本性风险。
安全社区将该漏洞归类为多种弱点组合，包括完整性检查值验证不当（CWE-354）和加密签名验证失败（CWE-347）。该漏洞影响基于 Go 的 Nginx-UI 软件包，特别是 2.3.3 及更早版本。管理员必须立即升级至 2.3.4 修补版本。
除应用最新补丁外，建议开发者实施服务端可信完整性根，使用私钥而非客户端暴露的令牌对备份元数据进行签名。此外，系统应安全配置以避免循环信任模型，并在任何哈希验证失败时严格中止恢复操作。