PHP2Shell PHP Vulnerability: What US and Canadian Website Owners Should Do

On October 21, 2026, the PHP project shipped emergency fixes for two critical security flaws that the press now calls PHP2Shell. PHP is the programming language behind WordPress and most other content management systems, so the PHP2Shell vulnerability touches nearly every small business website in the US and Canada, from a roofing contractor’s lead form to a dental clinic’s booking page. A vulnerability, in plain terms, is a flaw in software that lets an outsider do something they should never be able to do.

This page sums up the situation as of October 22, 2026: what happened, whether it affects your site, how to check your PHP version and what to do if the site already acts strange. The picture changes daily, so I link to the original sources. The servers Zen Webmaster looks after are already updated.

Short on time? I can check your site for signs of a break-in since October 17 and clean it up if anything turns up. See hacked website cleanup, from $100, with the exact scope set after diagnosis. If you prefer to handle it yourself, every step is below.

What happened

There are two flaws, CVE-2026-109618 and CVE-2026-109619. A CVE is the shared ID a vulnerability gets in every security database. Both allow remote code execution on the server without logging in, so no password or account is needed. Put simply: if things line up badly, an attacker can reach your site’s files and do whatever they want with them.

The PHP team rated both flaws 9.2 out of 10 on the CVSS scale, the standard way to score how severe a vulnerability is. That is very high. You may have seen 10.0 in early news stories. That number came from a leak before the official release, and the PHP Foundation says it is wrong. The same leak is why the fixes came out a day early, on October 21 instead of October 22.

The patched releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net). According to php.net, every PHP installation that answers web requests is at risk, which means practically every PHP website. The researchers who found the problem reported that the attack worked against certain versions of WordPress and other popular CMSs.

What we know about the attacks so far

At release time

The PHP team looked at the attack examples circulating online and found none that worked when the fixes went out.

First attempt on October 17

Amazon’s threat intelligence team saw an attack attempt on October 17, four days before the release, and more on October 21. Cloudflare and watchTowr report attempts too.

Stopgap protection

Cloudflare turned on web application firewall (WAF) rules for all customers, free plan included. That only helps if your site runs through Cloudflare, and it is not a substitute for the update.

This summary comes from the Tenable FAQ published on October 21. As of October 22 there are no reports of mass successful hacks. That is a matter of time, not a reason to wait. No need to panic, but no reason to put it off either: attempts are already happening, and the longer a server runs without the patch, the better the odds it gets hit.

Who is responsible for updating PHP

Your website does not update PHP on its own. Whoever runs the server does.

Shared hosting

Your site lives on a server shared with other customers of a hosting company. Fixes inside a branch, say from 8.3.35 to 8.3.36, are installed by the host. Your part is to confirm it happened and that your branch (8.3, 8.4) is not outdated. The branch is usually picked in the hosting control panel, in the PHP section.

Your own server or VPS

With a separate server (a VPS), the software on it is your job or your contractor’s. The host only rents you the machine. Nobody else will install the update.

If your site runs on a hosted platform such as Wix, Squarespace or Shopify, the platform manages the servers and there is nothing for you to do here.

How to check your PHP version in WordPress

In the WordPress dashboard go to Tools > Site Health, open the Info tab, expand Server and look at the PHP version line. Read the full number, for example 8.3.36, not just 8.3.

As of October 22, 2026, these versions and anything newer within the same branch count as patched:

Three things to keep in mind:

• The number may not match the table. Servers that use the PHP packages of a Linux distribution often get the fix without a new version number, so you might see something like 8.3.6 with the patch already applied. A suffix such as -0ubuntu or -deb after the number is a sign of exactly that kind of package. If your number is lower than the table, do not guess: ask your host whether CVE-2026-109618 and CVE-2026-109619 are fixed on their side.
• PHP 8.1 and older. The PHP project no longer releases updates for these. Some Linux vendors and long-term support providers ship their own fixes, but do not count on it. If you are on 7.x or 8.1, plan a move to 8.3 or 8.4 either way.
• PHP 8.2 stops getting fixes on December 31, 2026, so put a move off it on the calendar as well.

What to do today

1. Check your version as shown above and write it down.
2. Email your host, even if your version looks current: “Have the fixes for CVE-2026-109618 and CVE-2026-109619 been applied to my hosting account?” A good host answers quickly and clearly.
3. On your own server, ask whoever manages it to update PHP today. php.net lists temporary settings for people who cannot update right away. They only lower the risk, and they are a task for a server administrator, not for the business owner.
4. If your branch is outdated (8.1 or older), take a full backup, switch the branch in the hosting control panel, then test the home page, the contact form and checkout. Old themes and plugins may break on a newer PHP, which is why the backup comes first. If something breaks you can switch back with the same setting, but only as a short pause: the old branch stays vulnerable, so get a specialist involved right away.
5. Update WordPress, your theme and your plugins. This does not fix PHP2Shell, but it closes other doors attackers have known about for years.

If your site may already be hacked

Signs worth checking: the site sends visitors to pages you never made, Google shows odd pages under your domain, admin users you did not create appear in the dashboard, your host warns about suspicious activity or outgoing spam, or the browser shows a red warning. I go through the early signs in more detail in is my WordPress site hacked: 7 warning signs.

What to do, in this order:

1. Stay calm and do not delete anything yet. Once a suspicious file is gone, it can no longer show how the attacker got in.
2. Make a full copy of the site as it is now, files and database, and keep it apart from your regular backups. It is your evidence for working out how and when the break-in happened.
3. Review activity from October 17, 2026 onward. That is Amazon’s advice, since the first attempt was seen that day. Ask your host for server logs from that date and compare them with your backups. The last backup taken before October 17 is the most likely to be clean.
4. Confirm PHP is patched. Otherwise the attacker walks back in through the same door after the cleanup.
5. Clean the site: remove malicious code and unknown users, check the database and scheduled tasks.
6. Change every password after the cleanup, not before: WordPress admin, FTP or SFTP, database, hosting control panel, email. Change them earlier and the same malicious code may capture the new ones.
7. If personal data may have leaked (form submissions, orders, customer accounts), you may have notification duties. In the US, state laws on data breach notification apply, and in Canada there are provincial rules plus PIPEDA at the federal level. Check what applies to you; I am not a lawyer.

If server logs, databases and hunting for hidden code are not your thing, this is the part worth handing off.

Quick checklist

• check your PHP version under Tools > Site Health > Info > Server;
• ask your host whether CVE-2026-109618 and CVE-2026-109619 are fixed;
• on your own server, update PHP today;
• on 8.1 or older, back up, move to 8.3 or 8.4, then test the form and checkout;
• update WordPress, the theme and plugins;
• if anything looks off: keep a copy as evidence, review from October 17, clean up, then change passwords;
• if customer data may be exposed, find out which breach notification rules apply to you.

Where a DIY check should stop

Any owner can check the version and email the host. It takes about 15 minutes.

Past that point, your own time is usually better spent elsewhere if the site sits on a server nobody is updating, if you run PHP 8.1 or older on a site that has not been touched in a long while, or if you see even one sign of a hack. A cleanup done by eye often leaves a back door, and a week later it starts over. For a contractor heading into storm season or a shop getting ready for holiday shopping, that second round usually lands at the worst possible time.

If your time is worth more

If you have the time and the interest, the steps above are enough to close the hole and check your site calmly. If you would rather not dig through logs and files, I handle the technical side: a copy of the site, a search for traces since October 17, cleanup, closing the vulnerability and resetting access. Cleanup starts at $100, scope set after diagnosis. To make sure updates like this simply happen on schedule from now on, look at WordPress maintenance plans, from $79 a month. Prices are in US dollars.

Sources (checked October 22, 2026): release announcements of October 21, 2026, php.net; Today’s PHP security release, PHP Foundation; PHP2Shell FAQ, Tenable.