Ingress NGINX 再爆多项高危漏洞，10 分钟迁移到阿里云 API 网关

Ingress NGINX 已于 2026 年 3 月 24 日退役。已部署的 Controller 仍可继续运行，但社区已不再发布新版本，也不再提供缺陷修复和安全补丁。与此同时，新的高危漏洞仍在陆续披露，入口层一旦暴露风险，影响的往往不是单个服务，而是整条南北向流量链路。针对 ACK 集群中仍在使用的 Nginx Ingress，阿里云云原生 API 网关近期进一步完善了迁移能力和控制台操作体验：原入口复用范围从 CLB 扩展到 NLB；不兼容注解可由迁移 Skill 分析并输出处理建议；迁移、切流与回退也被整合进控制台流程。简单说，风险在增加，但迁移这件事正在变得更容易。

仍可运行，不等于安全生命周期仍在继续

Cloud Native

Ingress NGINX 长期承担 Kubernetes 集群的南北向流量入口。一旦入口层出现缺陷，影响往往不只停留在网关侧，还可能传导到后端服务和集群整体暴露面。

Ingress NGINX 退役，并不意味着安全问题也停止出现。项目停止维护后，社区和安全研究机构仍在持续发现新的 NGINX 漏洞：2026 年 5 月披露的 CVE-2026-42945 和 CVE-2026-9256 都与 ngx_http_rewrite_module 有关，问题集中在 rewrite 规则对 PCRE 捕获组和替换字符串的处理上。在特定 rewrite 配置下，攻击者可以通过构造 HTTP 请求触发堆缓冲区溢出，造成 NGINX worker 进程崩溃重启；在 ASLR 关闭或可被绕过的情况下，还存在进一步代码执行的可能。2026 年 7 月披露的 CVE-2026-42533 则发生在 map 指令的正则匹配场景，同样属于堆缓冲区溢出，未认证请求即可触发数据面 worker 重启，严重情况下也可能被用于更进一步的攻击。三项漏洞的 CVSS v3.1 评分均为 8.1，属于高危漏洞；CVE 记录中列出的受影响范围也覆盖了 Ingress NGINX 最终官方镜像所使用的 NGINX 版本。

这些漏洞的共同点在于：它们不是“理论上的入口风险”，而是落在 NGINX 配置解析、rewrite 处理、map 正则匹配这些网关高频能力上的内存安全问题。对仍在使用退役 Ingress NGINX 的集群来说，更麻烦的地方在于，即使 NGINX 上游发布补丁，这些修复也不会再进入已经退役的 Ingress NGINX 官方 Controller 镜像，存量用户无法再通过原项目升级获得修复。服务还能继续运行，不等于它的安全生命周期还在继续。接下来要关注的不只是“还能不能继续跑”，而是要尽快为入口层准备一条可验证、可回退、可持续维护的迁移路径。

为什么迁移到云原生 API 网关

Cloud Native

对仍在使用 Nginx Ingress 的团队来说，迁移到云原生 API 网关并不只是替换 Controller。更关键的是：在尽量少改业务配置、尽量不动入口地址的前提下，把迁移、验证、切流和回退放进一条可控流程里。

1. 尽量保留原有资源和发布方式。云原生 API 网关可以监听 ACK 集群中的 Ingress 和 Service，并支持自定义 IngressClass。迁移时可直接监听原 Nginx Ingress 使用的 IngressClass，让两套控制面在过渡期读取同一批 Ingress 和 Service；兼容的路由和注解可以继续复用，无需重新创建一套 Ingress，团队也可以沿用现有 YAML 和 GitOps 发布流程。

2. 将入口治理交给托管网关。云原生 API 网关会将 Kubernetes 资源转换为网关路由，并提供认证鉴权、流量治理、插件扩展和可观测能力。业务团队仍然使用熟悉的 Kubernetes 资源管理应用，入口运行、治理和持续维护由托管网关承接。

3. 保持入口地址和客户端调用方式不变。迁移可以复用原有负载均衡入口，域名、IP 和客户端调用方式保持不变；新旧网关挂载在同一个入口后并行承接流量，再按比例逐步切换。对于外部调用方多、SDK 版本分散，或入口地址难以统一变更的业务，这是迁移方案能否平稳执行的关键条件。

4. 为后续升级到 Gateway API 预留空间。云原生 API 网关支持 Gateway API，并可灵活自定义 GatewayClass。作为 Kubernetes 官方主推的下一代流量管理标准，如果团队后续计划从 Ingress 演进到 Gateway API，可以在现有云原生 API 网关上继续使用和升级，无需再次迁移网关承载。

图 1：迁移期间，原 CLB 或 NLB 按比例将流量分配给 Nginx Ingress 和云原生 API 网关，两条链路均访问同一 Service 和 Pods。

升级一：原入口复用从 CLB 扩展到 NLB

Cloud Native

此前，云原生 API 网关已支持复用 Nginx Ingress 前置的 CLB。本次升级将复用入口的支持范围扩展到 NLB。

在现有迁移流程不变的前提下，复用入口的覆盖范围从 CLB 扩展到 NLB，具体操作如图所示。

扩展后，迁移方案在入口保持、验证和回退方面具备以下变化：

入口地址保持不变，通常无需调整 DNS 解析；
客户端调用方式保持不变，外部调用方不需要配合迁移同步修改访问地址；
新旧链路可并行承接流量，便于分阶段验证、放量和回退；
原先因使用 NLB 而无法采用复用入口迁移方式的集群，现在可以纳入同一套迁移流程。

图 2：创建迁移配置时勾选“复用原集群 SLB”，当前支持选择 CLB 或 NLB。

升级二：不兼容注解从识别到处理建议

Cloud Native

在 Ingress 迁移评估中，注解兼容性是需要重点确认的一项内容。

云原生 API 网关已兼容 Nginx Ingress 大部分常用高频注解，90% 以上的高频注解基本可以直接覆盖。这部分兼容项可以继续保留，无需为了迁移重复改写；剩余不兼容注解主要是少数场景，但这些场景往往更依赖具体业务语义和网关能力映射，也是迁移兼容处理更容易产生工作量的部分，需要单独评估替代方式。

此前，迁移工具主要用于扫描 Ingress 并标识不兼容注解，后续的文档查找、替代方案评估和插件开发仍需人工完成。现在，可以通过阿里云云 Skill 门户官方 Skill ：alibabacloud-nginx-ingress-to-api-gateway，生成面向迁移场景的兼容性分析、处理建议和配置参考。

Skill 会结合注解的实际语义逐项分析，并按以下优先级给出处理建议：

1. 云原生 API 网关已经兼容的，原样保留；

2. 能映射到 Higress 原生能力的，给出原生配置写法；

3. 可移除且不影响业务行为的，说明移除依据；

4. 已有内置插件能覆盖的，生成对应的插件配置；

5. 以上方式都无法覆盖的，再生成自定义 Wasm 插件方案。

图 3：已识别的不兼容注解按优先级匹配原生配置、安全移除和内置插件；

前三种方式均无法覆盖时，再生成自定义 Wasm 插件方案。

这里的“自定义 Wasm 插件方案”不是只给出实现思路，而是根据原注解语义自动生成插件代码和通过 Ingress 注解绑定插件的配置，形成可实现对等能力的完整产物，并配套部署、验证和回退操作指引；用户评审确认后即可按说明落地。

除兼容性结论外，Skill 还会整理迁移后的 Ingress 配置、插件方案、部署步骤、验证方法和回退说明。它不会直接持有集群权限或修改生产环境，而是输出可评审、可执行的迁移材料；业务语义仍由团队确认，变更也继续纳入既有发布流程。

迁移 Skill 的作用不只在于输出扫描结果，还包括提前整理替代方案、插件配置和操作步骤。对于注解数量较多、历史配置较复杂的集群，这部分准备工作可以减少人工梳理成本。

升级三：迁移、切流和回退

都收进同一条控制台流程

Cloud Native

入口和配置准备完成后，迁移进入切流阶段。

此前，这一步需要在云原生 API 网关控制台与 ACK 控制台之间来回切换：先在网关侧配置权重，再到 ACK 控制台手动修改 Nginx Ingress LoadBalancer Service 注解。对单个集群来说操作还能接受，但一旦涉及多个入口、多个环境或多轮灰度，就需要人工维护两侧权重、等待配置生效，并反复在多个页面确认状态，迁移成本和误操作风险都会被放大。

图 4：升级前，迁移页面会提示用户前往 ACK 控制台

手动修改 Service 注解，完成后再返回网关侧继续操作。

现在，云原生 API 网关将这些操作整合到迁移页面：

迁移所需的 Service 注解支持一键更新，不需要再手动编辑 YAML 或跨控制台切换；
可直接设置云原生 API 网关承接的目标流量比例，支持在 0% 到 100% 之间逐步调整；
新旧链路的目标权重由系统统一换算并下发，迁移人员只需要关注“希望新网关承接多少流量”；
支持按比例分阶段放量，出现异常时可快速下调，必要时回退到 0%；
当目标比例调整到 100% 且观察稳定后，可在同一页面完成迁移收尾。

图 5：升级后，注解更新、目标比例调整和完成迁移

均可在云原生 API 网关控制台内完成。

为避免连续操作造成状态不一致，切流流程增加了任务状态控制：上一次调整未完成时，系统不会接受新的切流任务；向上放量时每次最多增加 25 个百分点，向下调整不受该限制，便于异常时快速回退。与此同时，切流任务的编排与状态收敛也做了优化，使不同环境、不同任务时序下的权重调整结果更一致。这些限制的目的，是为每次变更预留必要的生效和观察时间。

图 6：迁移过程中，原有 CLB 或 NLB 保持不变，

新旧链路并行承接流量，云原生 API 网关的目标比例从 0% 逐步调整到 100%。

一次迁移，现在可以按页面走完

Cloud Native

完成上述升级后，一次迁移可以沿着控制台引导拆成五个阶段：

1. 确认环境：确认云原生 API 网关版本、ACK CCM 版本、IngressClass、负载均衡类型和监听配置；

2. 迁移路由：导入或监听现有 Ingress，兼容注解先按原配置保留；

3. 处理差异：使用迁移 Skill 分析不兼容项，并根据报告准备原生配置、内置插件或 Wasm 插件；

4. 验证链路：通过本地 hosts 等方式访问云原生 API 网关入口，验证路由匹配和业务行为；

5. 切换流量：复用原有 CLB 或 NLB，在迁移页面按目标比例分阶段放量，观察稳定后完成迁移。

迁移期间，建议保留原有 Ingress、Service 和 Nginx Ingress Controller，直到流量稳定切换并完成观察期后再清理。保留回退路径，可以降低迁移收尾阶段的操作风险。

写在最后

Cloud Native

Ingress NGINX 退役不会让现有实例立即停止运行，但它改变了风险边界：后续不再有官方新版本、缺陷修复和安全补丁，入口组件的生命周期管理和安全响应需要由使用方自行承担。继续拖延迁移，意味着每一次新漏洞披露后，都要重新评估入口暴露面、补丁不可得和应急替代方案。

本次云原生 API 网关对 Nginx Ingress 迁移能力的升级，主要围绕三类影响迁移效率和确定性的环节展开：

入口覆盖范围扩展：CLB、NLB 均可复用，入口地址和客户端调用方式可以保持不变；
注解处理更明确：兼容注解可原样复用；不兼容注解由 Skill 输出替代方案、插件配置和操作步骤；
切流链路更集中：可在控制台内完成注解更新、比例调整、观察和回退，减少跨页面操作和手工换算。

如果你正在评估存量 Nginx Ingress 集群的后续演进，可以直接进入云原生 API 网关控制台的迁移工具，按页面引导完成环境确认、注解分析和分阶段切流。具体适用范围、版本前提和完整操作步骤，可参考文末的迁移指南；正文这里不展开版本细节。迁移入口：云原生 API 网关 Nginx Ingress 迁移工具。如果在迁移过程中遇到兼容性、配置转换、切流验证或回退相关问题，也欢迎反馈给我们。我们会持续优化迁移能力和控制台体验，帮助存量集群更平稳地完成迁移。

Ingress NGINX 再爆多项高危漏洞，10 分钟迁移到阿里云 API 网关

相关资料：