@amluto, fair points, I still consider this vulnerability extremely severe as yes, if you use rootless containers the attacker won't be able to get root on the host and with that injecting additional potential malware, but at the same time for containers re-using the same image layers it will give the ability to poison those binaries in memory and break to some extent the container to container isolation.

If we weren't looking into moving away from using containers completely into using ephemeral microVMs one area I'd invest in would be replicating what CargoWall does for GitHub actions in GitLab CI. At that point even if the attacker gained access to a container, modified a binary with some specific instructions (like reading env vars and sending them to an external server) it'd not be able to send credentials or fetch a malware remotely at all due to the DNS queries being intercepted by eBPF and being sent to a CoreDNS proxy.

I still think rootless containers increase the attack vector complexity in more than just a one liner into an attack scenario that, at that point, should also involve understanding additional details about the underlying host with information such as, as you correctly pointed out, what container images (and thus shared image layers) are present and also whether these images use setuid binaries which specific CI jobs explicitly call throughout the build process (kind of unusual to see anyone running a setuid binary in a CI pipeline anyway as that is generally an action that would result in a permission denied in normal conditions).