On 21 October 2026, a security update to PHP led governments, global brands and thousands of small businesses to take websites offline on purpose. Most never published a notice. For many visitors, their favourite sites simply showed a maintenance page.
The cause was PHP2Shell, two critical flaws in the PHP engine, which runs WordPress, Drupal, Joomla, Magento and a large share of the web. If your website, CRM plug-in or customer portal runs on PHP (and there is a good chance it does), here is what happened, why it matters and the exact steps to take now.
What is PHP2Shell?
PHP2Shell is the nickname for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run their own code on a web server without logging in, with the same permissions as the website itself. In plain English, a stranger could take control of the server that runs your site.
- CVE-2026-109618: when PHP runs out of memory partway through setting up a request, it leaves internal data half-built and then trusts it during cleanup.
- CVE-2026-109619: internal state outlives the memory it points to, so the next request handled by the same PHP worker can act on stale data.
What makes this different from a typical WordPress plug-in bug is that the flaw is in PHP itself, not in your website’s code. A perfectly maintained website on an unpatched server is still exposed. According to the PHP team, in some setups (notably Apache with mod_php) an attack can succeed before your application’s code even runs, so security plug-ins inside WordPress cannot stop it.
How it unfolded
| Date (2026) | What happened |
|---|---|
| Before October | Researchers at Calif find both bugs and report them privately to the PHP team for a coordinated fix, planned for 22 October. |
| 20 October | Details leak on social media two days early. PHP announces an emergency release for the next day. Security firm watchTowr confirms the flaws are real. |
| 21 October, 14:00 UTC | PHP releases fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA (the US cyber security agency) tells organisations to patch immediately or take PHP systems offline. watchTowr reports exploitation attempts in its honeypots. |
| 21–22 October | Governments in the Netherlands, Denmark, France, Finland and Canada take some sites offline as a precaution, as do some EU services. Wikimedia takes many supporting services offline, and Orange suspends several sites and apps. Cloudflare reports early attacks and ships temporary firewall rules. |
| 22–23 October | Hosting companies, including Hostinger, Plesk and Vercel, roll out patched PHP versions. Security vendors publish detection guidance. |
As Tiffany Farriss, interim CEO of the Drupal Association, put it: “This issue impacts the majority of the Internet.”
Why so many websites went offline
Going offline was mostly a precaution, not a sign of a breach. The details leaked before a fix existed, so organisations faced a simple choice: stay online and exposed, or close the door until the patch was in place. Many chose the second, and that was the right call.
Some outages also lasted longer than they needed to, because many teams were simply not sure:
- which PHP version their sites actually run
- who is responsible for updating it: the agency, the host or an internal IT team
- which old microsites, landing pages and staging servers were still live
The bigger worry is the long tail. By CybelAngel’s count of Shodan data, 59% of versioned PHP hosts run PHP 8.1 or older, branches that get no official fix. WordPress.org figures cited in the same report show about 35% of WordPress sites on an unsupported PHP version. Those sites stay exposed until someone upgrades them.
Are you affected?
| Your PHP version | Status | What to do |
|---|---|---|
| 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later | ✅ Patched | Confirm that PHP workers were restarted after the update. |
| 8.2, 8.3, 8.4 or 8.5, earlier than the above | ⚠️ Vulnerable, fix available | Update now. |
| 7.4, 8.0 or 8.1 | ❌ No official fix | Use a vendor or long-term support package if your host offers one, then plan an upgrade. |
| 7.3 or older (including PHP 5) | ❌ No fix | Upgrade to a supported version, or take the site offline. |
How to check: in WordPress, go to Tools → Site Health → Info → Server. Most hosting control panels (hPanel, cPanel, Plesk) also show the PHP version for each site. Note that updating WordPress or its plug-ins does not update PHP: PHP belongs to your server, and your host or developer has to update it.
Seeing an “old” version number? Many managed hosts (including those built on CloudLinux, cPanel and Plesk) backport the fix into their own PHP builds without changing the version number. A site can show PHP 8.5.11 and still be patched. In that case, check the Build Date in your PHP info page (in hPanel: Websites → Dashboard → PHP Info). A build dated 21 October 2026 or later, plus written confirmation from your host, is what you want to see.
What to do this week: a checklist for website owners
Do
- List every site you own, including old microsites, campaign landing pages and staging servers
- Get written confirmation from your host or agency that the fix is installed, not just scheduled
- Check the PHP version on each site yourself
- Make sure PHP workers were restarted after patching
- Keep a web application firewall in place as an extra layer
- Review server logs for unusual activity since 20 October
Avoid
- Assuming a WordPress security plug-in protects you here
- Leaving unsupported PHP 7 or 8.1 sites online “for now”
- Relying on a firewall alone: it is a stopgap, not a fix
- Forgetting forms and portals that collect customer data
- Waiting for proof of attacks before acting
If you find signs of compromise, such as PHP processes launching shell commands, unknown admin users or unexpected files in your uploads folder, treat it as an incident. Take the site offline, preserve the logs, and restore from a clean backup on a patched server.
The lessons for marketing teams
PHP2Shell is a server problem, but it is also a marketing problem. Your website is where your ads, emails and sales teams send people. When it goes down, campaigns keep spending and leads stop arriving. Three lessons are worth keeping:
- Know your stack. Keep a simple register of every site and landing page, where it is hosted, its PHP version and who maintains it.
- Retire what you don’t use. Old campaign microsites are the doors attackers find first. Archive them, redirect them, then switch them off.
- Agree who owns updates. “We thought the host did it” is the most common answer after an incident. Put it in the contract.
The bottom line
PHP2Shell is one of the most serious web vulnerabilities in years, and the fix is simple: run a patched, supported version of PHP. The organisations that recovered fastest were not the biggest. They were the ones who knew exactly what they were running and who was responsible for it.
Not sure where your sites stand? Our development team can check your PHP versions, patch or upgrade your WordPress sites and landing pages, and clear out the forgotten ones. Ask us for a quick website security check.
Last updated 24 October 2026. This is a developing story; check the official PHP advisory for the latest guidance.
Sources
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- watchTowr: PHP2Shell FAQ
- Malwarebytes: PHP2Shell, why many websites had to go offline
- Engadget: Government websites in the EU and Canada taken offline
- CybelAngel: What we know about php2shell
- Unit 42: Threat brief on CVE-2026-109618 and CVE-2026-109619
- CNBC: Why governments pulled websites offline
