PHP2Shell is the way in, but standing access is the breach

PHP2Shell has been everywhere this week. If you missed it, our friends at Wiz and Calif have each published excellent breakdowns of the incident, its implications, and the flaws they found.

PHP powers 70% of all websites. PHP2Shell is a pre-auth remote code execution flaw in PHP itself, so an attacker can take over the server and read its memory, including any passwords, API keys, and tokens passing through it.

Preventing a vulnerability this severe is an AppSec question, and others have covered it well. But this post is about what happens after the attacker gets into the server. That part is an access question. If the server holds database credentials and cloud keys, the attacker doesn't need to hack anything else. They just need to log in.

Under attack four days before the patch

PHP shipped the fix on October 21. Amazon Threat Intelligence logged the first exploitation attempt four days earlier, on October 17, in its MadPot honeypots. On release day, Sansec reports that Cloudflare saw attacks about six hours before the patch went out, and Amazon said PHP2Shell was already being broadly exploited in the wild.

Wiz says frontier AI models let its researchers build working exploits across multiple applications in hours, and that complexity "may no longer provide a meaningful barrier." Amazon notes the same shift helps attackers turn a patch into a working exploit, which is why the gap between disclosure and attack keeps shrinking.

By the time a team could read the advisory, find its affected servers, and test the patch, the first attempt was already days old. When exploitation starts before the fix exists, patch speed stops deciding the outcome. What the attacker finds on the host does.

What the attacker finds on the server

A successful exploit runs code as the web server worker, usually www-data. That's a foothold on one machine. The breach is everything it can reach.

On most PHP servers, that's plenty. The next moves are well known: read the .env file, grab ~/.aws/credentials or a mounted Kubernetes token, and ask the cloud metadata service for keys. Some attackers won't even need the shell. The memory leak can hand over passwords, tokens, and API keys from other people's requests on the same server.

None of that access was careless when someone set it up. Each piece was the fastest way to make a deployment work. But all of it is standing access, live whether or not anything legitimate is using it. And every standing credential is a login the attacker can use.

Zero Standing Privilege limits the damage

Patching and detection matter, but you can't rely on them to keep attackers out. So the real question is what's waiting for them to exploit once they get in. That's the question Zero Standing Privilege (ZSP) answers.

No one should hold standing admin-level access. Not people, not scripts, not AI agents. Access should be requested for a specific task, limited to exactly what that task needs, and revoked the moment it's done. Anything less than that leaves a credential sitting on a server, waiting to be exploited.

To be clear, ZSP won't stop the exploit. The web app still needs its everyday access to run, so if the app can read its own database, an attacker who takes over the app can too. What ZSP takes off the table is everything beyond that: the admin passwords, the service account with far more rights than it needs, the SSH key for a job that only runs once a month.

So instead of losing everything the server's credentials could reach, you lose what one app could reach.

Same exploit, no standing privilege

Now run the same attack against a server with no standing privilege.

The attacker still gets in, maybe on October 17, before anyone knew the flaw existed. They open .env and find a database login that only works for the app's own data, and the server's cloud role can only do what the app needs. They catch an admin token in the memory leak, but it was scoped to one task and expired minutes after it was issued. They look for the service account with rights across the company and the SSH key for the deploy script. Neither is there. That access is granted only for an approved task, then revoked.

The attacker came to log in, and there was nothing to log in to.

They still have one app's data, and the server still needs patching. But one app's data is a contained breach. Every credential on the server is the whole company.

Check what's standing on your PHP servers

Patch first. Then, on every internet-facing PHP server:

• Treat every credential on it as exposed since October 17. Revoke and reissue it.
• Inventory what's standing there: .env files, ~/.aws/credentials, mounted Kubernetes service account tokens, SSH keys, and admin, automation, and AI agent tokens.

Revoking and reissuing is cleanup after the fact. With ZSP, there would be nothing privileged left on the server to clean up.

That's what we built Venice for: just-in-time access for human, machine, and AI agent identities, so a compromised server isn't holding the keys to everything else.

What decides the outcome

PHP2Shell put attackers on servers before most teams knew it existed, and that's becoming the norm. Plan for the shell landing. What decides the outcome is what they can log in to when they do, and the answer that holds up is no standing privilege.