PHP2Shell: Is Your Website Affected, and How to Check

Key Takeaway:
PHP2Shell is the nickname for two critical flaws in PHP, the language that runs WordPress and most of the web’s websites. Details leaked online on 20 October 2026 and PHP released fixes the next day: versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says the flaws can let an attacker run their own code on a server without logging in. If you run a website, find out which PHP version it really uses (WordPress shows it under Tools, Site Health), and make sure it’s one of those versions or newer. If you only visit websites, there’s nothing for you to update.

Most website owners never think about PHP. Their host installs it, WordPress runs on it, and it just works. That’s exactly why a flaw like this matters: millions of sites depend on someone else updating something they’ve never looked at. This guide explains what happened in plain English, who’s actually at risk, how to check your own site properly (including a trap we found on our own), and what to do next.

This is a fast-moving story. We’ll update this page as new facts are confirmed. Last checked: 22 October 2026.

What Happened

PHP’s security team found two serious flaws and planned to announce them together with the fixes, the normal way. Instead, on the morning of 20 October 2026, a post claiming the disclosure was coming appeared on Hacker News. It was taken down, but screenshots spread, so PHP announced the flaws that day and brought the release forward to 21 October at 14:00 UTC.

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and PHP rates both critical, 9.2 out of 10. In plain terms:

CVE-2026-109618 is a mistake in how PHP tidies up after a request when it runs out of memory. A carefully built request can corrupt memory at that moment and take control.
CVE-2026-109619 is a mistake where information from one visitor’s request can be left behind and reused by the next request handled by the same part of the server.

Both, in PHP’s words, “can allow unauthenticated remote code execution”: someone who has never logged in could make the server run commands of their choosing. On a website, that can mean a hidden back door, a stolen database, or a site quietly used to spread malware.

🛡️ Who’s at Risk

PHP says every PHP installation that serves web pages is in scope, whichever way it’s connected to the web server: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, the setup where PHP runs inside the Apache web server itself, because there an attacker’s request can trigger the attack before any of the site’s own code runs.

What that means for you depends mostly on who looks after your server:

How your site is hosted	Who updates PHP	What to do
Shared hosting	Your host	Check your host’s announcements, then confirm your PHP version once they say it’s done
Managed WordPress	Your host	Same as shared hosting; most will update without you doing anything
Your own server or VPS	You	Update PHP and restart every PHP process now
PHP 8.1 or older	Nobody, officially	PHP no longer updates these; ask your host or vendor, or move to a supported version

Hosting companies are reaching their own conclusions about their setups. Hostinger, for example, told its customers that its LiteSpeed-based shared hosting handles requests in a way the attack doesn’t work against, and that it was applying PHP’s fix across all its hosting anyway. That’s the right approach: a setup that blocks today’s known attack is good news, but only the update closes the flaw itself.

Is It Being Exploited?

The honest answer on 22 October is: attackers are trying, and the evidence of real break-ins is still thin.

The security firm watchTowr says it is “observing active exploitation attempts” of both flaws against its network of decoy servers.
Huntress, which watches its customers’ systems, said on 21 October that it had not seen in-the-wild exploitation on those systems.
The US agency CISA had not added either flaw to its list of vulnerabilities known to be exploited, as of its 21 October update.

Leaked details and a published fix give attackers a map: they can compare the fixed code with the old one to see exactly what changed. Treat the update as urgent rather than waiting for confirmation.

How to Check Your Site’s PHP Version, Properly

These are the versions that contain the fix. Your site needs to be on one of them, or newer:

If your site runs	It’s fixed from
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35 (and 8.2 itself stops getting updates on 31 December 2026)
PHP 7.4, 8.0 or 8.1	No official release; PHP published minimal fixes that vendors can build in. Ask your host
Anything older	No fix. Upgrade to a supported version

The reliable ways to check

In WordPress: go to Tools, Site Health, open the Info tab, and expand Server. The PHP version is listed there.
In your hosting control panel: most panels show the PHP version in the website’s PHP settings, usually in the same place where you can switch versions.
On your own server: run php -v, and remember the web server’s PHP can be a different version from the command-line one.

The trap: an outside check can show an old version

Many servers announce their PHP version in a hidden header sent with every page, called X-Powered-By, and tools that check a site from outside, including our Security Headers Checker, will show it to you. It’s a useful clue, but it can mislead in two ways.

First, caching. We found this on our own site while writing this article. After switching our PHP version, pages served from the site’s cache still carried the old header, PHP/8.3.35, while freshly built pages said PHP/8.4.26. The cache had stored the header along with the page. Until we purged the cache, every outside check reported a version we were no longer running. If you use a caching plugin or your host caches pages, purge the cache before trusting an outside check, or use the methods above.

Second, backported fixes. Some Linux distributions fix security flaws without changing PHP’s version number. On those systems, an older-looking number can be patched. If your server’s PHP comes from your Linux distribution, check that distribution’s security advisories rather than the number alone.

What to Do Now

On shared or managed hosting: check your host’s status page or emails for PHP2Shell. Once they say the update is done, confirm the version in Site Health or your control panel.
On your own server: update to a fixed version, or your distribution’s patched package, then restart every PHP process (PHP-FPM, Apache or LiteSpeed). Processes that keep running carry on using the old code until they restart.
If you can’t update today: PHP lists temporary settings that make the known attacks harder, such as turning off session.upload_progress.enabled and lowering post_max_size. PHP is clear that these “reduce exposure to specific attack paths but do not make an installation safe”, so treat them as a stopgap for days, not a fix.
Stop advertising your version: setting expose_php = Off in PHP’s settings removes the X-Powered-By header. It doesn’t fix anything, but it stops your site telling every scanner exactly what to try.
Look for signs of a break-in if your site was unpatched and exposed: new administrator accounts you didn’t create, unfamiliar files in the website’s folders, new scheduled tasks, and on your own server, PHP starting command shells or network tools it has no reason to run. If you find anything, take the site offline, keep the logs, and ask your host for help.

Frequently Asked Questions

I don’t run a website. Do I need to do anything?

No. PHP runs on web servers, not on your phone or computer, and there’s nothing for visitors to install. The risk to visitors is indirect: a site that’s been broken into can be used to show fake pages or spread malware, which is one more reason to be careful with unexpected downloads and sign-in pages.

Is WordPress itself vulnerable?

The flaws are in PHP, the language WordPress runs on, not in WordPress or its plugins. Updating WordPress won’t fix this; updating PHP will. That’s also why sites built on other PHP software, such as Drupal, Joomla, Magento or custom code, are in the same position.

My host says I wasn’t affected. Do I still need the update?

Yes, but it’s usually your host’s job, not yours. A host can reasonably say its setup blocks the known attack, and still apply the fix, because someone could find a different way to trigger the same flaw later. Check that the update has actually reached your site, using Site Health or your control panel.

Why does a checker still show my old PHP version?

Most likely your pages are cached: the cache stored the old version header along with the page. Purge the cache and check again, or read the version in WordPress Site Health, which always shows the version actually running.

What about PHP 7 or PHP 5?

PHP 5 and most of PHP 7 haven’t been supported for years and won’t get an official fix. PHP did publish minimal fixes for 7.4, 8.0 and 8.1 that vendors can build in, so ask your host. If your site still runs on one of these, this is a good moment to plan the move to a supported version.