PHP2Shell: Two CVSS 9.2 Bugs in the Language 69.3% of the Web Runs On

Original graphic by Guruji Corporation.

One HTTP request, no login, no plugin. On Apache with mod_php, the trigger fires before a single line of your application code runs.

That is PHP2Shell: two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, rated CVSS 9.2 for unauthenticated remote code execution and fixed on 21 October 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

What actually happened

Both sit in the engine's memory handling — code every request touches.

CVE-2026-109618 is RCE via OOM corruption: a request hitting memory_limit at exactly the wrong moment leaves internal request data partially initialised, and cleanup later treats that invalid data as valid. CVE-2026-109619 is RCE via stale global state: request-owned state can survive after its memory is freed, so a later request on the same worker may use freed memory before normal initialisation resets it.

The PHP Foundation is direct: for the OOM flaw, "an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings"; for the stale-state flaw, a use-after-free and worker crash were confirmed, and RCE was demonstrated against a real application on mod_php.

Everyone serving web requests is exposed — PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, per PHP's advisory. Risk is highest for mod_php, the default on much cheap shared hosting, and the flaw reaches back across nearly every release since PHP 5.4. Exploitation can also read process memory — where a PHP app keeps its database password, SMTP credentials, API keys and payment secrets. Patching stops the attack; it does not un-leak what was read.

The number that makes it a board problem

W3Techs puts PHP at 69.3% of all websites whose server-side language it can identify, and Wiz describes the reach as 70% of the internet. WordPress, Drupal, Joomla, Magento and Laravel all sit on this engine — so this is not a PHP app getting a CVE, it is the default web stack getting one.

AI found it. The fix took two years.

In 2024, PHP went through its first external audit in years, funded through OSTIF and run by Quarkslab. While fixing one reported issue, a core developer found the first hints of the OOM problem behind CVE-2026-109618; an exploit was theorised, no concrete vector surfaced, and clearer issues took priority.

Then the models arrived. On 11 August 2026, researcher Ryan A at Calif reported an unconditional RCE with that same root cause, found using GPT-5.6 Sol under OpenAI's Patch the Planet programme. OpenAI independently reported the same root cause the same day, with more vectors on 18 September; Wiz reported both flaws on 24 August. From 11 August the fix was the team's top priority.

The Foundation does not soften what came before: the delay, it writes, "was a structural failure, caused by both the security team's decision process and its lack of resources." A consensus-driven team, competing fixes each with a compatibility or performance cost, very few engineers with deep enough knowledge of the engine. Since 1 July it shipped 15 CVEs and worked through more than 100 invalid or duplicate reports.

The disclosure broke, twice

On 20 October around 15:00 UTC, both CVE IDs began circulating with a wrong release time and a wrong CVSS 10.0 — the real score is 9.2. PHP moved its pre-announcement to 19:30 UTC and pulled the release forward from 22 October to 21 October, 14:00 UTC. Calif mistakenly published a proof-of-concept video that spread in copies, and at 07:41 UTC on 21 October, six hours before the coordinated release, Chainguard published built images containing the fix.

OpenAI's account frames the fortnight as a "Defender's Window": to its knowledge, frontier AI found these flaws before attackers did, and it shipped a PHP version checker as a Codex skill. Both things are true — defenders got a head start, and the head start leaked.

Where it stands now

WatchTowr saw its first attempts as fixes landed, none successful at that point: "we don't expect that will last long," its threat-intel head said. Hadrian reported "php2shell exploited in the wild at scale", mostly abusing PHP's session upload-progress path; Cloudflare, Patchstack and Vega saw attempts, and Amazon confirmed attempts four days before release.

India's CERT-In advisory of 23 October rates the risk "high risk of remote code execution and complete system compromise" and adds a line worth forwarding to your host: "Multiple reports confirm large scale exploitation in the wild, users are advised to patch urgently."

On 23 October, PHP issued an informational advisory for a third, lower-risk flaw, CVE-2026-115560, with a configuration mitigation: set session.upload_progress.enabled=0 until the next bugfix release. The Foundation's framing of every workaround is the one to remember: mitigations reduce exposure to specific attack paths but "do not make an installation safe."

Why this matters for Indian SMBs

Most Indian SMB sites do not control their own PHP version. They sit on shared cPanel or Plesk hosting where PHP is a dropdown set by the provider, on a server shared with dozens of customers. Your patching decision is somebody else's maintenance window — a procurement problem before it is a technical one.

Age is the norm. PHP 8.1 and older "no longer receive updates from the PHP project"; the team published only minimal source backports for 7.4, 8.0 and 8.1. A host still defaulting to 7.4 has no clean route except an upgrade, and upgrades break old plugins.

Credential exposure outlives the patch. A PHP process holds wp-config.php values, database passwords, SMTP and payment API keys in memory. If your site was reachable and unpatched during the window, rotating those secrets is part of the response — and if you supply a bank, hospital or government department, expect the question in their vendor form.

Five checks you can run today

Find the real version per host. php -v on the CLI, then confirm the FPM or Apache module the site actually uses. On shared hosting, read the panel's PHP selector.
Compare against 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. Anything below is a same-day change, not a next-sprint ticket.
If a provider runs your PHP, open a ticket naming the exact build and get written confirmation. "We are patched" is not an answer.
If you cannot patch, shrink the blast radius. session.upload_progress.enabled=0 closes the most-observed exploit path; taking the site offline closes all of them. Neither is a fix.
Assume memory disclosure. Rotate database, SMTP and payment credentials that lived in that process, and read access logs for direct hits on PHP endpoints during 20–24 October.

Where Guruji Corporation fits in

We did not find these bugs, and an edge rule is not a patched engine. What we do is the unglamorous work that decides whether a Wednesday advisory becomes a Friday incident: an inventory of every PHP endpoint you own and who actually controls its version, including the shared host missing from your asset register; a patch calendar agreed in writing with that provider; credential rotation drills; and a one-page exposure note your compliance team can forward as-is.

If you cannot say today which PHP version serves your public site, that inventory is the first deliverable. Talk to us and we will build it from your own hosting accounts.

Sources