2026 年 3 月初，Kubernetes 社区披露了一枚影响范围极广的安全漏洞。编号 CVE-2026-3288 的 ingress-nginx 配置注入缺陷，CVSS 评分达到 8.8，攻击者只需具备创建或修改 Ingress 资源的低权限，就能借助nginx.ingress.kubernetes.io/rewrite-target注解向底层 Nginx 进程注入非法配置，最终在控制器 Pod 内执行任意代码，并顺势拖走整个集群的 Secret 密钥。默认安装场景下，控制器对全集群 Secret 拥有读取权限，这意味着一旦漏洞被利用，等同于集群大门敞开。
漏洞核心：rewrite-target 注解成攻击入口
这次问题并非出在 Nginx 本身，而是 ingress-nginx 控制器在生成 Nginx 配置时的输入校验缺失。具体而言，控制器在处理rewrite-target注解时，会将 Ingress 资源中spec.rules.http.paths.path字段的内容直接拼接进 Nginx 的rewrite指令。由于该路径值未经过充分的转义与过滤，攻击者只需在 path 中植入双引号等特殊字符，就能提前闭合 Nginx 配置语法，随后写入任意指令。
Sysdig 安全团队的技术分析指出，今年 2 月修复的 CVE-2026-24512 曾在buildLocation()函数中引入sanitizeQuotedRegex()过滤逻辑，但维护者遗漏了同样处理路径参数的buildProxyPass()函数。于是，rewrite 指令所在的代码路径成了"漏网之鱼"，攻击 payload 可直达 Nginx 配置模板，触发配置注入。这种"补丁补一半"的情况在云原生安全史上并不鲜见，却足以让生产环境瞬间陷入高危状态。
从配置注入到集群沦陷：攻击链路拆解
很多管理员误以为 ingress-nginx 只是一个流量网关，漏洞顶多影响入口路由。实则不然。成功利用 CVE-2026-3288 后，攻击者至少能达成两个致命目的：
一是远程代码执行。注入的 Nginx 配置可加载 Lua 脚本或调用其他模块，直接在控制器容器内运行攻击者代码。控制器通常以高权限 ServiceAccount 运行，Pod 内拿到 shell 几乎等同于拿到了集群内部的"通行证"。
二是全集群 Secret 泄露。默认部署模式下，ingress-nginx 控制器需要读取各命名空间的 Secret 以完成 TLS 证书加载，因此其 ServiceAccount 绑定的 RBAC 权限往往覆盖整个集群。攻击者利用这一设计，通过控制器身份遍历所有 Secret，服务账号令牌、数据库密码、API 密钥无一幸免。
值得注意的是，利用该漏洞无需用户交互，攻击复杂度低，且可通过网络远程触发。只要集群对外开放了 Kubernetes API 入口，且攻击者拥有创建 Ingress 的权限，整个利用过程可在数分钟内完成。
你的集群中招了吗？两步自查法
第一步，确认是否部署了 ingress-nginx。在集群中执行以下命令，若有返回结果，则说明环境存在该组件：
plain
复制
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx第二步，核对当前版本。受影响的版本范围如下：
低于 v1.13.8 的 1.13.x 系列
低于 v1.14.4 的 1.14.x 系列
低于 v1.15.0 的 1.15.x 系列
若版本落在上述区间，建议立即进入排查阶段。重点审计现有 Ingress 资源，尤其是rules.http.paths.path字段是否出现双引号、反斜杠或其他异常字符。正常的业务路径通常以斜杠开头，不会包含引号，这类特征往往是攻击尝试留下的痕迹。
修复与缓解：升级为先，策略兜底
最根本的处置方式只有一个字：升。社区已在 3 月 9 日放出修复版本，建议直接升级到 v1.13.8、v1.14.4 或 v1.15.0 及以上。升级前可先做好配置备份，并在测试环境验证 Ingress 规则兼容性，避免补丁修复了漏洞，却意外冲垮了业务路由。
若短期内无法重启或升级控制器，可通过准入控制策略先断风险。具体做法是部署 OPA Gatekeeper 或 Kyverno，制定策略禁止或严格校验包含nginx.ingress.kubernetes.io/rewrite-target注解的 Ingress 资源入集群。虽然这会暂时牺牲部分 rewrite 能力，但相比集群被拖库，显然是更务实的权衡。
事后加固：别让控制器成为"集群内鬼"
补丁升级只是止血，长期防护需要收紧权限模型。建议从三个维度加固：
第一，给 ingress-nginx 的 ServiceAccount 做 RBAC 瘦身。默认的集群级 Secret 读取权限过于宽松，实际只需开放业务所需命名空间的 Secret 访问，遵循最小权限原则。
第二，启用 Kubernetes 审计日志，对 Ingress 资源的创建与修改行为保持敏感。Falco 等运行时安全工具已能基于审计日志检测 path 字段中的双引号注入特征，可作为早期告警手段。
第三，审视 Ingress 资源的创建权限。很多团队为了便利，给开发账号绑定了过宽的命名空间管理员角色，导致普通开发者也能随意修改 Ingress。将 Ingress 写权限收归平台或安全团队，能显著降低攻击面。
写在最后
CVE-2026-3288 再次印证了一个老生常谈却常被忽视的道理：云原生环境中，网关组件的权限边界直接决定集群的安全基线。ingress-nginx 作为 Kubernetes 流量入口的事实标准，其配置注入漏洞的影响面远超一般应用层缺陷。建议各团队本周内完成版本排查与升级，同时借机全面梳理控制器的 RBAC 授权。安全这件事，宁可过度防护，也别给攻击者留一扇虚掩的门。
