A couple of weeks ago, I wrote about Copy-Fail (CVE-2026-31431) and how Red Hat OpenShift’s defense-in-depth approach prevented container escape despite a vulnerable kernel. I spent time actively trying to break out of an OpenShift container, achieved root inside the pod almost immediately, and still couldn’t escape to the host. The kernel vulnerability was real. The exploit path was real. The defenses still held. While I was wrapping up this article, another related variant, DirtyDecrypt (CVE-2026-31635), started circulating publicly alongside exploit discussion and proof-of-concept coverage. At that point, we were looking at 4 major Linux privilege escalation vulnerabilities in roughly 14 days, all abusing variations of the same broader pattern.That’s the part that matters most to me.At a certain point, you stop looking at these as isolated CVEs and start recognizing a systemic issue. Different subsystems. Different exploit paths. Same underlying concept: manipulate copy-on-write behavior inside the kernel page cache, corrupt supposedly immutable files, and escalate privileges.If you’re running production infrastructure right now, that realization changes the conversation pretty quickly. Chasing individual CVEs 1 at a time starts feeling less like a security strategy and more like trying to catch snowflakes with your tongue during an avalanche. The end result is not pretty. What matters is whether your architecture remains resilient when the next variant inevitably appears.Because at this point, it probably will.Different CVEs, same patternOver the past 2 weeks, researchers have disclosed multiple related vulnerabilities: Copy-Fail targeting general page cache manipulation, Dirty Frag moving into ESP/XFRM and RxRPC paths, Fragnesia targeting ESP-in-TCP, and now DirtyDecrypt surfacing publicly around rxgk. The implementation details vary, but the broader exploitation philosophy stays remarkably consistent. Researchers find a conceptual weakness in one area of kernel networking code, then begin tracing adjacent subsystems looking for similar assumptions and missing safeguards. Increasingly, they’re finding them.That recurring pattern concerns me more than any individual CVE number.I spun up a ROSA cluster and decided to test Fragnesia directly against OpenShift. The cluster was running OpenShift 4.21.15 on Red Hat Enterprise Linux (RHEL) CoreOS 9.6 with a vulnerable 5.14.0-570.113.1.el9_6.x86_64 kernel. The vulnerable subsystem was present. Theoretically, the environment should have been exploitable.What I wanted to understand wasn’t simply whether the kernel was vulnerable. We already knew that. I wanted to see where the exploitation chain would actually break under different security configurations.First, I deployed a completely standard pod with default OpenShift protections. Nothing fancy. No elevated privileges. No relaxed SCCs. Just a vanilla Fedora container running sleep infinity.The exploit chain failed almost immediately.User namespace creation was blocked before the attack could meaningfully progress. The vulnerable subsystem still existed, but the container never gained the capabilities necessary to reach the dangerous code path in the first place. OpenShift’s default security context constraints (SCCs) combined with SELinux enforcement shut the door before the exploit ever really started moving.That part wasn’t surprising.What interested me more was the next scenario, the kind of configuration a lot of real organizations actually run.I created a workload using the anyuid SCC and explicitly ran the container as user id (UID) 0. This is extremely common in brownfield environments—an existing environment where legacy applications were never designed around the concept of least privilege and organizations often compromise because, "the app needs it."Inside the pod, I had root.The exploit chain still failed.Even with anyuid, SELinux continued enforcing the container_t domain restrictions preventing the namespace operations required to continue escalation. That’s the part I think people often miss about OpenShift’s model, the security layers are intentionally overlapping. Relaxing one control does not automatically dissolve the rest of the boundary.At that point I decided to stop being reasonable.I built a deliberately dangerous configuration with privileged SCC, root user, and unconfined seccomp. This is about as permissive as you can realistically make an OpenShift workload without simply handing the host over directly.And finally, things started moving.User namespaces worked. unshare -U succeeded. The exploit chain began progressing in ways the previous scenarios never allowed. On many Kubernetes distributions, this is roughly where the story transitions from "security research" into "incident response."But the exploit still failed.Fragnesia doesn’t just require namespace creation. It requires successful UID/GID mapping inside the namespace so the attacker can obtain the capabilities necessary to access the vulnerable networking paths.That final step got blocked.Even with privileged SCC, root, and unconfined seccomp, SELinux still denied writes to /proc/self/uid_map. Without successful UID mapping, the escalation chain collapsed. No namespace-root privileges meant no XFRM/ESP access. No subsystem access meant no page cache corruption.The kernel remained vulnerable the entire time but the exploit still failed. That distinction matters.What the testing reinforced for me is something I’ve believed for a long time: good defense in depth remains valuable specifically when things go wrong. Not when everything is perfectly configured. Not when all workloads are pristine and least-privileged and security teams get everything they want. Real environments are messy. Controls get relaxed. Legacy workloads exist. Operational compromises happen constantly.The question is whether the architecture still holds together after some of those compromises occur.In this case, it did.Even after weakening multiple security layers simultaneously, SELinux still treated the container as fundamentally untrusted and prevented the final privilege escalation step required to complete exploitation.That’s the difference between "security features" and a coherent security architecture. That broader architectural conversation matters more to me than the individual Fragnesia CVE itself. Because if the last few weeks have shown us anything, it’s that this vulnerability family is probably not finished evolving yet.The operational question organizations need to start asking themselves is no longer, "Have we patched CVE-2026-46300?"The real question is, "What happens operationally when CVE-2026-XXXXX drops next Tuesday targeting another subsystem nobody was watching yet?"The exploit evolves. The signals don'tAnd let’s be real here… at this point, that no longer feels hypothetical.This is also where I think Red Hat Advanced Cluster Security for Kubernetes becomes significantly more valuable than simple CVE-driven thinking. The interesting part about Red Hat Advanced Cluster Security in this context isn’t that it knows about Fragnesia specifically, it’s that the behavioral patterns surrounding these exploit chains are often recognizable even when the exact vulnerability changes.A web application container suddenly creating user namespaces is unusual. An application workload executing /bin/su is unusual. Those signals remain interesting regardless of whether the exploit is called Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, or whatever branding researchers come up with next week.The CVE changes, but in these cases, the behavior doesn’t.That matters because disclosure cycles are moving faster than many organizations can realistically patch large fleets without introducing operational instability. Architecture and behavioral visibility buy you time. Sometimes that time is the difference between executing a controlled remediation plan and spending the next 18 hours trapped on an incident bridge wondering which clusters are exposed.The same thing applies operationally at fleet scale.Testing 3 pods in a lab is easy. Coordinating policy changes across dozens or hundreds of clusters while production workloads remain online is a completely different problem. That’s where Red Hat Advanced Cluster Management for Kubernetes changes the conversation from reactive scrambling into governed rollout. Instead of manually auditing clusters one at a time, manually identifying dangerous configurations, and manually coordinating security posture changes across teams, you establish consistent policy centrally and propagate it everywhere at once.That distinction becomes critically important when new variants are appearing every few days.On my Red Hat OpenShift on AWS (ROSA) cluster, the kernel stayed vulnerable throughout the testing. The vulnerable subsystems remained present. The exploit prerequisites technically existed.The exploitation chain still kept collapsing because layered controls interrupted escalation at multiple points.Then DirtyDecrypt started circulating publicly while I was still writing this article.Same broader exploitation philosophy. Different subsystem. Same defenses already holding.That’s not luck. That is architecture. That’s defense in depth.Learn moreWhen AI finds the bugs: Why defense in depth was always the answerTry OpenShift for freeLearn more about OpenShift Platform Plus