PHP2Shell: the full timeline, what it exposed, and what it means for how you host

On 21 October 2026 the maintainers of PHP shipped emergency patches for two critical vulnerabilities that together put remote code execution, the holy grail of attacks, within reach of anyone who could reach a web server running an unpatched build of a language that powers roughly 69 percent of websites whose server-side language is known, per W3Techs. The vulnerabilities were found by artificial intelligence, named PHP2Shell by the researchers at Wiz, and patched under a global coordinated disclosure that partially leaked two days early, which is why the week of 20 October 2026 is now remembered as the week governments took their own websites offline on purpose.

This is the full story with dates, the honest impact assessment, how Cloudways protected the servers this site runs on (disclosure: we are Cloudways customers and the review on this site carries an affiliate relationship), and what the whole event says about where security is going. The timeline, the version tables and the checklist below are interactive; everything on this page is sourced.

What PHP2Shell actually is

Two distinct memory-safety flaws in PHP itself, not in any CMS or plugin, tracked as CVE-2026-109618 and CVE-2026-109619, affecting PHP versions from 5.4 (released 2012) through 8.5: remote code execution via out-of-memory corruption, and remote code execution via stale global state between requests. A successful exploit runs code with the privileges of the web server process. The PHP project rated both 9.2 out of 10 under CVSS v4.0; the security firm watchTowr argued for a full 10.0.

No login and no plugin bug are involved: the request itself is the weapon, which is why every serving mode, PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, was affected.

The code runs with the web server process's privileges, the level a CMS or framework already has: read the site files, talk to the database, write a webshell to stay.

Both CVEs reach the same outcome by different memory-corruption routes: 109618 through a controlled out-of-memory condition, 109619 through stale global state between requests.

The uncomfortable detail in the postmortems: a PHP core developer had found the out-of-memory error during an audit in 2024, and the class of bugs had been flagged as a concern decades earlier. The team could not agree on a fix, no exploit existed, and the issue was shelved as too difficult to weaponise. That judgment was probably correct for humans. It did not survive contact with AI-assisted research.

5.45.67.48.08.18.28.38.48.5

PHP 8.58.5.12

Fixed 21 October 2026 in PHP 8.5.12, then refreshed for the 23 October regression. Run the latest point release.

The version to check is the one per application, not per server: panels let each site run its own PHP, and the site you forgot is the one that gets you.

Tap a version for its status. Status is labelled, never colour alone: dark means a fixed release exists, amber means source-only, red means no official patch.

The timeline

Five days decided the week: an anonymous leak on the 20th, the patch drop at 13:34 UTC on the 21st, and a proof-of-concept bounty claimed by the 25th. Explore it below, phase by phase.

EverythingDiscoveryThe leakPatch dayFall-out

1. August 2026AI finds the bugs two independent teams
2. 17 OctoberExploitation before disclosure
3. 20 OctoberThe embargo breaks early
4. 21 October, 13:34 UTCThe patches land

   PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship, 26 minutes early, with source-only patches for EOL 7.4, 8.0 and 8.1. The maintainers state there are no complete mitigations: updating is the only safe choice. cPanel and CloudLinux ship backports; Ondřej Surý builds installable packages for old versions. Cloudflare, which had already seen early exploitation signs, deploys free WAF rules.

5. 21 October, through the dayThe web goes dark on purpose
6. 22 to 23 OctoberPatch-diffing and the regression
7. 25 OctoberThe doubt ends

Tap an event to expand it. Filter by phase to follow one thread.

The honest impact assessment

The visible layer was the deliberate downtime. For one week an extraordinary number of organisations decided that being offline was cheaper than being exploitable, which tells you how the industry rated the odds.

Governments

Portals that chose offline over exposure

• Dutch government portal (Overheid.nl)
• All Finnish government public web services
• French Interior Ministry
• Danish national school platform
• Some Canadian government sites
• NSA advice: go offline if you cannot patch now

Platforms

Community and archive sites

• Wikimedia supporting services (Phabricator, screenshot tool)
• Internet Archive, briefly
• 4chan and Something Awful, voluntarily
• Cloudflare free WAF rules for everyone else

Japan

Games and commerce

• Umamusume: Pretty Derby
• Granblue Fantasy
• Princess Connect! Re:Dive
• Street Fighter V delisted from stores

Rational for a government portal, overreaction for a blog, and both were correct given their stakes. The quiet layer is bigger: the unpatched tail will be harvested for years.

The real layer was the unpatched long tail, and it is still with us. Every PHP 8.1-and-older server with no official binary patch, every abandoned appliance, every forgotten VPS is a standing answer to why this bug class matters. The proportion of the web that never patched Heartbleed and Log4Shell suggests the PHP2Shell tail will be harvested quietly for years, which is precisely what NCSC guidance about backdoor-hunting anticipated.

The structural layer is the economics. The Guardian noted during the week that the PHP Foundation, keeper of a language running most of the web, employs around thirteen people part and full time, funded largely by donations, while the AI tooling that found the flaw operates on billions in investment. The infrastructure that holds up the web is maintained on a shoestring, and PHP2Shell put that asymmetry on every front page for a week. If you run on the web, that is your supply chain.

How Cloudways protected their users

This is where the managed layer earned its monthly fee, and the record is public on the Cloudways status page, timestamps and all. The short version: identified and mitigating hours before any patch existed, customer sites patched fleet-wide across every supported version including end-of-life ones by the morning of 22 October, and protection against the regression CVE shipped before that CVE was disclosed.

1. 21 Oct, 09:16 UTCIdentified, before any patch exists
2. 21 Oct, 13:34 UTCPHP ships; Cloudways patches itself first
3. 21 Oct, 16:43 UTCPHP Group's interim mitigations deployed
4. 21 Oct, 22:19 UTCFleet-wide mitigation, every version

   Interim protections cover the fleet. Patched builds roll out to every supported version, including deprecated 5.6, 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4, each with its corresponding fix. No impact on platform or site availability.

5. 22 Oct, 01:02 UTCAutonomous applications done
6. 22 Oct, 10:20 UTCRollout complete
7. 23 OctAhead of the next disclosure

From Cloudways' public status-page incident history. Tap a step for what happened. The whole span is under 50 hours from identification to complete fleet coverage.

Read the 23 October step again. The platform shipped protection against a vulnerability in a patch that had existed for under 48 hours, before that vulnerability had a CVE number. That is the entire argument for managed hosting compressed into one week. If you run your own VPS, PHP2Shell meant a panicked Tuesday of checking versions, trusting community packages, and hoping your configuration did not match the vulnerable profile. If your sites run on a managed panel, you woke up on 22 October to a status email and patched servers. The comparison is not theoretical; it is the product. Our Cloudways review covers what that layer costs the rest of the year.

The arms race has new participants

The part worth sitting with: AI found this. GPT-5.6 Sol and Gemini 4 Argon, pointed at PHP's source by researchers on both coasts, found in weeks what a human audit had found in 2024 and shelved as too hard to exploit. The expensive part of vulnerability research has always been the grinding audit of decades-old code, and that is exactly the part machines got good at first.

Defenders gained

• AI audits found in weeks what a 2024 human audit found and shelved as too hard to exploit
• Coordinated disclosure run by NCSC-NL and CERT-EU tracked 929 products to fixed
• Free WAF rules from Cloudflare bridged the gap for the unpatched tail on day one
• Platforms deployed mitigations before CVEs existed at all

Attackers gained

• Exploitation probes in Amazon MadPot telemetry four days before public disclosure
• Early patched builds let anyone diff the fix and see the vulnerability before the embargo lifted
• The same model that audits code for defenders writes exploits for whoever pays it
• An unpatched tail that will be harvested quietly for years

The scarce resource stops being the vulnerability and becomes the unattended server. Security gets decided by who applies the patch, how fast, at what scale: a hosting decision.

The plausible middle period ahead: WAF rules and virtual patching as the bridge for the unpatched tail, coordinated disclosure getting leakier and faster, and platform operators increasingly doing what Cloudways did in October, deploying mitigations against flaws before CVEs exist, because their detection loops now run faster than formal disclosure. If finding bugs becomes cheap, the web's security stops being decided at discovery time and gets decided by who applies the patch, how fast, at what scale.

What to check on your own sites

0 of 5 done

• YConfirm the PHP version per applicationNot per server: panels let each site run its own. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• YGet off 8.1 or olderNo official binaries exist. Extended-support packages, community builds, or schedule the upgrade you have been deferring.
• YRotate credentials and sweep for persistence if you were exposedUnpatched and web-facing during the window? Assume compromise: unfamiliar cron entries, unknown admin users, changed plugin files.
• YKeep the WAF rules, patch anywayCloudflare's free rules and platform mitigations are a bridge while you update. A bridge, not a destination.
• YTest a restoreIf the week had gone worse, recovery speed would have been the whole story. A backup nobody has restored is a hope.

Five things, in order. If you run on a managed panel, item one is a ten-minute check; the rest was probably done for you the night of 21 October.

And the hosting question the week answered: when the next language-level vulnerability lands, and there will be a next one, who applies the patch at 22:00 UTC while you are asleep? If the answer is nobody, that is the gap to close. Our Cloudways review covers the managed layer that handled this one, the PHP hosting guide covers the version-and-control tradeoffs that decided how exposed you were in the first place, and the security checklist and maintenance routine are the habits that make the next event smaller.

Sources: the PHP project announcements, the NCSC-NL operational repository tracking affected products, the PHP2Shell Wikipedia record with its primary-source citations, and the Cloudways status page incident history for every Cloudways timestamp above.