CVE-2026-27944 Nginx UI信息泄露漏洞深度分析

这是一个CVSS评分9.8的严重漏洞，允许未经身份验证的攻击者下载并解密Nginx UI服务器的完整系统备份，从而获取敏感数据。

漏洞概述

CVE-2026-27944是Nginx UI（一款基于Web的Nginx服务器图形化管理工具）中的一个严重信息泄露漏洞。该漏洞存在于2.3.3之前的版本中，主要问题在于/api/backup端点无需身份验证即可访问，并且在X-Backup-Security响应头中泄露了解密备份所需的加密密钥。

技术细节分析

漏洞核心机制

漏洞由两个关键缺陷组成：

1. 权限控制缺失：/api/backup接口被错误地放置在无需认证的公共路由组中，而非受保护的私有路由组。
2. 密钥同步泄露：备份文件虽然使用AES-256-CBC加密，但加密密钥和初始化向量（IV）以base64格式拼接后，直接放入X-Backup-Security响应头中返回给客户端。

攻击流程

攻击者只需执行以下简单步骤即可获取敏感数据：

1. 发送匿名请求：GET /api/backup
2. 接收包含加密备份文件的响应
3. 从响应头提取X-Backup-Security: <base64key>:<base64iv>
4. 使用标准AES解密工具解密备份文件

影响范围

受影响版本：Nginx UI 2.3.3之前的所有版本。

漏洞原理深度分析

路由配置错误

在router/routers.go中，备份模块的路由被错误地初始化在匿名访问组：

root := r.Group("/api", middleware.IPWhiteList())
{
    public.InitRouter(root)
    crypto.InitPublicRouter(root)
    user.InitAuthRouter(root)
    license.InitRouter(root)
    system.InitPublicRouter(root)
    system.InitSelfCheckRouter(root)
    backup.InitRouter(root)  // 错误位置：应放在需要认证的组
}

IP白名单的”零值陷阱”

middleware/ip_whitelist.go中的IP白名单中间件存在设计缺陷：

func IPWhiteList() gin.HandlerFunc {
    return func(c *gin.Context) {
        clientIP := c.ClientIP()
        if len(settings.AuthSettings.IPWhiteList) == 0 || clientIP == "" || clientIP == "127.0.0.1" || clientIP == "::1" {
            c.Next()  // 白名单为空时直接放行
            return
        }
        // ... 其他检查
    }
}

由于默认配置中IPWhiteList为空数组，导致所有新安装的环境在默认状态下即对公网完全暴露高危接口。

密钥泄露实现

在api/backup/backup.go中，加密密钥被直接放入响应头：

func CreateBackup(c *gin.Context) {
    result, err := backup.Backup()
    if err != nil {
        cosy.ErrHandler(c, err)
        return
    }

    // 拼接密钥和IV
    securityToken := result.AESKey + ":" + result.AESIv

    // 将安全令牌放入响应头
    c.Header("X-Backup-Security", securityToken)  // 关键泄露点

    // ... 发送文件内容
}

泄露的敏感数据

解密后的备份文件包含以下敏感信息：

1. 用户凭据与认证数据

• 用户账户信息（包括哈希密码）
• 会话令牌和认证Cookie
• 2FA/Passkey相关数据

1. SSL/TLS证书与私钥

• 网站SSL证书私钥
• 中间证书和根证书

1. Nginx配置信息

• 完整的Nginx配置文件
• upstream服务器地址和内网服务信息
• 访问控制策略和认证配置
• 反向代理规则

1. 应用配置数据

• app.ini配置文件中的JWT密钥
• Node secret和其他加密密钥
• 数据库连接信息
• 第三方服务API密钥

1. 数据库文件

• SQLite数据库文件（包含用户数据、配置等）

潜在攻击链扩展

结合恢复接口的RCE可能性

虽然CVE描述主要关注信息泄露，但POST /api/restore接口同样位于匿名组，这可能导致更严重的后果：

1. 配置覆盖攻击：攻击者可以上传恶意Nginx配置
2. 服务重启控制：通过设置restore_nginx=true参数触发Nginx重启
3. RCE实现：通过恶意Nginx配置实现命令执行（如利用lua模块）

内网横向移动

获取的配置信息可能包含：

• 内网服务地址和端口
• 数据库连接字符串
• 其他服务的认证凭据
• 网络拓扑信息

修复方案

官方修复（2.3.3及以上版本）

1. 路由重新分组：将备份相关接口移至需要认证的路由组
2. 移除密钥泄露：不再在响应头中返回加密密钥
3. 加强默认安全：改进IP白名单的默认行为

临时防护措施

1. 升级到最新版本：立即升级到Nginx UI 2.3.3或更高版本 GitHub-nginx-ui
2. 网络访问控制：

• 使用防火墙限制对Nginx UI管理端口的访问
• 仅允许受信任的IP地址访问管理界面

1. 启用认证：确保启用并配置强身份验证
2. 监控与日志：监控对/api/backup和/api/restore端点的访问

安全启示

1. 管理界面安全：Web管理界面不应直接暴露在公网
2. 默认安全配置：安全功能应有安全的默认值
3. 加密不等于安全：加密必须与密钥管理结合才有效
4. API端点审计：定期审查API端点的访问控制
5. 纵深防御：采用多层安全防护，不依赖单一控制点

该漏洞的CVSS 9.8评分反映了其严重性，攻击者无需任何特殊技能即可利用，且影响范围广泛。对于使用Nginx UI的组织，应立即评估风险并采取相应措施。