On August 27, 2026, CISA added another Linux kernel vulnerability to its Known Exploited Vulnerabilities catalog.
CVE-2026-53362, nicknamed "Frag Gap." An out-of-bounds write in the IPv6 fragmentation path.
CVSS 7.8.
Already being exploited in the wild.
When news like this shows up, I've noticed engineers around me split into two camps.
One says "we run everything in Kubernetes, so this doesn't really touch us." The other camp skims the headline and moves on within a few seconds.
Looking back, both end up at the same blind spot.
I'll admit it honestly: for a long time, I was closer to the first camp.
I don't think this assumption comes from carelessness.
It's closer to a structural misunderstanding that container tooling quietly plants in you, precisely because it's so well engineered.
Part of it is just over-trust in the word "isolation." Containers get described as "lightweight VMs" or "fully independent environments," and that framing pairs nicely with how disposable they feel (something breaks, you just throw the container away) until you genuinely believe nothing that happens inside can ever reach outside.
Carrying over habits from hypervisor-based virtual machines doesn't help either.
A traditional VM (an EC2 instance, VMware, VirtualBox) really does have its guest kernel physically separated from the host by a hypervisor.
Keep that mental model and move to Docker or Kubernetes, and it feels obvious that "breaking out of a container to affect the host" simply isn't a thing.
And then there's infrastructure-as-code quietly making the base OS invisible.
A developer today can write a Dockerfile, build it in CI, and ship to a managed container platform without ever touching the underlying Linux kernel directly.
Something you never interact with is easy to stop thinking about entirely.
But a container is not an operating system.
It's not a virtual machine emulating separate hardware and booting an entirely different kernel.
The Linux kernel a container uses is the exact same, single kernel the host is running.
Namespaces restrict what a process can see.
They don't give each container its own copy of the kernel to run code against.
Every process, containerized or not, ultimately lands in the same kernel space.
If a VM is a standalone house with its own foundation, a container is more like a room in a shared house.
Your room is walled off and comfortable, and you can't see what your housemates are doing.
But the plumbing running under the floor, the kernel, is shared by everyone in the building.
Crack that pipe, and it doesn't matter how tidy your own room is; the whole house floods.
Understanding this on an intellectual level is one thing.
Actually feeling, in your gut, that "a process inside a container can reach in and directly corrupt the host's kernel memory" is another.
Firewalled.
Containerized.
Isolated.
Layer these reassurances on top of each other long enough, and your attention quietly drifts away from the one-piece-of-rock kernel sitting underneath all of it.
Frag Gap is dangerous precisely because it exploits that blind spot.
The attack never starts with the kernel bug itself.
It starts with a foothold: a vulnerable web app, a poisoned npm package, a stolen SSH key — anything that gets you unprivileged code execution somewhere.
From there, if that process can create a UDP socket (which almost none of them are prevented from doing), it can abuse IPv6 fragment handling to overwrite kernel memory directly and walk straight out of the container onto the host, as root.
And because this attack rewrites trust structures inside the kernel itself, it takes SELinux-style mandatory access control down with it.
Two defensive lines a lot of teams lean on ("we're containerized" and "we have SELinux enforcing") go dark in the same instant.
I build a defensive security app for Linux (RoamSwitch) as an independent developer, and following this story, I went back to my own code in a bit of a panic.
Sure enough, most of my existing pr