undefined | Better HN

0 pointsraesene91d ago0 comments

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.

0 comments

captn3m01d ago

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.

freedomben1d ago

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.

raesene9OP1d ago

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.