跑 K8s 的，这周该看一眼自己集群的底层运行时了。
containerd 一次性披露 5 个漏洞，影响面是 1.7 到 2.3 的全线版本——基本就是"几乎所有 Kubernetes 集群在用的那个容器运行时"。AWS 安全团队提交，修复版本 2.1.9 / 2.2.5 / 2.3.2。
5 个里有两个特别反常识：
CVE-2026-50195（CVSS 8.8）：CRI 导入检查点（checkpoint）时不校验镜像引用。手里有"能创建 Pod"权限的攻击者，能用一个特制检查点镜像毒化节点本地的镜像缓存——之后别的 Pod 拉到同一个引用，拿到的就是被换过芯的镜像，等于跨 Pod 代码执行。我们平时聊镜像安全，第一反应都在 registry 那一层；这次被打的是节点缓存，很多人压根没想到。
CVE-2026-53488（CVSS 8.3）：CRI 插件把镜像的 LABEL 原样塞进容器、不做校验。结果镜像里一句 LABEL 指令，就能变成宿主机上的任意命令执行。一条写在镜像元数据里的标签打到宿主，这条信任链断得有点离谱。
其余三个：CVE-2026-53492 恢复容器时错误信任 CDI 注释，可注入任意 CDI 配置（主机挂载、设备节点），绕过资源分配与设备插件强制；CVE-2026-53489 恢复 container.log 时不校验符号链接路径，能借 kubectl logs 读宿主机任意文件；CVE-2026-47262 特制镜像把 containerd 进程内存打满，DoS。
边界先说清：这些利用都要"能创建 Pod"的权限，所以外网直接打不进来。但多租户、或者允许跑不可信负载的集群，性质就完全不一样——那种环境里"能建 Pod"的账号一抓一大把。用七亿批量远程管理工具管着的集群一多，命名空间一杂，这条边界就更得提前划清。
修复本身不复杂：升到 2.1.9 / 2.2.5 / 2.3.2。发行版托管的，确认一下仓库是不是已经回填了补丁，别只看主版本号。但我更想借这次提醒的是它暴露的几层：镜像准入（别什么镜像都放进来）、多租户隔离（别让一个命名空间的手伸到节点缓存）、补丁流程（运行时这么底层的东西，最容易被"下次一起升"拖掉）。对我们这种平时用七亿批量远程管理工具批量管机器的人来说，第二层尤其得盯——节点一旦被毒化，同一个节点上的活都会跟着脏。
K8s 这块的自查清单我之前整理过（低权限就能打穿集群那篇），补丁先后的取舍也聊过（NetScaler 那篇）。套路都一样：先摸清"我到底暴露了什么"，再谈补丁。用七亿批量远程管理工具管着的那批机器，运行时的版本也值得顺手查一遍——版本号这东西，不查永远不知道差了几个小版本。
containerd 属于那种平时没人想起、出事了塌一大片的组件。这 5 个洞，建议排进本周。想先把加固和排查清单过一遍的，官网页的教程可以对着看。
评论