如果你在生产环境中运行 Kubernetes 并使用 Ingress-Nginx —— 从统计数据来看，你很可能在使用 —— 请放下手头的工作检查你的版本。在 CVE-2026-24512、CVE-2026-24513 和 CVE-2026-24514 下披露的多个严重漏洞影响了 Ingress-Nginx 控制器，CVSS 评分高达 8.8。旧版本分支的维护已于 2026 年 3 月停止，这意味着传统安装将不会获得任何补丁。修复路径很明确：立即升级到 v1.13.7 或 v1.14.3 及更高版本。以下是关于技术细节、攻击面以及 Kubernetes 入口安全更广泛影响你需要了解的信息。
漏洞详情
CVE-2026-24512 是主要漏洞。它影响 Ingress-Nginx 控制器的准入 webhook 组件，该组件在将入口资源配置应用到集群之前会对其进行验证和修改。该漏洞允许能够创建或修改 Ingress 对象的攻击者 —— 这项权限通常授予开发人员和 CI/CD 管道 —— 通过特殊构造的注解值注入任意的 Nginx 配置指令。由于准入 webhook 在净化处理之前会在服务器端处理这些注解，注入的指令会直接写入 Nginx 配置并在控制器重新加载时执行。
实际影响非常严重。攻击者可以在 Ingress-Nginx 控制器 pod 中实现远程代码执行，该控制器通常有权访问集群所服务的每个域的 TLS 密钥。从那里，向其他集群资源横向移动变得轻而易举，特别是如果控制器使用过于宽松的服务账户凭证运行 —— 这是常见的错误配置。
CVE-2026-24513（CVSS 8.8）针对 Nginx 配置模板渲染引擎中相关但不同的攻击向量。它通过操纵的 Ingress 路径规范实现路径遍历，允许攻击者从控制器 pod 文件系统读取任意文件，包括挂载的密钥和服务账户令牌。CVE-2026-24514 通过导致 Nginx 配置解析器进入无限循环的错误格式化注解值加剧了风险，有效地使整个集群的入口服务瘫痪。
为什么入口控制器是高价值目标
入口控制器在 Kubernetes 架构中占据着独特的特权位置。它们位于网络边界，终止外部流量的 TLS 并将请求路由到内部服务。出于必要，它们有权访问所服务的每个域的 TLS 证书和私钥。它们通常可以访问每个服务命名空间的网络。并且它们按设计处理不受信任的输入 —— 来自互联网的 HTTP 请求。
这种特权与暴露的结合使得入口控制器成为 Kubernetes 集群中价值最高的攻击目标之一。被攻破的入口控制器可以拦截和修改进入集群的所有 HTTP 流量，窃取 TLS 私钥从而对任何托管域名进行中间人攻击，并可能利用挂载的服务账户令牌转向 Kubernetes API 服务器。安全研究人员越来越多地将入口控制器视为一种攻击向量，而这些 CVE 的发现正是这一更广泛趋势的一部分。
受影响版本和修复措施
1.13.x 分支中 v1.13.7 之前的所有 Ingress-Nginx 控制器版本，以及 1.14.x 分支中 v1.14.3 之前的所有版本都受到影响。关键的是，1.12.x 分支和所有更早的版本线已于 2026 年 3 月停止维护，不会收到任何补丁。运行这些旧版本的组织必须升级到支持的分支——别无选择。
Ingress-Nginx 的升级过程有完善的文档记录，但在生产环境中需要仔细规划。控制器管理着影响实时流量路由的 Nginx 配置状态，因此糟糕的升级可能导致停机。推荐的方法是使用金丝雀策略部署新版本的控制器 alongside 现有版本，验证流量路由是否正常工作，然后进行切换。Helm chart 用户应更新到相应的 chart 版本，并查阅变更日志以了解配置语义中的任何重大变更。
对于无法立即升级的组织，作为即时缓解措施，可以使用 RBAC 限制谁能创建和修改 Ingress 资源。主要攻击向量需要能够创建具有任意注释的 Ingress 对象的能力，因此将此权限限制在受信任的自动化和高级操作员可以减少攻击面。此外，考虑在严格模式下启用控制器准入 webhook，它会拒绝带有未知注释的 Ingress 资源，而不是让它们通过。
入口安全的深度防御
这些漏洞凸显了围绕 Kubernetes 入口进行分层安全防护的必要性。没有单一的控制措施是足够的。网络策略应限制入口控制器可以与哪些 pod 通信——它需要访问后端服务，但不应该拥有无限制的集群级网络访问。Pod 安全标准应确保控制器尽可能以非 root 用户身份运行，并使用只读的根文件系统。秘密访问应限定范围——控制器应该只挂载它实际服务的域的 TLS 密钥，而不是对命名空间中的所有密钥拥有完全访问权限。
像 Falco 或 Tetragon 这样的运行时安全工具可以检测入口控制器 Pod 中的异常行为——shell 执行、意外的网络连接或偏离正常控制器操作的文件访问模式。这些工具提供了一个检测层，即使在预防措施失效时也能捕获到攻击行为。
更全面的视角
Ingress-Nginx 漏洞提醒我们，Kubernetes 安全不是一个终点，而是一个持续的过程。平台的表面积巨大，变化节奏毫不松懈，而最重要的组件——入口控制器、API 服务器、etcd、kubelet——恰恰是攻击者主要针对的目标。旧版 Ingress-Nginx 停止维护尤其令人担忧，因为许多组织运行版本固定的基础设施，这些基础设施比上游发布落后数月甚至数年。
如果您的组织将 Kubernetes 组件升级视为可选或低优先级维护，那么这些 CVE 应该促使您重新评估。从漏洞披露到实际利用之间的时间窗口正在不断缩小。对于入口控制器这类面向互联网的组件，这个窗口可能是几天，而不是几周。立即修补漏洞，审查您的入口 RBAC 策略，实施运行时检测，并建立流程以确保您永远不会在安全更新方面落后这么多。