PHP2Shell: 2 Hours With AI Agents vs Days for a Team [2026]
On 21 October 2026, PHP published fixes for two critical bugs that let anyone on the internet run their own code on a PHP web server, no login needed. The bugs became known as PHP2Shell, and attackers were already trying them.
The next morning I asked my AI system one question: are we vulnerable? We had about 20 servers and sites to check. Within about two hours every one of them was protected, and the patching finished soon after. Of that time I spent maybe 20 minutes actually typing. The rest of the morning I was running about 15 other agent sessions on completely different work.
In this guide we'll cover what PHP2Shell is and how to check whether you're exposed. Then I'll show you how an agentic operating system handled it, what a team would normally take, what it cost, and why it says something about the jobs being advertised right now.
TL;DR: if you've only got 30 seconds
PHP2Shell is two critical PHP bugs that let an attacker run code on your web server without logging in. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Check the PHP that answers web requests, then confirm the fix: from your distribution's changelog or security advisory, or from the version number if you installed official PHP.
With one AI agent per server, about 20 systems were protected in about two hours, for about 20 minutes of my typing by my estimate, plus approving each change.
Without agents, I'd estimate two or three engineers for three to five days. That's my estimate, not a measurement.
What Is PHP2Shell?
Think of a busy restaurant kitchen. Every order (a web request) gets a clean plate. PHP2Shell is what happens when a plate isn't cleaned properly between orders, and the next customer's food lands on top of the last one's leftovers. Normally you'd just get a messy dish. A skilled attacker can arrange those leftovers so the kitchen ends up following their recipe.
In technical terms, there are two bugs, both rated 9.2 out of 10 (CVSS v4):
CVE-2026-109618, "RCE via OOM corruption". If PHP runs out of memory part-way through setting up a request, it can be left holding half-built data. The clean-up step then treats that broken data as if it were real.
CVE-2026-109619, "RCE via stale global state". Data from one request can outlive the memory it was stored in, so a later request handled by the same worker uses something it should never see.
That makes PHP2Shell a PHP remote code execution (RCE) bug: someone on the other side of the internet makes your server run their commands. That's usually enough to read your app's passwords, reach your database and plant a back door. On the riskiest setup, PHP's advisory says "an unauthenticated request can trigger the attack before any application code runs", so your login page never gets a say.
The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The risk is highest for Apache with mod_php, real for PHP-FPM, and also listed for LiteSpeed, php-cgi and FrankenPHP. If you're on managed hosting, ask your host whether they've patched. The researchers at Calif and Wiz showed working exploits against WordPress and Laravel sites, and you don't need to call session_start() to be exposed.
How to Check If You're Exposed
These are the checks we ran on every server. None of them changes anything.
Find the PHP that answers web requests, not just the one php -v shows. Look for php-fpm, lsphp, frankenphp or Apache's mod_php in the running processes.
Confirm the fix, not just the version number. If PHP came from your Linux distribution, read the package changelog: distributions often backport the fix and keep the old version string. No match there doesn't settle it either way, so check your distribution's security advisory too. If you installed an official release, an official container or a source build, the version number is the check: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later. A common trap: an automatic security update that looks like the fix but turns out to be the previous round.
Check PHP restarted after the update. A fixed package does nothing until the workers reload.
Check who can reach it, including round the back. If your site sits behind a firewall service, try the server's own IP address too.
Can't patch today? Set session.upload_progress.enabled=0 in php.ini or your FPM pool (not ini_set() or .user.ini, which apply too late) and restart every PHP worker. Keep post_max_size modest, and block file-upload requests at your firewall on paths that never take uploads. PHP is blunt that these only reduce exposure: "There are no complete mitigations, updating is the only safe choice." On 23 October PHP added that it's worth keeping session.upload_progress.enabled=0 even after you update, until the next regular release, because of a separate and unlikely attack route.
For check 2 on a Debian or Ubuntu package, count the CVE IDs in the changelog (swap in your PHP version, such as 8.3). One or more is good evidence the fix is in. Zero is inconclusive, so check your distribution's security advisory:
$ zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -c 'CVE-2026-10961[89]'
How It Reached Us
We track security advisories from software vendors and government agencies, so PHP2Shell was on our radar the day it was published. The first question was the one we always ask: do we run the affected software, and which version? We checked every server and application we run, reading the version that was actually serving traffic rather than what our documentation said should be there.
Next we rated each affected system by how reachable it really was. Could anyone on the internet reach it with no login in front of it? Did the specific conditions the attack needs actually apply to how that server was set up? Systems that were exposed and matched the attack went to the top of the list; ones where the attack was possible but less certain came next. Every finding went into our central vulnerability register with the evidence behind each judgement, and the fixes were scheduled in that order. Each change to a live system was planned with a rollback and approved by a named person before it went ahead, because a rushed patch that breaks a site is its own kind of incident.
What a Team Would Normally Take
Before I show you how the agents did it, it's worth knowing what normal looks like, because the numbers are worse than most people think.
Verizon's 2026 Data Breach Investigations Report looked at vulnerabilities on CISA's known-exploited list, the ones attackers are actively using. The median time for organisations to fully fix one was 43 days. Only 26% were fully fixed during 2025, and "by Day 7 … somewhere between 60% and 70% of KEV vulnerabilities remain open regardless of year, volume or organizational maturity." Exploiting vulnerabilities is now the most common way into a breach, at 31%.
Attackers don't wait that long. Verizon puts the median time to mass exploitation of a known-exploited bug at five days, and Mandiant's latest estimate puts the average time-to-exploit below zero, meaning more attacks now start before a fix exists. PHP2Shell fits that pattern: Amazon saw attempts from 17 October, four days before the fix.
Why so slow? Mostly not because patching is hard. In a Ponemon study for ServiceNow (2019, nearly 3,000 respondents), 88% of organisations said they have to coordinate with other teams before patching, adding an average of 12 extra days. DORA's research found that heavyweight change-approval boards make delivery worse without making changes safer.
Now picture this job without agents. Nothing's ever done purely by hand, of course. A good team has scripts, scanners and dashboards. But someone still has to read the advisories, log into 20 systems, work out which PHP each one really runs, decide how to protect each, plan and test a different fix for each kind of setup, get approvals and write it up. My honest estimate: two or three experienced engineers for three to five working days, and longer if anything needs rebuilding. At UK contract rates of around £525 a day for a security or DevOps engineer, that's roughly £3,000 to £8,000 of people time, before any out-of-hours premium. That's an estimate, not a measurement, but I'd defend it.
One AI Agent per Server: How the Agentic Operating System Did It
We run our business on HAL, our own agentic operating system, and the HAL Agent Bridge is its control room. Every piece of work runs as its own AI agent session, grouped into folders in a sidebar, and the agents can message each other. Here's what AI incident response looked like in practice.
The morning ran like this:
A controller agent checked every server, read the advisories from the original sources, and wrote one briefing with everything the others needed.
One agent per server, each in its own tab, owned its server from investigation to fix. One server each meant nothing got mixed up between machines.
A live status page sat beside the controller. Each agent kept its own card up to date: its plan as numbered steps, how far it had got, and when it last updated. A small checker nudged any agent whose card went stale.
I approved every change. No agent touched a live system without my explicit approval for that specific change.
The first thing we did was close the door. Picture a shop with a security guard at the front door: Cloudflare was our guard, and since 21 October it has carried emergency rules for PHP2Shell, free on every plan. But a guard is useless if the back door is propped open. On one application, about a fifth of the day's requests had been reaching the server directly rather than through the guard, and the ones we checked were all automated scanners. We closed that route quickly.
Then each agent patched its server calmly: the distribution's security update, the newer official PHP release where that was the faster route, and our host's patched PHP for the managed WordPress site. Staging first, a backup before every change, a test from outside afterwards.
It feels like having a whole tech team that works in parallel: one agent per server, all moving at once, while I make the decisions. They still need guidance, to make sure they look at authoritative sources and double-check things. I set the direction and approve every change; they do the execution.
What It Actually Cost
Here are the numbers from that morning:
| Without agents (estimate) | With HAL's agents (measured unless marked) | |
|---|---|---|
| Time to protect everything | Three to five working days | About 2 hours |
| Human time | Two or three engineers for days | About 20 minutes of my typing (my estimate), plus reviewing and approving each change |
| People cost | Roughly £3,000 to £8,000 | One person: about 20 minutes of typing (estimated), plus review time |
| AI cost | None | About 600 million tokens, around $165 at list API prices. We actually pay a flat monthly subscription |
For context only: Verizon's 43-day median measures how long organisations take to fully fix a known-exploited bug, which isn't a like-for-like comparison with one morning on our own systems.
Most of those 600 million tokens are the agents re-reading their own notes from a cache, which is the cheap part.
⚠️ There's an honest catch
This only works because the system already existed. HAL has been about 13 months in the making. The pieces that did the work this morning, like the Agent Bridge, are much newer, but they stand on everything built before them: the rules, the checks, the habits that made this morning safe.
Why Mistakes Never Became Problems
The agents made mistakes that morning. None of them mattered, because of the process around them.
Take the last one. An agent asked to switch the live site before it had finished its research. I asked, "Are you sure we've checked everything?" It hadn't.
AI agents are fast, and like people they get things wrong. The difference is that a well-built system checks them every time.
What This Means for Your Career
You can already see this in the job market. We track real job postings that ask for people who direct AI, not just use it, and you can read them yourself on our AI-driven cyber security jobs tracker. The skill those employers are paying for is exactly what this morning took: knowing what good looks like, asking the right questions, checking the evidence, and approving the change. The agents do the execution.
If you want to understand why that's an opportunity rather than a threat, read AI Just Handed You the Biggest Career Opportunity of Your Life. If you want to start building this kind of system yourself, Agentic Engineering is the place to begin.
Your PHP2Shell Checklist
Frequently Asked Questions
What is PHP2Shell?
Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, published on 21 October 2026. They let an attacker run code on a web server without logging in.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions may backport the fix under an older version number, so check your package's changelog or your distribution's security advisory for the CVE IDs.
Does a web application firewall stop PHP2Shell?
It helps, but it isn't a fix. Make sure attackers can't reach your server directly around the firewall, and patch.
Do I need to upgrade my operating system to fix PHP2Shell?
No. You need a fixed PHP. If your distribution hasn't shipped it yet, use an official patched PHP container or build from source.
How long did it take with AI agents?
About two hours for every system to be protected, with the patching finished soon after. By my estimate I spent about 20 minutes typing, plus the time to review and approve each change. Without agents, I'd estimate two or three engineers for three to five working days. For wider context, Verizon's 2026 report puts the median time for organisations to fully fix a known-exploited vulnerability at 43 days.
What did the AI cost?
About 600 million tokens, roughly $165 at list API prices, on a flat monthly subscription.
About the Author
Nathan House, Founder & CEO of StationX
Nathan House has 30 years of hands-on cybersecurity experience and is Cambridge-educated, holding CISSP, CISA, CISM, OSCP, CEH, and SABSA. He founded StationX in 1999 — one of the UK’s first cybersecurity companies — and has secured £71 billion in UK mobile banking transactions and the London 2012 Olympics, advising clients including Microsoft, Cisco, BP, Vodafone, and VISA. He authored the world’s most popular cybersecurity course — a #1 Udemy bestseller taken by over 500,000 students — and was named Cyber Security Educator of the Year 2020, AI Security Educator of the Year, and a UK Top 25 Security Influencer 2025. A DEF CON speaker and featured expert on CNN, Fox News, NBC, and the BBC, Nathan leads StationX’s training of more than half a million students worldwide.
