Podman rootless containers and the Copy Fail exploit
ggpsv
122 points
23 comments
May 08, 2026
Related Discussions
Found 5 related stories in 77.6ms across 8,303 title embeddings via pgvector HNSW
- CVE-2026-31431: Copy Fail vs. rootless containers averi · 59 pts · May 05, 2026 · 77% similar
- Copy Fail: 732 Bytes to Root on Every Major Linux Distributions fratellobigio · 15 pts · April 29, 2026 · 60% similar
- Copy Fail: 732 Bytes to Root on Every Major Linux Distribution eyalitki · 15 pts · April 30, 2026 · 59% similar
- Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities akhuettel · 120 pts · May 19, 2026 · 58% similar
- "Dirty Frag" (CVE-2026-43284): The Second Linux Root Exploit in Eight Days ggallas · 31 pts · May 09, 2026 · 58% similar
Discussion Highlights (5 comments)
raesene9
This is kind of an odd article to me. The point that podman may provide better isolation that Docker is made, but copy fail part focuses on the sample exploit (that overwrote su) which is not super applicable to containerised environments, and not the general effect of exploiting the vulnerability, which is to allow the user to overwrite a file that they should only have read-only access to. https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber... - This PoC has a good example of how Copy Fail might have an impact in a container based environment, it's exploiting the shared layers in a pair of container images, to overwrite a file in one image based on the running of an exploit in another. Whilst I've not directly tested podman for that kind of attack, I'd be a bit surprised if it stopped it, given how this vuln works.
seba_dos1
Anyone who sees Copy Fail and chooses to focus on the way the example exploit happens to gain root is just showing how unimaginative they are. In the pre-container hype era, the sysadmin where I used to work gave us write access to nginx.conf on work machines to facilitate development. I used it in pair with an XSLT template to gain root access, so I could install things without having to go through the sysadmin - all thanks to a single config file for a webserver and without relying on any kind of security bugs in there. This vulnerability makes all sorts of stuff that were supposed to be shared read-only with the container actually sorta writable, so the blast radius is going to be enormous in many contexts, even when not as universally trivially exploitable as with the "su" example.
samlinnfer
While the sample exploit does not breakout of the container, with memory corruption everything is still on the table, those missing caps can be added back, no new privs can be unset, etc. It just not as straightforward as patching su.
wolttam
I just don't trust the Linux kernel to effectively isolate processes anymore. Don't care if you're using user namespaces, seccomp, etc. There will be a bug. Time for Micro VMs, they're a stronger security boundary (not perfect, stronger)
zackmorris
Has anyone made a sandbox site running every type of container and presenting a shell where users can try to break out of any uncompromised ones remaining? It's self-evident that we should only run containers that haven't been pwned yet. I suspect that with all of the CVE-20XX exploits, Heartbleed, Meltdown, Rowhammer, Spectre, etc, that we're all living in a fantasy and there simply are no secure containers.