Comment by eyberg
14 hours ago
No they have not been. There were at least 16 container escapes last year - at least 8 of them were at the runtime layer.
I personally spent way too much time looking at this in the past month:
https://nanovms.com/blog/last-year-in-container-security
runc: https://www.cve.org/CVERecord?id=CVE-2025-31133
nvidia: https://www.cve.org/CVERecord?id=CVE-2025-23266
runc: https://www.cve.org/CVERecord?id=CVE-2025-52565
youki: https://www.cve.org/CVERecord?id=CVE-2025-54867
Also, last time I checked podman uses runc by default.
It looks to me like what is called a "container escape" in this context isn't necessarily as bad as it seems. For example, in the advisory for CVE-2025-31133 affecting runc[1]:
> Container Escape: ...Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.
Sounds bad. But...
> this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.
The attacker needs already to have the capability to spawn containers! This isn't a case of "RCE within the container" -> "RCE outside the container", which is what I would think prima facie reading "container escape".
I have always thought that running an untrusted image within an unprivileged container was a safe thing to do and I still believe so.
[1] https://github.com/opencontainers/runc/security/advisories/G...