On October 21, 2026, the PHP project shipped emergency fixes for two flaws in PHP itself. If your company website runs on WordPress, or on most of the website systems built in the last twenty years, it runs on PHP. The flaws let an attacker on the internet run their own code on the server behind your website, without a password.

There is no button in your WordPress dashboard for this one. The fix is an update to the server software underneath the site, and whether it has happened depends entirely on who looks after that server. At a lot of small companies, nobody is quite sure who that is.

What PHP2Shell is, in plain English

PHP is the programming language that assembles a web page each time someone visits. WordPress, Drupal, Joomla, WooCommerce stores, and countless custom sites are written in it. It runs on the web server, out of sight, and most site owners never think about it.

PHP2Shell is the name for two flaws, CVE-2026-109618 and CVE-2026-109619. Both are mistakes in how PHP manages memory while it handles a visitor’s request. Each is rated 9.2 out of 10 on the industry’s standard severity scale. Because the mistakes are in PHP itself, a site can have clean, current code and still be exposed. Security firm watchTowr’s summary is blunt: every PHP installation that serves web requests is in scope.

Three things make this different from the usual plugin warning:

  1. It is below your website, not in it. Updating WordPress and every plugin does nothing for PHP2Shell. The fix is a new version of PHP on the server.
  2. The attacker needs no login. The attack arrives as a web request, the same way a visitor does.
  3. Old versions get no official fix. PHP stopped supporting version 8.1 and older before these flaws were found, and plenty of small business websites still run on them.

What has actually happened so far

The timeline was rushed. Details leaked online on October 20, two days before the planned announcement, and PHP released the fixed versions the next day, according to watchTowr. Amazon’s threat intelligence team later reported an attack attempt against one of its decoy servers on October 17, four days before the public disclosure, as reported by Help Net Security and Datadog Security Labs. watchTowr says its own decoy network has seen attacks since October 21, and Sansec’s timeline records Cloudflare reporting early attacks that morning, before the fix was out.

The honest caveat is that the worst case has not arrived. On October 22, Sansec, a security firm that focuses on online stores, wrote that mass exploitation now looks less likely than it did on release day, and that the public attack code does not work against a default PHP installation. That is good news for this week. It is not a reason to wait. Researchers at Wiz told Help Net Security that AI models had substantially lowered the effort needed to turn this long-standing flaw into a working attack, and a server that stays unpatched stays exposed for as long as it runs.

Why the fix depends on who runs your server

Sansec put it plainly: “you cannot fix PHP2Shell from within your store code.” Somebody with access to the server has to update PHP and restart it. Who that is depends on how your site is hosted.

  • Managed WordPress hosting or shared hosting. Your host runs PHP for you and is responsible for the update. Ask them to confirm, in writing, which PHP version your site runs now.
  • A server your company or developer rents. If your site runs on its own cloud server, the update is your company’s job, even if nobody has logged in since the site launched. This is the case most likely to have fallen through the cracks.
  • A site an agency built and handed over. Some agencies host for a monthly fee and patch on their own schedule. Others handed over the keys at launch and moved on. Find out which one you have.

If you cannot say which of these describes your site, that is the real finding, and it matters more than the version number. It is the same “who is watching” gap our guide to patching and vulnerability monitoring describes for firewalls and print servers.

Which versions are fixed

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, or anything newer in the same line. A site on PHP 8.3.20 needs the update to 8.3.36. It does not need to move to 8.5.

Older versions are where it gets complicated.

  • PHP 7.4, 8.0, and 8.1. No official fixed release. The PHP security team published source code fixes, and some Linux distributions and extended-support vendors ship patched packages, sometimes without changing the version number. A site on PHP 8.1 can be fixed, but only if its host installs one of those packages, and the only way to know is to ask.
  • PHP 7.3 and older, including PHP 5. No fix exists, and watchTowr confirmed that PHP 5 is affected too. These sites need an upgrade to a supported version of PHP, which often means updating the website itself so it runs on the newer version. That is a project, not a patch.

Temporary measures, and what a firewall does not do

While they update, hosts can change a few PHP settings and block some kinds of uploads to make an attack harder. PHP’s own position, as watchTowr reports it, is that no configuration change fully closes these flaws. Treat those settings as a stopgap measured in days, not a fix.

The same goes for a firewall in front of your site. Cloudflare said that PHP sites behind its network had an initial set of protective rules in place on release day, which helps against the attacks those rules recognize. It does not fix the server. Someone who finds a way around the rules, or around Cloudflare entirely, still finds an unpatched PHP behind it.

What a well-patched website looks like

  1. A named owner for the server. One person or company is responsible for PHP updates, and you know who it is.
  2. A known PHP version. Your host or developer can tell you the exact version your live site runs, today.
  3. Proof the fix is in. For PHP 8.2 and newer, the version number shows it. For older versions, the installed package’s change notes list CVE-2026-109618 and CVE-2026-109619.
  4. Every copy covered. The staging site, the old campaign microsite, the second WordPress install someone set up in 2019. Datadog Security Labs notes that the PHP version a developer sees when logged in to a server can differ from the one serving web pages, so the check has to be on the live site.
  5. A restart after the update. PHP keeps running the old code until it restarts. The update is not finished until that happens.
  6. A plan for old PHP. If your site runs PHP 8.1 or older, there is a date for moving it to a supported version.

Where you stand, in two questions

  1. Who updates the server your website runs on? A name or a company, not “the host, probably.”
  2. Could they tell you today which PHP version it runs, and whether it includes the October 21 fix?

Our free external check reads what your website already shows the public and tells you whether it reports a vulnerable PHP version. Many well-run sites hide their version, which is good practice, and then the check cannot tell from outside, so the two questions above still matter. If the answers are unclear, our cybersecurity page covers how we run security for clients, or start a conversation and we will tell you where you stand.