Kubernetes 的 ingress-nginx 是大多数集群的"前门"：所有进到集群的流量都经过它，而它足够复杂、足够古老，以至于成了攻击者经年累月盯着的那道门。CVE-2026-4342 正是又一个落在它身上的高危漏洞：攻击者通过控制 Ingress 上的注释（annotation），能以注释风格向 nginx 配置里注入指令，最终在 ingress-nginx controller 进程上下文内执行任意代码，并泄露该 controller 能够访问到的 Kubernetes Secret。CVSS 8.8，影响 EKS/AKS/GKE 等几乎所有主流发行版。
一、根因：把"注释"当成可执行指令的解析器
Ingress 的功能高度依赖 annotation——开发者通过像 nginx.ingress.kubernetes.io/proxy-body-size 这样的注释来定制路由行为。CVE-2026-4342 的问题，就出在这些注释的解析上：ingress-nginx 构建 nginx 配置时，在解析 Ingress 注释的过程中，允许用户通过注释风格注入 nginx 配置指令。攻击者只要能在某个 Ingress 资源上写入合适的注释，就能把自己控制的指令带进最终的 nginx 配置——这在本质上是一种配置注入，攻击者既有能力在配置层面做手脚，也能进一步在 controller 进程内执行任意代码。而 controller pod 通常持有访问集群 Secret 所需的密钥与权限，这让泄露能力变得非常直接。
二、为什么多租户集群格外痛
在新版本上早已修、但仍有大量生产集群未打补丁的现状，让专家在 8 月反复拉响警报。对多租户集群而言，危害被进一步放大：一个租户只要能在自己的 Ingress 上注入配置，就可能利用 controller 进程的权限去访问本不该由它看到的其它租户的 Secret，从而形成越权——这也让"单租户环境"的修复优先级被推后，而"共享集群"成了必须优先处置的场景。核心在于：它是控制平面能力的代表，一旦攻破，横向影响半径远远超出单个命名空间。
三、处置与缓解
- 升级 ingress-nginx 至 1.13.9 / 1.14.5 / 1.15.1 及以上，这是根治手段；
- 严格控制谁能在命名空间内创建或修改 Ingress：把"能写 Ingress"当作等于"能进 controller 配置"的敏感权限对待；
- 在多租户集群中优先排查并阻断未打补丁的 controller，评估 controller 服务账户的 RBAC 权限并收敛；
- 对 Secret 的使用做最小化审计，确保 controller 只保有完成任务所需的最低访问范围。
CVE-2026-4342 的教训，藏在"前门"这个词的代价里：越是承接所有入站流量、越是被长期信赖的基础组件，越容易积累这类因"解析宽松"而起的隐患。对待 ingress-nginx 这样每天面对全集群的入口，把它纳入与 API Server 同等严格的安全节奏——及时升级、严格授权、收敛权限——才是真正能守住前门的做法。
参考：Kubernetes 官方安全公告（CVE-2026-4342）、O3 Security 与 Shattered 的相关技术分析。