CVE-2025-1974 — IngressNightmare (ingress-nginx)

引言

本文档介绍了影响 Kubernetes 组件 ingress-nginx（验证准入控制器）的漏洞 CVE-2025-1974 的研究。
CVE-2025-1974 是一个严重漏洞（CVSS 3.1 9.8），属于 ingress-nginx 进程上下文中的未经身份验证的 远程代码执行（RCE）。攻击者在攻击过程中，如果能够访问 Pod 网络（或者能够将 AdmissionReview 发送到验证 webhook），则可以在控制器 Pod 中执行任意代码，这可能导致 Secrets 泄露和集群被接管。

Ingress-nginx 是 Kubernetes 中最常用的 Ingress 控制器之一（据估计，有相当大比例的集群在使用它），因此该漏洞的实际影响非常高。Kubernetes、Wiz 研究人员以及多家供应商博客已发布了相关的描述、技术分析和官方修复建议。

---

报告目的

逐步剖析 CVE-2025-1974，并为撰写 write-up 准备所需材料：

1. 收集并整理材料。 收集官方公告、研究人员 write-up 和供应商分析；提取关键技术细节和 PoC 方向。
2. 理解漏洞本质及其影响。 解释根因、攻击链和可能的后果（RCE → Secrets 泄露 → 集群接管）。
3. 确定 CPE 和配置条件。 列出受影响的 Kubernetes/ingress-nginx 版本/包及配置。
4. 提供实验室安全测试建议 以及大规模检查时的风险最小化措施。

---

⚠️ 免责声明

本研究仅供教育和道德目的，并针对测试/受控环境。
在任何情况下，未经所有者书面许可，不得针对他人集群或公开可用的实例运行漏洞利用程序/PoC。公开发布完全可用的“武器化”PoC 会大大增加滥用风险——在公开部分最好提供 safe-PoC 和方法论。（官方公告和供应商也强调在传播漏洞利用程序时要谨慎。）

---

CPE 和配置条件

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — 受影响的 ingress-nginx 版本（公告中列出了具体版本；最终发布时请更新数值）。
• 包含受影响控制器的供应商/发行版：
  • RKE2 / Rancher 发行版，使用了低于指定补丁版本的 ingress-nginx。
  • Harvester 版本，使用了受影响的 ingress-nginx（供应商知识库包含具体受影响构建版本）。
  • 用户自行安装 ingress-nginx 的集群（Helm chart/manifest）——需检查 chart/image 版本。

漏洞适用的配置条件：

1. 受影响的 ingress-nginx 版本（低于公告中指定的发布/补丁版本）。具体版本号请参见 NVD 和供应商公告。
2. 验证准入 webhook 可从 Pod 网络外部访问 — 如果 webhook 可从外部访问（例如，公开 endpoint，供应商错误地将服务暴露在外），则利用程序可远程执行。Wiz 和其他研究人员指出存在大量公开暴露的案例。
3. 缺少 NetworkPolicy / Pod 网络隔离： 如果攻击者能够从某个 Pod 向集群网络发送请求（受陷 Pod），则足以进行利用。
4. 准入控制器前缺少额外验证/ACL： 额外的过滤器/ingress-proxy 身份验证可降低风险。
5. ingress-nginx 容器中的服务账号具有广泛权限并可访问 Secrets — 默认情况下，控制器通常挂载具有广泛权限的 serviceAccount；这增加了成功利用后的影响。

---

漏洞详情

简要总结。
该漏洞发现于 Ingress-NGINX 控制器的 验证准入控制器 组件中，与该组件基于传入的 Ingress / AdmissionReview 生成并验证临时 NGINX 配置的方式有关。在处理过程中，控制器会生成 nginx.conf 并执行配置检查 (nginx -t)。如果 Ingress/AdmissionReview 的字段净化不足，攻击者可以插入精心构造的片段，这些片段会进入生成的配置，并最终导致控制器进程内执行命令——即在 ingress-nginx Pod 中实现远程代码执行 (RCE)。

主要技术要点

• 入口点。 控制器验证 webhook 接收到的传入 AdmissionReview/Ingress 对象成为生成 NGINX 配置的原始数据（包括注释字段、后端设置等）。
• 利用机制。 构造的恶意 Ingress 或直接发送的 AdmissionReview 可以将可控字符串注入配置模板/片段。当此类 nginx.conf 被检查/加载时，检查过程 (nginx -t) 和随后的配置文件操作可能导致在控制器上下文中执行任意代码、写入/运行文件或执行命令。
• 必要条件。 成功利用需要：受影响的 ingress-nginx 版本；能够将 AdmissionReview 发送到验证 webhook（从 Pod 网络访问或直接网络访问）；缺少补偿措施——NetworkPolicy、RBAC 限制或额外的 webhook 身份验证。在某些场景下，可以通过直接向 webhook 发送精心构造的 AdmissionReview 来绕过 Create/Update 权限。

此漏洞的危害性——利用后果

成功利用可在 ingress-nginx 容器中执行代码，这通常允许：

• 获取控制器的 serviceAccount 令牌并访问 Kubernetes API；
• 读取可访问命名空间中的 Secrets 和其他敏感信息；
• 创建/修改集群资源并扩大访问权限（权限提升、横向移动）；
• 在某些情况下——完全控制集群。

行为与检测观察

• 在控制器正常运行期间，通常没有请求流向 Admission Controller——验证 webhook 是内部组件，仅在集群内工作。在利用过程中会观察到异常：在网络拓扑图（例如 Luntry）上，出现了来自非标准源（报告中来自 alpine 类型的容器）到 ingress-nginx-controller-admission 和 ingress-nginx-controller 服务的入站连接，这在正常工作中不应出现。
• 分析集群网络拓扑图可以了解微服务之间的交互；选择 ingress-nginx 部署所在的命名空间，可以查看入站/出站连接。在攻击时刻出现到 admission endpoint 的入站连接是明确的受损迹象。
• 为检测利用尝试，建议监控：对验证 webhook 的 POST 请求、创建非典型的 Ingress 对象、nginx -t 调用和控制器突然重启，以及 ingress-nginx 进程的意外文件写入操作。

上下文：什么是 Ingress-NGINX 控制器以及为何它很重要

Ingress-NGINX 是 Kubernetes 中使用最广泛的 Ingress 控制器之一（广泛用于组织对服务的外部访问）。该控制器充当反向代理：接收外部流量并根据一组 Ingress 规则将其代理到相应的 Service/Pod。Ingress-NGINX 项目非常受欢迎，在可互联网访问的集群中占有很大份额。

Ingress-NGINX 在 Kubernetes 文档中被作为 Ingress 控制器的参考示例。据估计，相当大比例的公网集群使用它；一些研究指出，大约 41% 的公开可访问集群使用 Ingress-NGINX。正是由于它的广泛普及和在流量路由中的核心作用，该组件中的漏洞具有很高的实际影响。

为什么验证 webhook 成为便捷的攻击向量

• 默认情况下，控制器的验证 webhook 在 Kubernetes 网络空间内可访问，并且在访问其地址（例如 validate.nginx.ingress.kubernetes.io）时通常不需要额外的身份验证。这使得从集群内部访问变得容易。
• 组合：控制器的广泛使用 + 其网络可访问性 + 潜在广泛的服务账号权限 = 关键组合，提供了有效的入侵途径。
• 在实际操作中，获得集群的“初始入口点”并不难：应用程序通常包含导致单个容器受损的漏洞；随后，攻击者可以从此容器访问内部 webhook。此外，可被利用的 web 应用程序中的 SSRF 类型漏洞通常用于向集群网络内部发起请求并利用此类 webhook。

攻击链重述（概要）

1. 攻击者能够向 Pod 网络发送请求或直接访问验证 webhook。
2. 构造一个精心制作的 Ingress / AdmissionReview，其中特定字段包含未经过滤的恶意字符串。
3. 控制器根据这些输入生成 nginx.conf，并执行 nginx -t / 其他检查操作。
4. 注入的片段导致在控制器进程上下文中执行命令/脚本或写入/运行文件。
5. 获得代码执行后，攻击者提取 serviceAccount 令牌，访问 Kubernetes API，并在集群中继续移动和提升权限。

与其他漏洞的兼容性说明

此类漏洞与其他缺陷结合时尤其危险：受陷的 Pod（或公共应用程序中的 SSRF）+ 暴露的验证 webhook 提供了很高的完全攻破机会。因此，事件分析应考虑依赖链和潜在向量，而不仅仅是 ingress-nginx 的版本。

---