PHP2Shell: Is Your Website Safe, and Who Should Fix It?
- PHP2Shell is two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619), fixed on October 21, 2026. They let attackers run code on a web server without logging in.
- Almost every PHP version since 5.4 was affected, so any site or tool running on PHP was exposed until its server got the fix.
- Updating WordPress, Drupal or plugins didn't help. Only whoever runs the server could install the fixed PHP version.
- Governments, hospitals, banks and media worldwide took sites offline as a precaution. As of October 22, no break-in of a specific site has been publicly confirmed.
- Webflow-hosted sites don't run on a PHP server that customers manage, so there was nothing to patch for this flaw. Access, custom code and third-party scripts still need an owner.
- The real lesson isn't about one platform. Every website needs a named owner for each layer, before the next warning comes.
PHP2Shell is a pair of critical flaws in PHP, the language behind about 69% of websites with a known server language, including WordPress, Drupal and Magento. Until the fix landed on October 21, an attacker could take over an affected server with a single request, no password needed.
The fix had to be installed on the server, not in the CMS. So sites were only safe once their host or IT team updated PHP.
What Is PHP2Shell?
Two memory bugs in PHP's core, both rated 9.2 out of 10. In plain terms:
- CVE-2026-109618 corrupts memory when a request runs out of memory, which an attacker can turn into running their own code. It can also leak data from the server's memory, like passwords, session tokens and API keys.
- CVE-2026-109619 lets leftover data from one visitor's request be reused by the next request on the same server process.
Both are triggered before the website's own code runs. That's why a login screen, a security plugin or a fully updated CMS couldn't stop them.
How Did It Unfold?
- October 17: Amazon's honeypots recorded an exploit attempt, four days before public disclosure.
- October 20: Details leaked early, so PHP moved its fix forward by a day.
- October 21, 03:02 UTC: Cloudflare switched on firewall rules for all customers as a stopgap.
- October 21, 14:00 UTC: PHP released the fixed versions. Exploitation attempts started within minutes.
The flaws were found by researchers at Wiz, Calif and OpenAI's Codex Security team, with AI models helping turn them into working exploits.
Which Websites Were Affected?
Any internet-facing site running PHP, anywhere in the world. VulnCheck puts that at about 2.6 million servers. Government agencies, hospitals, banks, universities and media took sites offline across many countries, mostly as a precaution, not because they were hacked.
Here's how it played out in some markets we operate in:
- United States: CISA urged immediate patching, and the FBI advised watching for PHP processes that launch shells or download files. BambooHR took its service offline as a precaution in the US, Canada and Ireland. WordPress and Drupal host Pantheon blocked more than 60,000 suspicious requests for its customers.
- Belgium: The Centre for Cybersecurity Belgium (CCB) advised patching immediately or taking sites offline. FOD Financiën, the courts, e-ID, Smartschool, Stad Gent, the Port of Antwerp-Bruges, VRT and hospitals including UZ Gent and UZA went offline temporarily. The CCB reported no attacks on Belgian sites on October 21.
- Netherlands: DigiD, MijnOverheid, the Tweede Kamer, the NCSC's own site, the Dutch Data Protection Authority, RTL and Tweakers went offline. The NCSC had seen no active exploitation in the Netherlands and advised treating every public PHP system as vulnerable until updated.
Why Didn't Updating WordPress or Plugins Fix It?
Because the flaw sat one layer below the CMS. WordPress, Drupal and their plugins run on PHP, and PHP runs on the server. Updating the CMS changes nothing in PHP.
So the question on October 21 wasn't “is our CMS up to date?” It was “who installs PHP updates on our server, and are they online today?” Here's how that played out by setup:
| Setup | Who installs the PHP fix | What your team had to do |
|---|---|---|
| Self-managed server (VPS or in-house IT) | Your IT team or developer | Install fixed PHP, or take the site offline until then |
| Managed or shared hosting | The hosting provider | Confirm the host deployed the fix |
| Agency-run hosting | The agency, if it's in the contract | Confirm who's responsible and that it's done |
| PHP 8.1 or older (any setup) | Nobody automatically: no official fixed release | Upgrade PHP or get a vendor backport, and isolate the site until then |
| Webflow-hosted site | Nobody: there's no PHP server for you to run | Nothing for this flaw, review access and custom code |
Older versions were the hardest case. PHP only released official fixes for 8.2 and newer. Versions 7.4 to 8.1 got source-code fixes that hosts had to build themselves, and older versions got none. According to W3Techs, about a third of PHP sites still run PHP 7 or older.
Our suggestion: Ask your host, IT team or agency one question today: “Which PHP version runs our website, and who installs the fix when the next warning comes?” If nobody can answer within a day, that gap is a bigger risk than PHP2Shell itself.
Could This Happen on Webflow?
Not this specific flaw. Webflow-hosted sites don't run on a PHP server that customers manage or update, so there was nothing to patch and nothing to take offline. Webflow hosting is run and maintained by Webflow itself.
That doesn't mean a Webflow site needs no security owner. The risks just sit in different places:
- Account access: Who can log in to your Workspace, and is two-factor login or SSO switched on?
- Custom code: Scripts added through embeds or custom code run in every visitor's browser.
- Third-party tools: Analytics, chat widgets, forms and integrations like HubSpot, Make or Zapier each have access to your data.
- Everything else on your domain: A blog, careers portal or self-hosted tool on PHP is still exposed, even if the main site is on Webflow.
Why Does Website Security Matter More Now?
Because the time between a fix and an attack is now measured in hours. PHP2Shell showed three shifts:
- Attacks start before or right after the fix. The first attempt came four days early, and new attempts started within minutes of the patch.
- AI speeds up both sides. It helped researchers find these flaws, and it helps attackers turn a published fix into a working exploit.
- Downtime is a marketing problem too. An offline site collects no leads, sends paid traffic to an error page, and stops all publishing until someone else fixes the server.
None of this is new. What changed is how little time there is to respond, which makes knowing who's responsible more important than which platform you use.
What Should You Do Now?
Confirm the fix is installed, not just scheduled. Then make sure the next warning doesn't start with a search for names.
If Your Site Runs on PHP
- Check the PHP version. Ask your host or IT for the exact version. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or newer.
- Handle old versions. On PHP 8.1 or older, upgrade or get a vendor backport. Until then, keep the site offline or behind strict firewall rules. Plan the move off 8.2 as well: it reaches end of life on December 31, 2026.
- Review logs from October 17 onward. Look for memory-limit errors, unexpected shell processes and unusually large form submissions. If anything looks off, change passwords and API keys, since one of the flaws can leak them.
- If you take the site offline, return a 503 status. It tells Google the downtime is temporary, which protects your rankings during a short outage.
If Your Site Runs on Webflow
- Check everything else on your domain for PHP: subdomains, landing page tools and self-hosted apps.
- Review Workspace access. Remove former freelancers and agencies, and switch on two-factor login.
- Audit custom code and third-party scripts. Remove what nobody uses and note who owns the rest.
For Every Team
- Name an owner for each layer: hosting, server software, CMS, plugins or custom code, and integrations.
- Agree who can take the site offline: and who tells marketing when it happens.
- Keep a one-page site inventory: platform, host, versions, owners and emergency contacts.
Should You Change Platforms Because of PHP2Shell?
Not in a rush. Patch first, then decide calmly. Sites on managed hosting were often protected quickly, because their host owned the server layer and acted fast.
The better question is who you want to own security in the long run. If your team wants full control and has the people to run servers, a well-managed PHP setup works. If you'd rather not own server updates at all, a managed platform like Webflow takes that layer off your plate.
Either way, plan any move properly. Our guides on WordPress to Webflow migration and keeping SEO during a CMS migration cover how to switch without losing rankings.
Frequently Asked Questions
No action was needed on Webflow-hosted sites, because customers don't run or patch a PHP server on Webflow. Other PHP tools on your domain still need checking.
Not on its own. PHP2Shell was in PHP itself, so only a fixed PHP version installed on your server closes it.
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or newer. Versions 8.1 and older need a vendor backport or an upgrade.
As of October 22, no break-in of a specific site has been publicly confirmed, but exploitation attempts are widespread. Most sites that went offline did so as a precaution. Check your logs from October 17 onward.
Yes, if it runs on PHP and the fix isn't installed. Authorities in Belgium and the UK advised exactly that. Return a 503 status so search engines treat it as temporary.
Only if personal data was accessed. Then you must notify your data protection authority within 72 hours of becoming aware of it. This isn't legal advice, so check with your data protection officer.
