PHP2Shell: 70% of the web, 22 million servers and a 4-day head start for attackers.
On 21 October 2026 PHP shipped emergency fixes for two critical flaws that let anyone take over a server without logging in. Several governments, Poland among them, took their own sites offline. Here is the story in numbers, and what actually protected sites versus what only felt like protection.
What happened, in one paragraph.
PHP2Shell is the shared name for two bugs in the PHP core itself: CVE-2026-109618 (memory corruption when handling an out-of-memory condition) and CVE-2026-109619 (a use-after-free, i.e. using memory that has already been released). Both score 9.2 out of 10 on CVSS v4.0; watchTowr rated them a full 10.0. A crafted HTTP request could run arbitrary code on the server before the application even started. On Apache with mod_php it therefore didn't matter whether the server ran WordPress, Drupal, Laravel or a hand-written site. The bug had been in PHP since version 5.4, more than a decade.
The numbers worth remembering.
| Metric | Value |
|---|---|
| PHP share of sites with a known server-side language (W3Techs, 22.10.2026) | 69.3% |
| Internet-facing PHP instances potentially vulnerable (Palo Alto Cortex Xpanse) | 22.6M |
| PHP sites on 5.x and 7.x, with no official fix (W3Techs, August 2026) | over 1/3 |
| Severity (CVSS v4.0) | 9.2 / 10 |
| How long the bug sat in PHP's code | over 10 years |
| First exploit attempt before disclosure (Amazon MadPot) | 4 days |
| Time from PHP's pre-announcement to the fixes | about 18 hours |
A note on “70% of the internet”: the figure repeated in headlines from CNN to Fortune describes PHP's reach, not the number of servers that could be taken over. Exposure depended on version and configuration. Even cautious estimates still run into millions of machines.
How often PHP ships security fixes.
More often than most site owners assume. Every supported PHP branch gets a new release roughly once a month. PHP 8.4 debuted in November 2024, and the October fix was 8.4.27: 27 patch releases in under two years, on average every 3–4 weeks. In 2026 critical fixes landed at least twice: in May (8.4.21, including CVE-2026-6722 and CVE-2026-7261 in the SOAP extension) and now in October.
The pace is rising. According to stack.watch, 15 PHP vulnerabilities were published in 2025, and 31 in 2026 by the end of October, with a higher average severity. The PHP Foundation says outright that the security team now receives far more reports than before, and links that to AI-assisted research. In May 2026 the foundation set up a dedicated Ecosystem Security Team.
If your site hasn't had a PHP update in six months, it has statistically missed around six patch releases.
Timeline: the attackers got there first.
- August 2026 — researcher Ryan Austin of Calif and the Wiz team find the bug independently, both using AI tools. The report goes to the PHP security team, which prepares a fix in private.
- 17 October — Amazon's MadPot honeypots log the first exploitation attempt, four days before disclosure. It is still unknown how the attacker had the details.
- 20 October — an anonymous Hacker News post announces “two critical RCE flaws in PHP”. Within hours watchTowr confirms they are real. At 19:30 UTC PHP publishes a pre-announcement and moves the release forward by a day.
- 21 October, morning — Cloudflare enables blocking rules for all customers, free plans included, about 9 hours before disclosure.
- 21 October, 14:00 UTC — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship. According to Cloudflare's CEO, attempts grow from thousands (in the 10 hours before disclosure) to tens of thousands within 45 minutes after it, hundreds of thousands within 2 hours and millions shortly after.
- 22 October — Poland's Central Informatics Centre (COI) temporarily takes down the public information bulletin (BIP) sites running on the SSDIP system (ssdip.bip.gov.pl), restoring them gradually in the afternoon.
The key numbers in this timeline: about 18 hours from warning to fix, and 45 minutes from disclosure to a tenfold jump in attacks. A company that checks for updates once a month has no chance of keeping up in that scenario.
How loud it was.
Very, and well beyond the IT industry. Warnings came from the US NSA (advising “patch or take the system offline”), the UK's NCSC, CERT-EU, Singapore's CSA and CERT Polska. According to Computer Weekly, Finland, the Netherlands, France and Denmark pre-emptively took some government services offline. In Poland the Ministry of Digital Affairs issued an urgent statement, and the story ran on RMF24, Rzeczpospolita, money.pl and Wprost. Internationally CNN, Fortune and Newsweek covered it, and some outlets dubbed it the “PHPocalypse”.
For balance: as of 23 October no successful PHP2Shell break-in had been publicly confirmed, and the flaws were not yet in CISA's Known Exploited Vulnerabilities catalog. Sophos withdrew its earlier report of a successful attack; its telemetry showed only scanning and failed attempts, including a Mirai botnet payload. The lack of confirmed breaches, though, is mostly down to the fast response: patches, WAF rules and sites taken offline.
What worked, and what didn't.
| Measure | Effectiveness | Notes |
|---|---|---|
| Updating PHP to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 and restarting Apache or PHP-FPM | Complete | The only complete fix according to PHP, CERT Polska and Poland's Ministry of Digital Affairs. In containers: rebuild the image on a fresh base. |
Disabling session.upload_progress.enabled and restarting every PHP worker | Partial | The most commonly recommended interim step; reduces the CVE-2026-109619 family of bugs. |
| WAF rules (Cloudflare, Imperva, others) | Temporary | Cloudflare itself called them a stopgap. The rule only worked with the default upload-progress field name and only for traffic passing through the proxy. Attackers tweaked payloads to get past it. |
| Taking the service offline until patched | Complete, but costly | The NSA's choice for systems that can't be patched quickly, and the route taken by COI and several governments. |
Lowering memory_limit or post_max_size | Almost none | PHP confirmed code execution with default limits, and the attack payload is small and looks ordinary. |
Updating WordPress, Drupal, plugins, composer update | None | The flaw is in the PHP interpreter, not the application. |
Site owners on outdated branches had it worst. Versions 7.4–8.1 only got a source-code patch with no ready-made packages, and 5.4–7.3 get no fix at all. Depending on the scan, between 45% and over 70% of sites that disclose their PHP version run an unsupported branch. For them the only way out is a migration or paid extended support.
Who got through it calmly.
The companies for which PHP2Shell was just another Thursday had a simple, unglamorous common denominator:
- They knew what they had. A list of services with their PHP version and an owner. CERT Polska's recommendations started with exactly that inventory.
- They were on a supported PHP branch. Going from 8.4.26 to 8.4.27 takes minutes. Jumping from 7.4 to 8.4 in the middle of a crisis is a weeks-long project.
- They had repeatable deployments. Rebuild the Docker image or run one package-manager command, rather than hand-editing a live server.
- Someone was watching the advisories. PHP's pre-announcement came a day before the fixes. Whoever read it had time to plan a maintenance window and switch on interim protections.
- They had backups and a staging copy. So the update could be tested and rolled out without fear.
These are exactly the elements I describe in the post on regular Drupal updates. PHP2Shell simply showed that they apply to the whole technology stack, not just the CMS.
Monitoring threats isn't paranoia, it's hygiene.
It's tempting to treat PHP2Shell as an exception, but the numbers say otherwise. PHP has had critical flaws before (CVE-2024-4577 in PHP-CGI in 2024, for one), fixes ship monthly, and AI tools speed up bug hunting on both sides. Wiz writes that one researcher with AI did in a week what used to take a team months. Attackers have the same tools, and the gap between disclosure and mass exploitation is now measured in minutes.
In practice that means three things: an up-to-date stack (a supported PHP, OS and CMS version), someone who follows security advisories and reacts within hours rather than weeks, and infrastructure in which updating is routine rather than open-heart surgery. If you don't have time for that, it is what ongoing maintenance is for. What it costs is covered in how much Drupal maintenance costs.
Frequently asked questions.
Does updating WordPress, Drupal or plugins protect against PHP2Shell? No. The flaw is in the PHP interpreter itself, not in the CMS. You have to update PHP on the server (or rebuild the container image) and restart Apache or PHP-FPM. Updating the CMS, plugins or running composer update changes nothing here.
Which PHP versions are safe? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later. Linux distributions often backport the fix into their own packages under a different version number, so check your distribution's security advisory. Versions 7.4–8.1 only got a source-code patch, and 5.4–7.3 got nothing.
Is a WAF (e.g. Cloudflare) enough instead of updating? No. WAF rules buy time, but the companies that shipped them call them a stopgap. They only protect traffic that passes through them, and only against known attack variants. The only complete protection is a patched PHP version.
How do I know whether my site was vulnerable? You only need the PHP version on the server: if it was older than the versions patched on 21 October 2026, the site was vulnerable. If you don't know which PHP version you run or who is responsible for updating it, that is the main lesson of this story.
Summary.
PHP2Shell wasn't the first critical flaw in PHP and won't be the last. The difference between “we patched before lunch” and “we took the site down for a day” wasn't luck. It came down to whether someone had already taken care of an up-to-date stack, an inventory and an update process. If you want to check how that looks for you, get in touch. I'll start with which PHP version your site actually runs.
Sources
- The PHP Foundation — the 21.10.2026 release, Ecosystem Security Team
- Wiz Research — discovery write-up, versions back to 5.4, role of AI
- Unit 42 (Palo Alto Networks) — 22.6M potentially vulnerable instances
- Cloudflare — WAF rules and their limits; The Next Web — scale of attempts
- Infosecurity Magazine — the 17.10 attempt in Amazon MadPot data
- Tenable and watchTowr — FAQ, CISA KEV status
- Computer Weekly — NSA, NCSC and CERT-EU warnings and government takedowns
- Rzeczpospolita and ITwiz (Polish) — Ministry of Digital Affairs statement, BIP takedown
- W3Techs — PHP share and version breakdown
- TechnologyChecker and CybelAngel — share of sites on unsupported versions
- stack.watch — PHP vulnerability counts for 2025–2026
As of 24.10.2026. The situation is still developing; some figures come from single vendors and use different methodologies.