PHP2Shell is not the problem; the frozen codebase is

On 21 October PHP fixed two critical flaws that let an attacker run code on a web server with one unauthenticated request. The code goes back to PHP 5.4 from 2012, according to Wiz, and researchers showed working exploits against WordPress, Drupal, Magento, Laravel and Symfony. What sets PHP2Shell apart is how it was found: AI models did much of the searching. The lesson is less about PHP than about speed.

I wrote PHP for 10+ years, a CRM, an ERP, a lot in between, so I read everything that came out that day. Here is what it says.

What happened

Both flaws, CVE-2026-109618 and CVE-2026-109619, sit in the PHP engine and score 9.2 on CVSS v4. PHP answers each request in a worker with a memory limit. One flaw corrupts memory when a request hits that limit before the app starts. The other leaves a fatal error’s state pointing at an earlier request’s memory, which the next request on that worker then uses.

Updating WordPress, Drupal or Laravel changes nothing; only a PHP update fixes it. Fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 7.4, 8.0 and 8.1 there are only source backports; older branches get nothing. Every web setup is affected, from PHP-FPM to FrankenPHP; Rapid7 rates mod_php as the most exposed, because there the attack can run before any application code.

How AI found it

The PHP Foundation’s account is unusually open. A first sign of the memory problem turned up in a 2024 audit, but the fix stalled for months over competing approaches. The Foundation calls that a structural failure of its own process.

This year the search sped up. Calif, auditing under OpenAI’s Patch the Planet program, reported remote code execution on 11 August, and OpenAI found the same root cause that day. Wiz added attack paths on 24 August, working with Gemini 4 Argon and GPT-5.6 Sol.

What the models did not do is just as telling. AI helps the Foundation validate reports and sort duplicates, but a person makes every call and works on every patch. Wiz describes repeated testing and debugging by its researchers to turn the bugs into working attacks.

What to keep a sober eye on

The “70 percent of the internet” in the headlines is PHP’s share of websites, not a count of vulnerable servers. Palo Alto Networks counts 22.6 million exposed instances that may be vulnerable. By W3Techs’ numbers, about half of PHP sites run a branch PHP no longer patches.

The disclosure did not go to plan. On 20 October the CVE numbers leaked with a wrong 10.0 score, Calif posted its proof-of-concept video by mistake, and the Foundation moved the release up a day. Chainguard then shipped fixed images six hours early.

Amazon’s honeypots had already logged an attempt on 17 October, four days before disclosure, and Cloudflare saw attackers changing payloads to dodge its rules on release day. At release the Foundation knew of no working exploit; Rapid7 expects that to change.

AI is no free lunch for maintainers either. Since July the PHP security team has published 15 CVEs and worked through more than 100 invalid, duplicate or unreproducible reports, each taking time the project barely has. The Foundation used the release to ask companies for funding.

What this means for teams

The models that found these bugs are available to attackers too. Wiz says they lowered the barrier to turning decades-old flaws into working exploits. That changes the clock: with PHP2Shell, attempts came before the fix.

The bottleneck is not knowing about the patch. It is applying it everywhere: every server, container image, serverless function and forgotten admin tool. Google’s write-up shows the split: App Engine standard updated itself, Cloud Run did where automatic base image updates were on, and App Engine flexible and self-built images had to be rebuilt by hand. Same bug, same day; the difference was the setup.

Four things make that setup. Put them in place before the next PHP2Shell, not during it.

Stay inside the support window. Each PHP branch gets two years of fixes and two more of security fixes. 8.1 and older are outside it; 8.2 leaves it on 31 December. Run a current runtime with a maintained framework; the language is not the point.

Know what you run. CISA’s first instruction was to inventory every system running PHP. A current list of services with runtime and version turns “are we affected?” into a query.

Make patching a routine, not an event. Bump the base image, rebuild, test, deploy: the same task every time. A team that does it weekly for small updates can do it in hours for a critical one. Track the time from a fix being available to it running everywhere.

Decide by risk who checks what. A version bump on an internal tool with good tests ships on green checks. A change to a shop’s checkout gets a person before it goes live.

If you cannot patch at once, Rapid7 lists stopgaps: disable session upload progress, turn off fatal error backtraces on 8.5, remove the memory limit. Sansec warns the last one lets a single request use all of a server’s memory, so treat them as a bridge to the update. Systems that cannot be updated at all, CISA says, go offline until they can be.

At Kadmo we treat this as a transformation, not a patch. Specialized agents work through playbooks on your own infrastructure, with any LLM.

• Knowledge first. The agents read the codebase and the running product and write the knowledge pack: module map, business rules, data model, integrations, deploy path. Their instructions and your documentation in one.
• A current stack or another language. A current PHP, TypeScript, Java, Go or .NET. Whatever your team can hire for.
• The cloud. Container images and managed runtimes that take the next patch on their own.
• Agentic development. Upgrades, tests and releases run through playbooks. A gate decides by risk whether a person looks before it ships.
• Your review, your tools, your cloud. Module by module, every change a pull request your team reviews.

If you want to see what this could look like for your team, we are happy to show you.

When did your team last deploy the oldest service you run?

Sources

• https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• https://www.wiz.io/blog/php2shell-php-rce
• https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
• https://sansec.io/research/php2shell
• https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
• https://www.php.net/supported-versions.php
• https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
• https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released
• https://w3techs.com/technologies/details/pl-php