> the attacker does not need to break in remotely. The danger is that once an attacker gets in — through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container

This part I don't understand. Wouldn't the attacker need to break in remotely? Ö

Your understanding is fine. In many environments, you can still do a lot of damage just by popping a shell and being able to access the database/sensitive environment variables/sensitive code. Getting to root would just be the icing on the cake.

That being said, it's pretty common for non-containerized processes to drop permissions to a low-privileged service account (like nginx running as `nobody`), so it definitely thwarts defense-in-depth in those setups.

In containerized environments, my understanding is their use of namespaces means you still need something more clever than just "patch out the authentication logic in su via the page cache" to escalate permissions in the system to break out of the container. That doesn't mean it's impossible in these exploits (the original copyfail writeup alluded to a second writeup coming to this effect - distinct from dirtyfrag though), but it does mean you're not going to be able to just spam the PoCs floating around.

The answer is in your question:

"...through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container"

DirtyFrag alone doesn't help an attacker; they need to get in first. But the blast radius is much wider now. A wordpress flaw, or a prompt injection in your OpenClaw skills, or a supply chain compromise in npm librarires means they now have full root access to your system.

This does sound inadequate. Do you think it's a possible AI slop "logic" written, too?