PHP2Shell was found with the help of AI, exploited before the patch shipped, and fixed in releases that don’t reach most PHP servers. Patching faster matters, but it isn’t the whole lesson. Upgrades have to become routine, and the same AI that’s speeding up discovery can speed up the fix.
On 21 October, PHP shipped emergency fixes for two critical flaws in the language behind around 70% of websites whose server-side code is known. Together called PHP2Shell, CVE-2026-109618 and CVE-2026-109619 let an attacker who hasn’t logged in run code on a web server. Both are rated 9.2. They sit in PHP itself, not in any CMS or framework, so every PHP installation that serves web requests is affected until it’s updated.
Attackers didn’t wait for the patch. Amazon’s threat intelligence team logged an exploitation attempt against its MadPot honeypots on 17 October, four days before disclosure. Proof-of-concept exploits appeared around 02:00 UTC on the 21st, about 12 hours before the fixes shipped. Cloudflare’s chief executive, Matthew Prince, said the company saw tens of thousands of attempts within 45 minutes of disclosure, hundreds of thousands within two hours, and millions since.
In the UK, the NCSC told organisations to update immediately, use PHP’s temporary mitigations if they couldn’t, and consider taking affected systems offline if neither was quick. By Wednesday afternoon, the websites of Edinburgh and Oxford councils and the Metropolitan Police were among those unavailable, with no break-ins confirmed. Government sites in Finland and the Netherlands were pulled too. Switching your own website off is what security looks like when the fix can’t reach you.
Found With AI, by Someone Who Knew Where to Look
How PHP2Shell was found is the part to plan around. Calif researcher Ryan Austin found the vulnerable code paths on 1 August and reported the first bug to PHP on the 11th, working with what Calif’s write-up calls an “LLM companion”. OpenAI says the model was its GPT-5.6 Sol, used in an audit funded through its Patch the Planet initiative. Wiz found both flaws independently a few weeks later, also with AI models in the loop. The earliest affected code dates back to PHP 5.4.0, released in 2012.
OpenAI presents it as a milestone: “To our knowledge, frontier AI found these vulnerabilities before attackers did.” Calif’s account is more measured. “No special harness, or access to models that weren’t generally available to everyone were used in the initial bug discovery,” it says. The researcher “focused on something I had a background in, knew its vulnerability history well, and held a theory that specific bugs lurk within the codebase.”
Read together, the two accounts say the same thing. The model didn’t find PHP2Shell on its own. It extended the reach of an expert who knew where to look, and that combination is now available to attackers too. OpenAI warns that “the same capabilities can also help attackers rapidly develop offensive tools and exploits”, and expects similar findings to “increase sharply in the coming months”. We looked at the attacker side of this shift in The Claude Mythos Arms Race. PHP2Shell shows what it means for defenders.
Two teams finding the same 14-year-old bug within weeks of each other is the clearest sign of where this goes. As CJ Moses, CISO of Amazon Integrated Security, put it this week: “An embargo protects defenders only until someone else finds the same bug.” His conclusion is the one every technology leader should take away: “A 7-day or 30-day SLA assumes a delay that no longer exists.”
Most PHP Servers Can’t Install the Fix
PHP released fixed versions for its four supported branches: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Anything older gets no release. The PHP project was blunt about it: “PHP 8.1 and older no longer receive updates from the PHP project.” Its security team published minimal source backports for 7.4, 8.0 and 8.1, but those are patches for people who compile PHP themselves. A server that installs PHP from packages only gets them if a vendor ships an update. For 7.3 and earlier, there’s nothing.
That wouldn’t matter much if old PHP were a long tail. It isn’t. Bitsight’s internet-wide scans found that “only about a third of the PHP instances where we could identify the version run a branch covered by this security update.” The most common branch by far was PHP 7.4, with more than 2 million observations. PHP 7.4 stopped receiving security fixes in November 2022.
For most PHP servers that reveal their version, there’s no patch to apply. There’s an upgrade, a vendor backport, or the off switch. That’s why the official advice reached for the off switch so quickly. CERT-EU told organisations to isolate internet-facing applications until a fix was in place, and the NCSC’s fallback was to take systems offline.
Why the Old Versions Are Still Running
Nobody chooses to run PHP 7.4 three years after it lost support. It happens because a runtime upgrade is the hardest kind of engineering work to fund. It ships no feature. It carries real regression risk. It touches code whose authors have often moved on, with thin test coverage and quiet dependencies on functions that newer versions removed. So it loses every prioritisation meeting to work the business can see, until an incident makes the case for it.
Over time, the cost of upgrading grows while the cost of not upgrading stays invisible. We’ve called this platform debt: it compounds quietly until something makes it visible. PHP2Shell made it visible in an afternoon. End-of-life software isn’t technical debt you can pay down later. It’s exposure you can’t patch when it matters.
Put AI to Work on the Fix, Not Just the Find
Here’s the opportunity in this week’s news. The capability that helped find PHP2Shell reads code far faster than people do. That’s just as useful for the slow, high-volume work that stops upgrades from happening, and it’s work defenders can start on today.
Find what’s running. AI can sweep servers, container images, repositories and deployment configs for every PHP runtime, with its version and how it’s served. That last detail matters: PHP’s security team said “we consider the risk highest for mod_php”.
Read what will break. For each application, AI can trace the functions, extensions and behaviours that changed between versions and turn a vague worry into a concrete list. Engineers then judge which items carry business risk.
Pin down today’s behaviour. Legacy code rarely has the tests an upgrade needs. AI can write characterisation tests that record how the application behaves now, so any change in behaviour shows up before it reaches production.
Draft the change in small pieces. AI can propose the upgrade as a series of small, reviewable changes rather than one big-bang branch. Engineers approve every one, and the regression suite decides what ships.
None of this removes engineers. It changes where their time goes: from grepping a decade-old codebase to reviewing, deciding and approving. AI-drafted changes still need the same verification as any other change, and as we’ve written before, verification is where most AI-assisted engineering falls short. The goal isn’t a heroic upgrade project. It’s making upgrades boring: small, tested, reviewed changes that ship as routinely as features.
Measure Time to Patch in Hours
Amazon’s guidance is to measure patch and mitigation timelines for critical, internet-facing flaws in hours, not days. Few organisations can do that today, and the reason is rarely the security team. Patching in hours depends on four things engineering owns: an inventory you trust, a named owner for every runtime (including the ones your hosting provider, SaaS vendors and agencies run for you), automated tests that make a runtime change safe to ship, and a pipeline that can roll forward and back without a change freeze.
Those are delivery capabilities, not security products. The organisations that took PHP2Shell in their stride this week were the ones for whom shipping a new runtime is already a routine change.
Where to Start This Week
Find every PHP runtime, including the ones you don’t host. Record its version, how it’s served, and who can actually patch it. Your hosting provider, your SaaS vendors and your agencies hold some of your patches, and you can only ask them for a date.
Patch, or mitigate and keep going. A fixed release is the only complete fix. PHP’s temporary mitigations reduce exposure while you update, but PHP’s security team says they don’t fully protect against exploitation, so treat them as a stopgap with an expiry date.
Look back to 17 October, not the 21st. Amazon advises starting investigations from the first observed attempt, not the disclosure date. Datadog’s guidance is that a web worker spawning a shell is the most direct evidence of a successful attack, and a successful exploit doesn’t necessarily crash anything.
Put a date on every end-of-life runtime. For anything on PHP 8.1 or older, decide this quarter: upgrade it, buy vendor-supported backports, or retire it. “Later” is the option PHP2Shell took away.
Make the next upgrade routine. Pick one legacy application and run an AI-assisted upgrade from end to end, with your engineers reviewing every change. One real upgrade will tell you more about your true cost of change than any estimate, and it gives you a repeatable pattern for the rest of the estate. Modernising in slices that each pay for themselves beats waiting for a programme big enough to fund.
Q&A: PHP2Shell and End-of-Life PHP
What is PHP2Shell?
Two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2, that let an attacker who hasn’t logged in run code on a web server. They sit in PHP’s core rather than in any CMS or framework, so every PHP installation that serves web requests is affected until it’s updated.
Which PHP versions fix PHP2Shell?
PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older get no official release. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and long-term support vendors ship their own patched packages.
Is the configuration workaround enough?
No. Turning off session upload progress and lifting the memory limit reduce exposure while you update, but PHP’s security team says these mitigations don’t fully protect against exploitation. Updating to a fixed release is the only complete fix.
How was AI involved in finding PHP2Shell?
A Calif researcher found the first flaw in August while working with an AI model, which OpenAI identifies as its GPT-5.6 Sol, in an audit funded through OpenAI’s Patch the Planet initiative. Wiz independently found both flaws weeks later, also using AI. Calif stresses that the researcher’s knowledge of PHP’s vulnerability history drove the find, with the model extending their reach.
Can AI help upgrade legacy PHP applications?
Yes, as an accelerator for engineers rather than a replacement. AI can inventory runtimes, identify code that will break on a newer version, write characterisation tests, and draft the upgrade as small, reviewable changes. Engineers still review and approve every change, and the regression suite decides what ships.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we see PHP2Shell as a modernisation problem that’s landed on security teams’ desks. Our Modern App Discovery Quickstart maps your applications, runtimes and dependencies in one to two weeks and gives you a risk register with the business impact of each, so you know exactly which systems a fix can’t reach. Our AI Proof Sprint puts a working, governed AI agent into one well-bounded process in two to three weeks, and an upgrade-and-patch pipeline is exactly that kind of process: the agent drafts, your engineers decide. Where an application needs more than an upgrade, our Legacy Modernisation Strategy turns the estate into a phased, funded roadmap.
If you’d like a quick read on where you stand, our free Future Readiness Audit scores your software engineering, security posture and AI readiness side by side. It takes minutes, and it’ll show you which gaps an incident like PHP2Shell would find first.