云原生动态：GKE容器逃逸漏洞集群敲响运行时安全警钟、Flux Mirror实现无Git的GitOps镜像治理、Ingress-NGINX正式终止支持

8月24日至25日，云原生安全与供应链治理三条主线同时收紧。Google Cloud在8月集中修补GKE四个关键漏洞——三个位于容器运行时containerd，一个深达Linux内核的Fragnesia漏洞允许容器内攻击者直接逃逸为宿主机root；Flux社区发布Flux Mirror插件，以声明式配置实现容器镜像、Helm Chart和OCI制品在注册表间的可验证镜像同步，被定位为”无Git的GitOps”基础设施；Kubernetes SIG Network于3月24日正式归档ingress-nginx仓库，O3 Security 8月7日的研究显示该CVSS 8.8配置注入漏洞仍在大量生产集群中未修补，且从此再无官方补丁。

主要新闻

GKE容器逃逸漏洞集群：containerd、Fragnesia与运行时层的攻击面回归

据安全研究媒体Shattered报道，Google Cloud在整个8月密集披露并修补了四个分别影响GKE节点的关键CVE。其中最具威胁的是CVE-2026-46300（代号Fragnesia），这是一个Linux内核XFRM ESP-in-TCP路径中的本地提权漏洞——攻击者一旦进入容器，无需任何Kubernetes策略误配或泄露的凭证，即可利用内核skb_try_coalesce()函数中的缺陷将任意字节写入只读文件的页缓存，包括宿主机上受信任的特权二进制文件，等待其以root执行即完成逃逸。Red Hat将该漏洞评为高影响。另外三个containerd漏洞（CVE-2026-50195、CVE-2026-53488、CVE-2026-53492）均与checkpoint/restore功能相关，最高CVSS达9.6，可实现跨Pod代码执行和镜像缓存投毒。值得注意的是，运行Container-Optimized OS（COS）节点和Autopilot集群的GKE部署不受Fragnesia影响，暴露面集中在使用Ubuntu节点镜像的Standard集群。同期，微软披露了Azure Kubernetes Service的CVE-2026-50516（缺失认证漏洞，CVSS估算高达9.8），INGRESS-NGINX的CVE-2026-4342在披露五个月后仍有大量未修补集群——三大托管Kubernetes平台在同一窗口期存在关键或近关键漏洞，构成了对”云提供商替你打补丁”这一承诺的直接压力测试。

Source: GKE Containerd CVEs Hit 9.6 CVSS, Fragnesia Roots Nodes

Flux Mirror：声明式镜像治理走向”无Git的GitOps”

Flux社区于8月20日发布Flux Mirror插件（Flux v2.9 CLI插件系统的一部分），提供从声明式配置出发在容器注册表间同步容器镜像、Helm Chart和OCI制品的能力。该插件的核心设计理念是让Kubernetes集群仅从团队自运营的注册表中进行reconciliation，而不依赖外部公共注册表。此前，Docker Hub的速率限制事件和Broadcom在2025年冻结免费Bitnami目录等事件已反复证明：外部注册表的策略随时可能成为生产架构的一部分。Flux Mirror将HTTP Helm Chart重新发布为确定性的OCI制品，支持Cosign签名验证、SBOM传递、构建来源追踪，以及基于正则表达式、语义版本约束和”最小制品年龄”策略的镜像选择管线——新签名的制品必须经过足够长的公开时间才能被镜像到生产注册表。该设计直接回应了2026年供应链攻击加速的趋势，包括Shai Hulud蠕虫攻击波次和Aqua Security的Trivy GitHub Action被攻破事件。Chainguard的数据也显示，大多数容器CVE实例出现在非头部的长尾镜像中而非前二十最受欢迎的镜像，进一步印证了将”签名且经过年龄验证的制品”作为软件供应链单向隔离二极管的思路。

Source: Flux Mirror Uses Gitless GitOps to Keep Software Supply Chain Under Control

Ingress-NGINX仓库归档五个月：CVSS 8.8漏洞仍在生产中潜伏

Ingress-NGINX——全球约半数Kubernetes集群使用的流量入口控制器——于2026年3月24日在GitHub上被Kubernetes SIG Network正式归档，仓库变为只读状态，此后不再有任何发布、Bug修复或安全更新。CVE-2026-4342（CVSS 8.8配置注入漏洞）是该项目收到的最后一个安全补丁（3月19日发布于1.13.9、1.14.5和1.15.1版本），但O3 Security于8月7日发布的研究显示，大量生产集群从未应用该修复。五个月的公开漏洞利用细节已足够攻击者充分开发针对性工具。与此同时，Kubernetes 1.37正在上游进入发布周期——AKS预计9月预览、10月正式发布——版本升级为平台团队提供了审计ingress控制器和存储附加组件的天然窗口。Microsoft Defender for Cloud在7-8月的更新中已将Kubernetes节点漏洞扫描从AKS扩展至EKS和GKE，AWS和Google预计将在2027年初跟进跨云扫描能力。对平台团队的明确建议是：任何仍在使用pre-1.13.9、pre-1.14.5或pre-1.15.1版本ingress-nginx的集群应立即制定迁移至替代方案（如Envoy Gateway或Traefik）的时间表，因为不会有第二次补丁机会。

Source: Ingress-NGINX EOL: CVE-2026-4342 Still Unpatched

分析

GKE漏洞集群的核心教训是：Kubernetes在2026年最大的攻击面已从控制平面转移到运行时层。Fragnesia的利用不需要任何K8s RBAC误配——它只需要一个能够执行本地代码的容器，这在多租户环境中几乎不可能完全禁用。containerd的三个checkpoint/restore漏洞则暴露了一个更深层的设计张力：为提高调度弹性和故障恢复能力而引入的容器快照/恢复机制，恰恰创造了跨Pod攻击路径。对平台团队的启示是：应将容器运行时版本审计纳入CI/CD管线的常规检查（而非季度人工审查），并在生产环境中默认禁用checkpoint/restore和CDI设备注入功能，除非有明确的业务需求。

Flux Mirror代表了GitOps实践中”源码即真相”理念向”注册表即真相”的延伸。传统的GitOps以Git仓库作为desired state的唯一来源，集群通过reconciliation循环将其同步到实际状态。Flux Mirror在此之上增加了一层制品来源治理——将外部注册表的不可控性封装为声明式的镜像管线，并通过签名验证和最小年龄策略构建了制品层面的”零信任”。这与Nebius、CoreWeave等AI基础设施运营商对供应链完整性的需求高度契合：当Kubernetes集群正在承载AI训练和推理工作负载时，输入模型训练流水线的容器镜像和数据制品的来源可验证性直接影响输出模型的可信度。

Ingress-NGINX的EOL故事则为”开源组件生命周期管理”提供了一个反面教材：一个直接暴露在互联网和集群内部服务之间的组件，在被归档前仅获得了五天的修复窗口。当Kubernetes 1.37的升级周期为平台团队提供了审计附加组件版本的天然时机，应当将ingress控制器、CSI驱动和admission webhook的版本检查提升到与控制平面同等的优先级。

结论

8月下旬的云原生安全动态共同指向”运行时层治理”的紧迫性：Fragnesia和containerd漏洞集群要求将容器运行时版本审计自动化为CI/CD管线的标准检查；Flux Mirror为制品来源治理提供了可落地的声明式方案；Ingress-NGINX的永久EOL则要求所有仍在使用该控制器的集群立即启动迁移。对平台团队的建议是：（1）按节点OS镜像盘点所有GKE节点池并应用Fragnesia补丁，同时跨集群审计containerd版本；（2）将Flux Mirror等制品镜像工具纳入软件供应链安全策略；（3）在Kubernetes 1.37升级窗口中将ingress-nginx替换列为高优先级迁移项目。