几周前，我撰写了一篇关于 Copy-Fail（CVE-2026-31431）的文章，探讨了红帽 OpenShift 如何通过深度防御方法，在内核存在漏洞的情况下仍成功阻止了容器逃逸。我花了一些时间亲自尝试突破 OpenShift 容器，几乎立即就在容器集内获得 root 权限，却始终无法逃逸到主机。内核漏洞真实存在，漏洞利用路径也完全可行，但防御体系依然坚不可摧。
就在我完成这篇文章之际，另一款同类衍生漏洞 DirtyDecrypt（CVE-2026-31635）开始公开流传，相关漏洞利用讨论与概念验证代码也随之曝光。当时，短短 14 天内就出现了四个重大的 Linux 特权提升漏洞，而且它们都是利用了同一种更广泛的攻击模式的各种变体。
这才是最令我感到担忧的地方。
到了这个阶段，您已不能再将这些漏洞视为孤立的 CVE 条目，而是要意识到这是一个系统性问题。涉及的子系统各不相同，攻击路径也各有差异，但底层逻辑完全一致：操纵内核页面缓存内的写时复制行为，篡改本应不可修改的文件，最终实现特权提升。
如果您现在正在运行生产基础架构，这一认知会迅速改变讨论的方向。逐个修补 CVE 漏洞已不再像是一种安全策略，倒更像是在雪崩时试图用舌头接住每一片雪花。其结果往往不堪设想。
重要的是，当下一个漏洞变体不可避免地出现时，您的架构是否仍具有弹性。
就目前态势来看，这类新漏洞几乎一定会接踵而至。
不同 CVE，同一模式
在过去的两周里，研究人员披露了多个相关漏洞：Copy-Fail 以一般页面缓存操作为目标，Dirty Frag 深入 ESP/XFRM 和 RxRPC 路径，Fragnesia 瞄准 ESP-in-TCP，而如今 DirtyDecrypt 又围绕 rxgk 公开曝光。实施细节各不相同，但其更广泛的漏洞利用思路却惊人地一致。研究人员发现内核网络代码的一个区域存在概念性弱点，然后开始跟踪相邻的子系统，以寻找类似的假设和缺失的防护机制。而且，他们越来越多地找到了同类问题。
相比任何一个具体的 CVE 编号，这种反复出现的模式更让我担忧。
我搭建了一个 ROSA 集群，并决定直接针对 OpenShift 测试 Fragnesia 漏洞。该集群在红帽企业 Linux（RHEL）CoreOS 9.6 上运行 OpenShift 4.21.15，该系统搭载存在漏洞的 5.14.0-570.113.1.el9_6.x86_64 内核。易受攻击的子系统和内核一应俱全。从理论上讲，该环境本应是可利用的。
我想弄清楚的不仅仅是内核是否存在漏洞，这一点我们早已知晓。我真正想验证的是，在不同的安全配置下，攻击链究竟会在哪个节点被阻断。
首先，我部署了一个完全标准的容器集，采用 OpenShift 默认安全防护措施。没有任何特殊设置，未授予升级特权，也未放宽任何安全上下文约束（SCC）。只是一个运行 sleep infinity 命令的原生 Fedora 容器。
结果，该攻击链几乎在第一时间就失败了。
攻击尚未取得实质性进展，用户命名空间的创建就已被拦截。虽然存在漏洞的子系统依然存在，但容器从一开始就未能获得进入危险代码路径所需的功能。OpenShift 的默认安全上下文约束（SCC）与 SELinux 强制策略相结合，在漏洞利用流程正式启动前就阻断了攻击路径。
这一结果并不令人意外。
更让我感兴趣的是下一个场景，这也正是许多真实企业组织实际运行的配置。
我使用 anyuid SCC 创建了一个工作负载，并明确以用户 ID（UID）0 身份运行该容器。这在棕地环境中极为常见，这类现有环境中的传统应用在设计时并未遵循最小特权原则，而企业组织往往因为“应用需要此权限”而做出妥协。
在容器集内部，我确实拥有了 root 权限。
然而，攻击链依然失败了。
即便启用了 anyuid，SELinux 也继续执行 container_t 域限制，阻止了继续提权所需的命名空间操作。我认为这是人们经常忽略的 OpenShift 模型的关键一点：各安全防护层有意设计为相互重叠，放宽某一层控制，并不会自动瓦解其余的边界防护。
至此，我决定不再循规蹈矩。
我故意构建了一个危险配置：启用特权 SCC、以 root 用户身份运行，并解除 seccomp 限制。这几乎是在不直接将主机控制权拱手相让的前提下，能为 OpenShift 工作负载赋予的最高权限组合。
终于，攻击链开始有了实质性进展。
用户命名空间创建成功，unshare -U 命令顺利执行。攻击链开始以之前所有场景都无法实现的方式推进。在许多 Kubernetes 发行版中，到这一步，事件性质就已经从“安全研究”直接升级为“安全事件响应”级别。
但攻击依然失败了。
利用 Fragnesia 漏洞不只是需要创建命名空间，还必须在命名空间内成功完成 UID/GID 映射，攻击者才能获得访问存在漏洞的网络路径所需的权限能力。
而这最后一步被阻断了。
即便已经启用特权 SCC、获得 root 权限并解除 seccomp 限制，SELinux 仍然拒绝写入 /proc/self/uid_map。由于 UID 映射未成功，权限提升链就此崩溃。没有命名空间内的 root 特权，就无法访问 XFRM/ESP 子系统；无法访问该子系统，也就无从破坏页面缓存。
在整个测试过程中，内核自始至终都存在漏洞，但攻击依然失败了。这种区别至关重要。
本次测试进一步印证了我长期以来的信念：完善的深度防御体系，恰恰是在出现问题时才能凸显其价值。它的意义不在于一切配置完美无缺、所有工作负载都纯净无隐患、遵循最小特权原则，以及安全团队的一切诉求都得到满足。现实环境往往杂乱无章：安全控制会被放宽，传统工作负载普遍存在，运维层面的妥协更是司空见惯。
关键在于，在经历部分妥协之后，架构是否依然能够保持完整。
在此次测试中，答案是肯定的。
即便在同时弱化多个安全防护层之后，SELinux 仍然将容器视为本质上不可信的主体，并阻断了完成攻击所需的最后一步权限提升。
这正是“安全功能”与完整安全架构之间的区别。对我而言，这种更广泛的安全架构层面的讨论，比 Fragnesia 这一特定 CVE 本身更为重要。过去几周出现的一系列同类漏洞已经说明，该类漏洞系列很可能还会衍生出新的变体。
企业组织需要开始思考的运维问题，不再是“我们是否已经修复 CVE-2026-46300？”真正的问题是，“当下周二出现针对另一个无人关注子系统的 CVE-2026-XXXXX 时，我们的运维体系能否有效应对？”
攻击手段不断演变，但异常特征始终不变
坦白说，到此阶段，这已不再是一个假设性的问题。
在我看来，这也正是红帽 Kubernetes 高级集群安全防护比单纯的 CVE 驱动思维更有价值的地方。在此场景下，红帽高级集群安全防护的亮点并不在于知悉 Fragnesia 这一特定漏洞，而在于即便具体漏洞发生更迭，平台仍可识别出这类攻击链对应的行为模式。
Web 应用容器突然创建用户命名空间，属于异常行为；应用工作负载执行 /bin/su，同样十分可疑。无论漏洞被称为 Copy Fail、Dirty Frag、Fragnesia、DirtyDecrypt，还是研究人员下周想出的任何新名称，这些异常特征依然值得关注。
CVE 在不断变化，但在这些案例中，行为模式并未改变。
这一点至关重要，因为漏洞披露周期的节奏越来越快，许多企业组织根本无法在不引发运维不稳定性的前提下，为大规模集群及时完成修复。架构和行为可见性可为您争取时间。有时这段缓冲期，决定了您是从容执行可控修复方案，还是连续 18 小时守在应急工作中，逐一排查受影响集群。
同样的逻辑在大规模集群的运维中也完全适用。
在实验室中测试三个容器集非常简单。在生产工作负载保持在线的情况下，跨数十个或数百个集群协调策略更改，完全是另一道难题。这正是红帽 Kubernetes 高级集群管理的价值所在，它能将应对方式从被动应对转变为受控部署。您无需再手动逐个审核集群、识别危险配置，以及跨团队协调安全态势变更，而是可以集中制定一致的策略，并将其一次性推广到所有集群。
当新变体每隔几天就出现的当下，这一能力变得至关重要。
在我的 AWS 上的红帽 OpenShift（ROSA）集群上，内核在整个测试过程中始终存在漏洞。易受攻击的子系统依然存在。从技术上讲，利用漏洞的先决条件也已具备。
但攻击链仍然屡屡受阻，因为分层控制措施在多个节点阻断了权限提升。
在我撰写这篇文章的过程中，DirtyDecrypt 漏洞开始公开流传。
攻击思路大同小异，只是换了一个子系统。现有的防御措施依然有效。
这并非运气使然，而是架构设计的成果。这就是深度防御。
了解更多
关于作者
Sean Rickerd, a distinguished professional in the technology and security domain, seamlessly blends his extensive career journey with a commitment to excellence. From his early days at SUSE to his current role as Principal Technical Marketing Manager at Red Hat, Sean's writing reflects a dedication to continuous learning. With a focus on authoring about cutting-edge fields like DevSecOps and Kubernetes security, he stands at the forefront of driving innovation and elevating security practices.
