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.
It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.
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.
The k8s exploit requires stars to be aligned for an external attacker: the pod you exploit (via an RCE?) must share some layers with a privileged pod running in the same node. Or alternatively, you should have the ability to run an arbitary image as an unprivileged pod. Which is surely, some environments where internal teams might have such access. But getting there for a remote attacker isn't easy.
Key point for testing exploitability is kernel version, package versions (in case they ship a patch) and loaded kernel modules. Some stripped down environments don't have the relevant modules available.
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)
I didn't say run in an air-gapped VM... Just as a means to better isolate the workloads I have running (some less trusted than others). Network connectivity and the associated vulnerabilities obviously remain.
No argument against VMs - just that they have a different risk profile and a different set of trade-offs than containers. They're not a silver bullet, but if they're working for you, then go for it.
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.
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.
Seems a good place to repeat a quote from Theo de Raadt:
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
He'd probably say the same about container architectures.
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.
Wait nginx ran as root?
It's usually launched as root and then drops its privileges for its workers. Unless... ;)
If you have write access to nginx.conf, you can set "user root root;"
Long ago in Linux if you wanted to listen on a privileged port (< 1024) you had to do so as root.
If you're connecting to a host on a port < 1024, then you know a SysAdmin must have set it up, and it must be trustworthy. It was a simpler time.
It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.
is that no longer true?
No, now you have the option of using CAP_NET_BIND_SERVICE
There is also net.ipv4.ip_unprivileged_port_start
If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)
Forgot to mention: you can use systemd-socket-proxyd to bridge to an application that doesn't support socket activation too: https://www.man7.org/linux/man-pages/man8/systemd-socket-pro...
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.
The k8s exploit requires stars to be aligned for an external attacker: the pod you exploit (via an RCE?) must share some layers with a privileged pod running in the same node. Or alternatively, you should have the ability to run an arbitary image as an unprivileged pod. Which is surely, some environments where internal teams might have such access. But getting there for a remote attacker isn't easy.
Thanks for the link. I tried the copyfail PoC in rootless podman yesterday and it didn't work, but I hadn't dug into it yet. This is great info.
I've had claude knock up a basic podman PoC, that seems to work ok https://github.com/raesene/vuln_pocs/tree/main/CVE-2026-3143... . It just uses a read-only mount and then demonstrates overwriting that read-only file.
Key point for testing exploitability is kernel version, package versions (in case they ship a patch) and loaded kernel modules. Some stripped down environments don't have the relevant modules available.
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)
You can't really do anything useful with a VM either unless you start punching holes in those boundaries.
I didn't say run in an air-gapped VM... Just as a means to better isolate the workloads I have running (some less trusted than others). Network connectivity and the associated vulnerabilities obviously remain.
No argument against VMs - just that they have a different risk profile and a different set of trade-offs than containers. They're not a silver bullet, but if they're working for you, then go for it.
Exactly.
If your VM can't do anything, it's probably not very useful.
Doing things meaning reading / writing files, communicating between VMs, services, etc.
what about selinux?
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.
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.
Seems a good place to repeat a quote from Theo de Raadt:
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
He'd probably say the same about container architectures.