PHP2Shell is a pair of critical flaws in the Hypertext Preprocessor (PHP) language. The flaws let a stranger take over a web server without logging in. The fixes for the two flaws (tracked officially as CVE-2026-109618 and CVE-2026-109619) shipped on October 21, 2026. That same day, government websites across Europe went offline as a precaution, Reuters reported on October 22.
PHP is the language that runs on the server behind WordPress and most other popular website platforms. If your site runs on WordPress you or your host manage, this is about you. Sites on WordPress.com and Automattic's other hosted platforms were already protected. America's cyber defence agency told everyone to patch immediately.
PHP2Shell key facts
| Question | Answer | Source |
|---|---|---|
| What runs on PHP? | WordPress, Drupal, Joomla and Magento, among others | Reuters via The Globe and Mail |
| What is it? | Two flaws in PHP itself, each rated 9.2 out of 10 for severity (CVSS v4) | Patchstack |
| Who is exposed? | "All PHP installations serving web requests" | CISA |
| Which versions? | Every version back to PHP 5.4 | Wiz Research |
| What fixes it? | PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Nothing for 8.1 or older | CISA |
| How big? | PHP runs about 75% of sites with a known server language (W3Techs). About 1.5 million of 2.6 million PHP hosts seen by Censys run a version with no fix | Reuters via The Globe and Mail |
| Is anyone attacking? | Yes: "broadly exploited in the wild" | Amazon Threat Intelligence |
| Who found it? | Wiz researchers working with AI models; also credited to Calif and OpenAI Codex Security | The Hacker News |
The flaw sits in the interpreter, the program on the server that reads and runs PHP code. Your plugins and your theme are fine. The layer under them is broken.
What happened on October 21, and why did government websites go offline?
On Wednesday, October 21, the fixes came out. Organizations that couldn't confirm they were patched switched their sites off rather than risk a break-in. Reuters listed who went dark that day:
| Country | Sites that went offline |
|---|---|
| Netherlands | The National Cyber Security Centre, Port of Rotterdam, the Overheid.nl government portal, the KNVB football association, the five largest political parties, hospitals |
| Denmark | Kombit (the municipal IT body) and a school platform |
| Finland | Valtori, the state IT service centre |
| France | The Interior Ministry and info.gouv.fr |
Japan's prime minister told site owners to check whether they run PHP. Britain's cyber agency said organizations using any version are affected. It told them to look for installs they never set up themselves, and to consider going offline.
Why switch a site off instead of fixing it? Because the fix isn't one click. The language version on a server belongs to whoever runs that server. Many sites sit on versions so old that no fixed release exists. Going dark is the safe default while the right people do the update.
The leak, the fix and widespread attack attempts all landed within about 18 hours. The Hacker News has the timeline:
| Time (UTC) | What happened |
|---|---|
| Oct 20, about 20:00 | Calif accidentally posts a video of the attack |
| Oct 21, 03:02 | Cloudflare turns on blocking rules by default |
| Oct 21, 14:00 | The fixed versions are released |
| Oct 21, 14:19 | watchTowr reports active attack attempts, 19 minutes after release |
As of October 22, we found no advisory on this from Canada's national cyber centre, and no reports of outages here. That doesn't make sites here safe. The flaw doesn't care which country a server is in.
What does remote code execution mean for a business?
Remote code execution means a stranger on the internet can make your server follow their orders. It's as if they were sitting at its keyboard. With this flaw they don't need a password or an account first.
The researchers who found it showed it working on the latest official WordPress server image, a standard ready-made setup. It also worked on two other popular site systems. The flaw can also read the server's memory. That can leak passwords, tokens and keys to your payment, email and customer systems.
In plain terms, the outcomes look like this: a defaced homepage, malware served to your customers, stolen form entries, or your server used to attack someone else. We won't describe how the attack works.
> "The PHP situation will lead to a mass of incidents." > Kevin Beaumont, security researcher, who also called it "one of the biggest vulns in years," quoted by Help Net Security
Is my website affected by PHP2Shell?
Your site is affected if its server runs PHP and that copy hasn't been updated to a fixed version. Who does the update depends on how you're hosted. The table shows what each platform's own pages said as of October 22, 2026.
| How your site is hosted | Runs PHP? | Who updates it | Status on October 22 | What you do |
|---|---|---|---|---|
| Self-hosted WordPress, Drupal, Joomla or Magento on shared hosting | Yes | Your host | Exposed until the host updates. Reuters says small sites on shared hosting are at higher risk | Ask your host to confirm the version, in writing |
| Self-hosted on your own server | Yes | You or your developer | Exposed until you update | Update today, or take the site offline |
| WordPress.com, WordPress VIP, WP Cloud, Pressable (all run by Automattic) | Yes, managed | Automattic | Protected: "There is nothing you need to do." | Nothing for the platform itself |
| Shopify, Squarespace, Wix | Not stated | The vendor | We found no statement on PHP2Shell on their own sites on October 22 | Check with the vendor |
| Sites with no PHP on the server | No | Not applicable | Not reached by this flaw | Check old subdomains and add-ons for stray PHP |
Three details decide whether you're covered.
Updating WordPress, your theme or your plugins does not fix this. Automattic and Cloudflare both say so. The broken part sits one layer below. Every plugin can show green while the server is still open.
The version number on your dashboard can mislead you. One security news site notes that some server builds carry the fix under the old number. A written answer from your host beats a number on a screen.
"We don't use PHP" needs checking. A blog on a subdomain, a landing page an old agency built, or a booking tool on its own server all count. The British agency warns about exactly these forgotten installs.
Our guide on how to check the PHP version in WordPress shows the exact screens to look at.
Why does it matter that AI found PHP2Shell?
AI matters here because it made the flaw cheap to find. The gap between discovery and attack has shrunk to hours. That changes how fast you have to move.
The flaw itself is old. What changed is the cost of finding it. The researchers who found it wrote that one person, working with AI models, did in a week what used to take a world-class team months.
> "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." > Wiz Research, October 21, 2026
Others got there too. Reuters reports that a second team found the flaws with an AI model on August 1. The first team reported its find on August 24. Then Amazon's threat team caught an attack attempt on October 17, four days before the public announcement.
> "An embargo protects defenders only until someone else finds the same bug." > Amazon's security blog, October 21, 2026
An embargo is the quiet period when the maintainers know about a bug but the public doesn't, so a fix can be built. When AI lets many people find the same bug, that quiet period stops protecting anyone. Amazon's team now says patch timelines should be measured "in hours."
For a small business, the lesson is plain. "We'll get to the server updates next month" used to be a fair stance. After this week, it isn't.
What should I do about PHP2Shell this week?
Get written confirmation that your server is on a fixed version. Put a free firewall in front of the site until you have it. If you're on 8.1 or older and can't update, take the site offline. Here's the order we'd work in.
1. Ask your host to confirm the fixed version
Send one short message: "Is my site on one of the fixed releases, or a server build that includes the October 21 PHP2Shell fix? Please confirm in writing." The company behind WordPress.com gives self-hosted owners the same advice: ask your host.
If you're on 8.2, its security support ends at the end of this year, per php.net. The same company suggests 8.3 or newer as the better target. That way you don't do this twice in ten weeks.
| Version | Fixed release | Security support ends |
|---|---|---|
| 8.5 | 8.5.12 | December 31, 2029 |
| 8.4 | 8.4.27 | December 31, 2028 |
| 8.3 | 8.3.36 | December 31, 2027 |
| 8.2 | 8.2.35 | December 31, 2026 |
| 8.1 and older | None | Already ended |
2. Turn on a firewall as a stopgap
A web application firewall is a filter in front of your site. It blocks known attack traffic before it reaches your server. Cloudflare has rules for this flaw on every plan, including the free one. If you aren't using it, ask your host whether their firewall has rules for this flaw.
A firewall buys time but doesn't fix the flaw. The researchers are blunt: "Applying the PHP security update remains the only complete remediation." The WordPress.com team agrees: "These steps buy time. They are not a substitute for the update."
3. Skip the unofficial "fix" plugins
Patchstack warns against unofficial fix plugins and code snippets. A plugin can't repair the software running underneath it. A rushed one from an unknown author is a risk of its own. "Only an update is a complete fix," the firm says.
4. On 8.1 or older with no update path, go offline
The American agency's advice is direct: anyone on 8.1 or earlier, or anyone who can't update, "should take PHP-based systems offline." It sounds drastic. It's what government teams in four European countries did on October 21. A "back soon" page costs a few days of traffic. A breached server can cost you your customer data.
What does PHP2Shell mean for my website long term?
Long term, the software under your site needs an owner who updates it within hours, on any platform. That's a contract question as much as a technical one.
The sites that get hurt are the forgotten ones: the microsite from an old campaign, the plugin-heavy install nobody has logged into since launch. Hal Pomeranz, a security researcher, put it bluntly in the same report: "So many embedded installations out there that will never be patched."
| Option | What it means | Who carries the update duty |
|---|---|---|
| Stay on WordPress, managed hosting | Move to a host that patches the server for you, like the Automattic platforms above | The host |
| Stay on WordPress, self-hosted | Keep your setup and sign a maintenance contract with a response time in hours | You and your developer |
| Move to a setup with no PHP on the server | Rebuild the site on a stack that doesn't run PHP | Still someone. Every stack has its own updates |
None of these is wrong. WordPress itself wasn't the flaw, and its biggest managed hosts were protected on day one. Our companion piece, is WordPress safe after PHP2Shell, covers when staying makes sense and when moving does.
If you're weighing a move, read our take on site bloat and AI-native architecture and our headless migration guide. The sites we build do not run PHP on the server, so this flaw does not reach them. They still get their own updates, like any software.
What this guide does not cover
We're a web design studio, not a security firm. This post sums up public advice as of October 22, 2026, and it's moving fast. Check the American and British agency pages for updates.
We did not test the flaw. We found no statements from the three hosted builders in the table on their own sites, so we can't tell you their status. A firewall rule or a host's word isn't proof of a fix. Only a confirmed version is.
We'll check for free whether your site runs PHP and which version, at /audit.