Containers are generally considered as a robust security isolation boundary and are widely used to isolate workloads across enterprise and cloud environments.
As AI accelerates kernel vulnerability discovery and exploitation, the barrier to escaping containers by attacking kernel has fallen so significantly that we must assume attackers can do so at will. There are nearly 6000 kernel CVEs published as of September 2026.
They’ve been treated that way but Linux containers never offered a robust security boundary and strong isolation.
Security experts and major cloud providers stated clearly for years that Linux containers are not a strong boundary against a determined attacker and should never be treated as such.
Yeah.
In project config, I’m planning to set limits.containers = 0, which will disable containers for that project, for all less trusted users.
For stuff like Docker or Kubernetes, I am planning to use microvms (which are virtual machine based container runtimes), or gvisor, which is google’s reimplementation of parts of the Linux kernel in Go. Both of those isolate a process from the host kernel, offering a real security boundary, and they are popular in cloud provider setups.
speaking of microvms, the Kata runtime is doing exactly that – might be interesting to check out: GitHub - kata-containers/kata-containers: Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/ · GitHub
Ok. Thanks for the link. I’m reading and listening, the general point and reasoning regarding the extended attack surface of sharing the kernel is sound.
However, at the same time, lets keep in mind that there is a lot of hype and overblown statements that ultimately serve to line up pockets of tech oligarchs that own “security”, “ai” and general bigtech corporations. Greg Kroah-Hartman called bullshit on most of those CVEs:
@stgraber What do you think ?
The sky is not falling and there’s no impending doom.
As with any technology, know your risk profile and know your security requirements/obligations and don’t run unverified code on critical infrastructure.
There’s nothing new really here. Containers have always been at risk of local privilege escalation issues with the only real mitigation being the immediate rollout of the relevant fix.
That’s why IncusOS tracks mainline stable releases very closely and images are typically available within 24h so folks can quickly roll them out.
If you’re using unprivileged containers to run software/services that you’d otherwise run directly on the server, you’re not any worse off, especially if there is no easy path to root inside the container.
That applies to most infrastructures using unprivileged containers internally for resource isolation and general convenience.
Where things get more problematic, but again, not really a new problem, is if you’re providing root access to unprivileged containers to untrusted users. That’s the very dangerous case as those local privilege escalations bugs can be used to do some serious long term harm.
But that’s not a new problem, what’s new is the frequency at which the problem manifests. In practive most multi-tenant environments and effectivelly all cloud/VPS platforms have been using virtualization for cross-tenant isolation.
Either exclusively working with virtual machines, or operating a nested environment where tenant isolation is achieved through virtual machines, but tenants can use containers within that environment for effeciency.
I imagine some of the concerns regarding container exposure to the same resources the hypervisor runs on will be mitigated when/if PR 1360 lands.
