企业官网建设流程全解析

Nginx UI 是一个给 Nginx 做 Web 管理界面的开源项目。它有一个限制：普通的 HTTP 配置接口不允许写入load_module、js_import、js_content这类高危指令。这个限制做得对。问题在于，同一个产品新加的 MCP 配置接口，没有做同样的检查。

结果是：一个只该改配置的用户，可以通过 MCP 接口把 Nginx 变成一个代码执行环境。

一、漏洞本身

单独看评分，8.3 在今年的漏洞列表里不算最刺眼的——同一个月里有 9.1、9.5、10.0 的。但它的成因比评分更值得看。

二、根因：同一道限制，两个接口只做了一个

公开分析把成因写得很清楚：安全控制不一致。

• 常规 HTTP 配置接口：对敏感指令有白名单或拒绝机制，load_module、js_import、js_content写不进去；

• MCP 配置接口：缺乏相应的验证逻辑，允许已认证用户提交并应用这些受限配置。

于是这个限制在系统里其实只存在了一半。攻击者不需要绕过它——他只需要走另一个门。

利用链分三步：

1. 通过 MCP 接口写入受限配置，比如加载ngx_http_js_module.so；

1. 引入由攻击者控制的 JavaScript 代码；

1. 触发 Nginx 重载，使 NJS 脚本在Nginx 的 worker 进程上下文中执行。

到第三步就是任意代码执行。而 Nginx 的 worker 进程通常有对外服务的权限，服务器完全控制、数据泄露、服务中断都在可达范围内。

三、为什么 MCP 接口容易成为这一类盲区

这个案例不是孤例，它反映的是新接口进入存量系统时的一个通用遗漏。

一个已经运行了几年的管理后台，它的安全逻辑长这样：每个入口先过一轮权限判断，再过一轮参数白名单，最后才落到配置写盘。这套检查是随着功能一个个长出来的——每加一个配置项，顺手把它的白名单规则也加上。

然后团队加了一个新接口，用途是「让 AI 工具能通过 MCP 协议管理 Nginx」。新接口的功能跑通了：读配置、写配置、重载，全都能用。它的权限校验也做了：只有通过认证的用户才能调用。

唯独漏掉的是「参数白名单」这一层。因为它不在认证层的视野里，也不在功能测试的覆盖范围内——功能测试关心的是「合法的配置能不能写进去」，不关心「非法的指令能不能被拦住」。

这类遗漏有一个共同特征：它不是把检查做松了，而是新路径没有接进旧检查。修复方式也因此不是「加强校验」，而是「让新入口复用旧入口的校验逻辑」。

同一周里，同一产品线上还有另一类同构问题。10 月 12 日披露的 ngx_cache_purge（CVE-2026-108981）是清理缓存时跟随符号链接导致任意文件删除，3.0.4 修掉了「任意时间创建的符号链接」这一情形，但 TOCTOU 竞态仍未解决；同月披露的 Nginx 两个 RCE（CVE-2026-42530 需启用 HTTP/3、CVE-2026-42055 是 HTTP/2 代理模块的堆溢出）给的是「关闭 HTTP/3 或调小 header 缓冲区」这类缓解——都是绕开问题，不是修根因。把这三件事放在一起看，形态一样：防护措施在一个路径上有效，在另一个路径上不存在。

四、这件事对「把接口交给智能体」的启示

Nginx UI 加 MCP 接口的动机很清楚：让 AI 编码工具、运维智能体能直接管理 Nginx。这是今年很多基础软件都在做的事——9 月底到 10 月初，Oracle 把自家数据库包装成一个标准 MCP 端点，Automation Anywhere 在 Automation 360 里加了显式 MCP 支持，IBM 也发了用 MCP 服务器把业务能力安全暴露给智能体的架构指南。

MCP 正在成为「能力对外开放」的标准协议层。但这个案例说明：新增一个对外接口，等于给系统加了一个新的信任边界。而边界上的检查项，必须和既有接口逐条对齐，而不是「反正都走认证」。

具体要核对三件事：

1. 受限指令清单是否共用。高危指令的白名单/黑名单应该是一个共用的常量或策略对象，两个接口引用同一份，而不是各写一份；

1. 参数校验是否在同一层做。如果校验写在 HTTP 控制器里，那 MCP 控制器就天然绕过了它。校验应该下沉到「配置写入」这个动作本身；

1. 新接口是否进了威胁模型。功能测试覆盖不到「非法输入被拒绝」，需要专门的用例来说明「哪些东西必须写不进去」。

在信创环境里，企业内部服务分散在不同技术栈与不同底座上，协议、认证方式、数据格式都不统一，把它们整理成可供模型调用的统一形态，本身就是接口发布环节的工作。金蝶天燕 Apusic 负载均衡器 ALB 兼容 Nginx，支持通过 Nginx 配置文件配置、并提供一键迁移既有 Nginx 服务的能力，同时对外开放 RESTful 外部 API 与面向 AI Agent 的接入方式——当同一个 Nginx 语义既有配置文件入口、又有 API 入口时，「受限指令在哪一层被拦住」这个问题就必须有唯一答案，否则和上面这个漏洞是同一类结构问题。

五、如果你在用 Nginx UI

三条动作：

1. 升级到 2.4.1 或更高。这是唯一根治手段；

1. 排查 MCP 接口的暴露面。如果这个接口不对外开放（仅本机或内网管理网可达），风险显著降低——但内网不等于安全，二级认证用户的横向移动同样要考虑；

1. 审计 MCP 写入的配置历史。重点看有没有load_module、js_import、js_content这类指令通过 MCP 接口写进去过。

六、结论

三条要点：

1. 这个漏洞的成因是覆盖不全，不是强度不够。同一道限制在 HTTP 接口做了、在 MCP 接口没做，攻击者不需要绕过，只需要换门；

1. 新增对外接口等于新增信任边界。每加一个入口，都要把既有入口的检查项逐条对一遍，而不是只做认证；

1. 判断规则可以迁移。凡是「同一个能力有多个入口」的系统，都要问一句：这些入口的检查项，是谁在保证它们一致？

边界也要说清楚：本文的漏洞细节取自公开漏洞平台的分析，CVSS 8.3、影响版本 < 2.4.1、利用前提为二级认证权限，均以该来源为准；文中未发现原厂商公告的细节补充。修复建议是升级，其他措施只作缓解。

你们系统里同一个能力有几个入口？如果有配置文件入口和 API 入口两套，你能确定它们的限制清单是同一份吗？