[benatkin]

No, but Podman is. The recent escapes at the actual container level have been pretty edge case. It's been some years since a general container escape has been found. Docker's CVE-2025-9074 was totally unnecessary and due to Docker being Docker.

[eyberg]

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.

[jrpear]

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...

[xienze]

The best container security in the world isn’t going to help you when the agent has credentials to third party services. Frankly, I don’t think bad actors care that much about exploiting agents to rm -rf /. It’s much more valuable to have your Google tokens or AWS credentials.