Critical PHP Flaw (php2shell): Is Your Website Exposed?

If your website suddenly shows an error page today, or a vendor emailed you about “an urgent PHP update,” you are seeing the same story as thousands of other businesses. On October 21, 2026, the PHP project released fixes for two critical flaws, and governments and hosting companies have been scrambling ever since.

PHP is the programming language behind a huge share of business websites, including most WordPress sites. This post sticks to what has been confirmed by primary sources, flags what has not, and gives you a short list of things to do today. We will update it as the facts change.

Key takeaways:

• Two flaws, CVE-2026-109618 and CVE-2026-109619, let an attacker run commands on a web server without logging in. The fix is to update PHP, and the PHP project says there is no complete workaround.
• The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no fixes from the PHP project, so those sites need a vendor patch or an upgrade.
• Many hosts patch for you. Ask yours, in writing, whether the fix is applied rather than assuming it is.
• Some of the outages are precaution, not damage. Agencies told people to take unpatched sites offline, and some did.

What actually happened

The PHP project announced the fixes on php.net on October 21. Both flaws are rated 9.2 out of 10 on the CVSS v4.0 severity scale, which is the top tier. According to the PHP project, they allow a stranger to attack a server with a single request, before your website’s own code even runs.

In plain terms, the flaws are in how PHP handles a server running out of memory and how it cleans up after one visitor’s request. The PHP project describes the first as a case where the out-of-memory handling can interrupt PHP “while internal request data is only partially initialized,” and the second as leftover state from one request that a later request can reuse. Both can lead to remote code execution, meaning the attacker gets to run their own commands on your server.

The flaw is in PHP itself, not in WordPress, Drupal or any single plugin. That is why it is so broad.

Who is affected

The US cybersecurity agency CISA says the flaws affect all PHP installations serving web requests. The UK’s National Cyber Security Centre (NCSC) says organisations using any version of PHP are affected. Security firm Palo Alto Networks reported, in a threat brief from its Unit 42 team, over 22.6 million exposed instances. That is one vendor’s scanning data, so treat it as a rough scale rather than a precise count.

You are likely exposed if you have any of these:

• A WordPress, Drupal, Joomla or Magento site
• A customer portal, booking system or online store built on PHP
• Software you did not build but that “includes PHP,” such as some web-based accounting, scheduling or CRM tools
• An old website nobody has touched in years, which is the most dangerous kind

Is it being exploited?

Here the sources disagree, so be careful what you repeat. CISA said it had not observed exploitation at the time it published. The PHP project says an exploit has been demonstrated. Palo Alto Networks says it has seen proof-of-concept code. Brian Krebs reported that Cloudflare had already detected some exploitation, and that Wiz expects attackers to mass-exploit the flaws to plant web shells (a hidden backdoor on a web server).

We cannot independently confirm which of those is the full picture today. The safe assumption: working attack code exists, and attackers are scanning. Patch as if you are being targeted.

Why are websites going offline?

Two reasons, and only one of them is damage. Several government agencies, including some in Europe, took sites down as a precaution after warnings to take anything unpatchable offline. And the sudden wave of emergency updates means hosts are restarting servers, which can cause brief errors.

You may have seen headlines claiming a large percentage of the internet is “going dark.” We could not find a primary source for any such figure. The accurate statement is that the vulnerability is very broad, and the visible outages so far are mostly precautionary.

What to do today

1. Find out where PHP lives. List every website, portal and web-based tool your business runs or depends on. Include anything a vendor hosts for you.
2. Ask your host or vendor directly. The question: “Has PHP been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the equivalent patched package from our operating system vendor?” Distribution packages sometimes carry the fix without changing the version number, so a vendor’s confirmation matters more than a number.
3. If you manage the server yourself, check your version with php -v, then update to a fixed release. That command shows the command-line version, which can differ from the one your website uses, so check the web setup too.
4. If you are on PHP 8.1 or older, the PHP project no longer fixes those versions. It does publish minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux vendors offer backports. Otherwise plan an upgrade now.
5. If you cannot patch today, CISA and the NCSC both say to consider taking the system offline until you can. A web application firewall may help in the meantime. Cloudflare has said it deployed protective rules available to all customers, including free accounts, but its own CTO called them a stopgap.
6. Do not rely on the interim settings. The PHP project lists a few configuration changes that reduce exposure to specific attack paths, and states plainly that they “do not make an installation safe.” Updating is the only real fix.

After you patch, look for signs of a break-in

Patching closes the door but does not tell you whether someone already walked through. CISA suggests watching for PHP worker processes launching shells or downloading tools. For a small business, the practical version is: ask whoever runs your hosting to check for new or modified files on your web server and for unfamiliar admin accounts, especially if the site sat unpatched for any stretch. If anything looks wrong, change your passwords and keys and treat it as an incident.

Where we can help

Knowing what you run is the hard part of a day like this. Our managed IT service and cybersecurity services are built around keeping that inventory and patching it on a schedule, so an emergency like this one becomes a checklist instead of a scramble.

If you are not sure where PHP is hiding in your business, book a free assessment and we will help you build that list. For background on why fast patching matters so much, see our post on ransomware protection for small businesses.

This is a fast-moving situation. Details here reflect public sources as of October 21, 2026. This post is general information, not advice for your specific systems. Confirm next steps with your hosting provider or IT team.