Two page cache CVEs in two weeks. CISA deadline in 2 days. And most Kubernetes clusters still running unpatched kernels. At Tech86, we've been tracking this closely because it confirms something we've been saying for a long time: containers are not security boundaries. The Linux kernel's shared page cache is the weak link that collapses this premise — and CopyFail and DirtyFrag are the definitive proof.
CopyFail: 4 bytes that compromise a cluster
CVE-2026-31431 exploits a bug in the Linux kernel's crypto subsystem, specifically in algif_aead. The result: a controlled 4-byte write into the page cache of any readable file on the system. The bug has been present since 2017 — nearly a decade of exposed attack surface.
What makes CopyFail particularly dangerous is the simplicity of the exploit. The PoC is 732 bytes of Python. It's deterministic: no race condition, no timing window, no need for precision. It works on Ubuntu, RHEL, Debian, and Amazon Linux without any modification. In a Kubernetes cluster, the scenario is devastating: an unprivileged pod corrupts the page cache of a shared binary. Kube-proxy executes that corrupted binary during reconciliation. Ten seconds. No human interaction. Cluster compromised. We validated this chain on EKS, GKE, AKS, and Alibaba Cloud ACK — all four major managed providers are vulnerable.
CISA added CopyFail to the Known Exploited Vulnerabilities (KEV) catalog with a deadline of May 15. When we wrote this article, there were 2 days left. Most clusters had not yet applied the patch.
DirtyFrag: two variants, same class
CVE-2026-43284 and CVE-2026-43500 form DirtyFrag — two chained variants exploiting the kernel's ESP (esp4/esp6) and RxRPC subsystems. Same vulnerability class: page cache write primitive. Discovered by Hyunwoo Kim, the embargo was broken on May 7, with a public PoC available on GitHub.
Patches were merged quickly: ESP on May 7, RxRPC on May 10. Kernel 7.0.6 includes both. But here's the real problem: most production servers run distribution kernels — Ubuntu 6.17, RHEL 6.12, Amazon Linux 6.12. These kernels haven't received the patches through the conventional update channel yet. The patch exists upstream, but it hasn't reached your cluster's nodes.
Microsoft confirmed in-the-wild exploitation. GKE published bulletin GCP-2026-030. AKS deployed hotfixes for both variants. This is no longer a theoretical exercise — adversaries are actively using these vulnerabilities.
The structural problem: page cache is shared
Dirty Pipe (2022). CopyFail (2026). DirtyFrag (2026). Three vulnerabilities, same class, same subsystem. Page cache write primitive. The pattern is clear — and ignoring it is negligence.
The Linux kernel's page cache is shared among all processes on the system. Containers on the same node share this cache via overlayfs. There is no page cache isolation between containers. When a process in one container writes to the page cache, that write is visible to all other containers on the same node. That's how the kernel works by design.
Bruce Schneier published a piece on this: in 2026, the concept of "local" is misleading. Every container, every CI/CD job, every WSL2 instance, every AI agent with shell access — they all share a kernel. A page cache LPE collapses the boundary between workloads. The premise that containers isolate applications is false. They isolate namespaces, but the kernel — and especially the page cache — is shared territory.
Why patches don't solve the problem
The industry's standard response is "apply the patch." But patches are reactive by nature. Every new page cache write primitive discovered requires a new patch, a new deploy cycle, a new maintenance window. Meanwhile, adversaries operate at the speed of public PoCs.
The problem runs deeper. The Linux kernel was not designed with page cache isolation between containers in mind. Every subsystem that interacts with the page cache — crypto, networking, filesystem — is a potential attack surface. Patches fix individual bugs, but they don't change the fundamental architecture. As long as containers share the same kernel and the same page cache, this class of vulnerability will keep appearing.
At Tech86, we've watched this dynamic repeat. We apply security patches to our clusters within hours, not days. But we know the next Dirty Pipe, the next CopyFail, the next DirtyFrag is on its way. The fix isn't more patches. It's architecture.
Defense in depth: what actually works
Protection against page cache exploits requires layers. The first is Pod Security Standards in the Restricted profile, with allowPrivilegeEscalation: false mandatory. This doesn't prevent page cache corruption, but it blocks the final escalation — the moment an attacker turns file corruption into privileged code execution.
The second layer is kernel attack surface reduction. Modules like esp4, esp6, and rxrpc should be blocked if they're not needed. Fewer loaded subsystems, fewer exploitation vectors. The third layer is real kernel isolation: GKE Sandbox with gVisor, or Kata Containers, which run each pod in a separate virtualized kernel. GKE itself explicitly recommends not relying on containers as a security boundary.
The fourth layer is monitoring. Detecting page cache corruption is difficult, but anomalous behavior — like a pod attempting to access system files outside its overlay — can be caught with custom seccomp profiles and runtime security tools like Falco.
Architecture is the fix
At Tech86, we design Kubernetes with defense in depth from the start. Custom seccomp per workload. Pod Security Standards Restricted as the default, not the exception. Nodes with kernels updated in hours, not weeks. And for workloads that demand real isolation, we offer environments with dedicated kernels — because we know containers alone aren't enough.
If your Kubernetes cluster still relies on the premise that containers isolate workloads, it's time to rethink your architecture. CopyFail and DirtyFrag demonstrated that this premise doesn't hold. The next page cache write primitive is being discovered right now. The question isn't whether it will appear, but whether your cluster will be ready when it does.
Explore our Managed Cloud and see how we operate Kubernetes with the security layers this reality demands.