PHP2Shell: What the PHP Warning Means for Your Website

What Happened, in Plain English

PHP is the programming language that most of the world's websites are written in. WordPress is written in it, and so are Drupal, Joomla, Magento and a long tail of custom sites built over the last twenty years. Wiz, one of the security firms that found the holes, puts PHP at around seventy percent of all websites.

On 21 October 2026 the PHP project released emergency fixes for two flaws in the language itself, in the parts that handle memory and errors. Under the right conditions, a crafted request to a PHP server lets an attacker run their own code on it, without a password and before the website's own code even starts. The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10, and together they picked up the nickname PHP2Shell.

The release was meant to be coordinated. It leaked two days early, proof-of-concept attacks circulated before the fix was out, and several security companies reported attempts against real servers on the day. Some websites went into maintenance mode to patch. That is why the warning emails arrived with the word urgent in the subject line.

Who Is Affected

Every PHP installation that serves web traffic: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, according to the PHP security team. They consider Apache with mod_php the highest risk, because that is where a working attack was demonstrated before any application code runs.

In practice that means: if your website is WordPress, it is affected until the server underneath it is updated. The same goes for any other PHP site, including ones built years ago by someone who has since moved on. The hole is not in WordPress, your theme or a plugin. It is in the language they are written in, which is why updating any of those three does nothing here.

Sites that do not run PHP are not affected. A site built as a static site, or on a platform like Squarespace, Shopify, Webflow or Wix, has no PHP for an attacker to reach. If you are not sure which kind you have, the next article in this series shows you how to tell in five minutes, or send us the address and we will tell you.

What to Do Today

Ask one question

To your host, in writing: "Which PHP version is our server on, and when was it updated?" The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything else is not fixed.

Do not stop at WordPress

Updating WordPress, the theme and the plugins changes nothing here. The hole is in PHP, the language they are written in. Only the server's PHP update counts.

If they cannot answer

That is your answer about the host. Put the domain behind Cloudflare today (its free firewall has blocked these attacks since 21 October) while you decide what comes next.

If you were exposed for days

Ask for a quick check of the site: unexpected files, new users, unfamiliar scheduled tasks. Most hosts will do it; a developer can do it in an hour.

Pixel art of two monitors side by side: one showing a WordPress dashboard with a green updated tick, the other showing a terminal with a PHP version number in red — The green tick in WordPress means nothing here. The number that matters is the PHP version on the server.

The Versions That Count

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything newer than those. A server reporting 8.3.35, for example, is one release short and not fixed. PHP 8.1 and older no longer receive updates from the PHP project at all; some Linux distributions and extended-support vendors have backported a fix, but if your host cannot name theirs, treat the server as unpatched. PHP 8.2 itself reaches end of life on 31 December 2026, so a server on 8.2 has a second deadline close behind this one.

The PHP team's own words: "There are no complete mitigations, updating is the only safe choice." A firewall in front of the site (Cloudflare switched protection on for all its customers, including free plans, on 21 October) reduces the exposure and is worth having, but it is not a fix.

If You Are on Managed WordPress Hosting

Flywheel, WP Engine, Kinsta, SiteGround and the like run PHP for you, and most hide the version number from the outside world. That is normal, and it means the only way to know is to ask them. A good managed host will have patched within hours and will tell you the date. A host who cannot answer the question is telling you something too.

Smaller New Zealand hosts on shared cPanel or Plesk servers vary more. Checking a handful of sites this week, we found two servers still reporting PHP 8.3.31 and 8.3.35 a day after the fix. Both are one question to the host away from knowing.

Why Our Clients Got a Different Email

Every site we have built is a static site: generated once, served as plain files from a global network, with the interactive parts running on services built for one job each. There is no PHP anywhere in them, not in a plugin, not in a theme, not on a server waiting to be patched. We checked all of them on the morning of 22 October anyway, because checking is the job. All clear.

That is not a boast about being unhackable; nobody is. It is a smaller surface. When the next PHP2Shell comes along, and it will, the owners of those sites will get the boring email again. If you would rather be one of them, the third article in this series is about when a move is worth it, and when it is not.

Key Takeaways

Two critical PHP holes, fixed 21 October 2026, let attackers run code on a server with no login.
WordPress, Drupal, Joomla and any PHP site are affected until the server's PHP is updated.
Updating WordPress, themes or plugins does nothing. The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Ask your host for the version number and the date, in writing.
PHP 8.1 and older get no fix. PHP 8.2 reaches end of life on 31 December 2026.
Sites that do not run PHP are not affected at all.

FAQ

What is PHP2Shell?

The nickname for two critical security holes in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and rated 9.2 out of 10. They let an attacker run code on a web server without logging in. Fixes were released on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Does PHP2Shell affect WordPress?

Yes, because WordPress runs on PHP. So do Drupal, Joomla, Magento and most PHP applications. The hole is underneath WordPress, in the language it is written in, so updating WordPress, your theme or your plugins does not fix it. Only updating PHP does.

How do I know if my website runs PHP?

If it is WordPress, it runs PHP. Otherwise ask whoever built or hosts it, or check the response headers: many servers announce a PHP version. The free check on this page does that for you within the hour.

My host says they have patched. Am I safe now?

If the server is on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a later release) and PHP was restarted, yes, for this pair of holes. Ask them to confirm the version number in writing. PHP 8.1 and older receive no fix from the PHP project and should be upgraded.

Was my site hacked?

Receiving a warning email does not mean a compromise was found; hosts sent them to everyone. Attack attempts were seen in the wild from 21 October, so a site that was unpatched for days afterwards is worth a check: unexpected files, new admin users, odd outbound traffic. Your host or developer can do that in an hour.