PHP2Shell Vulnerability: What a Website Owner Should Do Now

In late October 2026, two critical vulnerabilities were found in the PHP interpreter itself, and researchers report they are already being used in real attacks. They do not affect one particular CMS: any site running on PHP is in scope, whether WordPress, OpenCart, Joomla, Drupal or custom code. Below: what is known, how to check your version in five minutes, what to do today and what to do if you cannot update right away.

What is known

Everything below comes from Patchstack and watchTowr. These are fresh reports and details may change, so also check PHP's official announcement.

• The flaws are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0 (critical).
• No authentication is needed: sending a request to the site is enough.
• The bug is in PHP itself, not in a plugin or theme. The first involves running out of memory in the middle of handling a request; the second leaves request state in memory after it is freed, and the next request on the same worker can pick it up.
• All web ways of running PHP are affected: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, FrankenPHP. Patchstack rates mod_php as the riskiest.
• watchTowr has recorded exploitation attempts in its honeypot network since 21 October 2026; Patchstack says hosting partners reported active incidents. When this was written, CISA had not yet added them to its known exploited catalog.
• According to Wiz research cited by Patchstack, the flaws allow not only code execution but also reading process memory, which can hold passwords, tokens and API keys.

In numbers

• According to W3Techs on 27 October 2026, PHP is used by 69.2% of websites with a known server language. Of those, 65.6% run PHP 8, 26.6% PHP 7 and 7.7% PHP 5. So roughly one in three PHP sites (34.4%) is on version 7 or older, which have no official fixes. We do not quote W3Techs minor-version splits: "8" also includes 8.0 and 8.1, which are likewise unpatched.
• Our own external survey of Ukrainian sites (114 sites, August to September 2026): 50 run WordPress, WooCommerce or OpenCart, that is, PHP. Only 7 of those 50 openly show their PHP version in response headers. Of those seven, 6 are on branches without security support (5.5, 7.3 on four sites, 7.4), and the seventh is on 8.3.33, below the fixed 8.3.36.
• This is a small sample and shows only those who do not hide the version. The other 43 sites could be in any state, which cannot be seen from outside. A version header also does not prove a site is vulnerable: a host may have backported the fix into an old package. So check the version from the inside.

Does this affect my site

If the site runs on PHP, yes, unless the version is updated. The fixed versions:

A version number can mislead: hosting providers and distributions often backport fixes into old packages without changing the number. According to the vendors, cPanel (ea-php 7.4 to 8.1), CloudLinux, TuxCare and Hostinger have shipped fixed builds for old branches too. So for 8.1 and older, look not only at the number but at the build date and the package changelog (fixes dated 21 October 2026 or later), and ask your host in writing.

Next.js, Node.js or static sites are not affected by themselves, but the same server often holds an old WordPress or a PHP-based mail or control panel. Check the server, not only the main site.

How to check your version in five minutes

1. In your hosting panel (cPanel, ISPmanager, Plesk) find "PHP version" or "PHP Selector".
2. With SSH: php -v. That is the command-line version; the web may run on another.
3. In WordPress: Tools → Site Health → Info → Server.
4. Compare the exact number, not just the branch: 8.3.35 is still vulnerable, 8.3.36 is not.
5. Remember subdomains, staging copies and old sites on the same account: each may run its own version.

What to do today

1. Update PHP to the fixed version of your branch. On shared hosting this is usually a switch in the panel; if the fixed version is not offered yet, ask your host.
2. Restart all PHP processes after the update, otherwise old code stays in memory.
3. Test compatibility on a copy. Moving, say, from 7.4 to 8.4 breaks outdated plugins and modules, so doing it directly on the live site is risky.
4. If you cannot update immediately, reduce risk with the stopgaps named by Patchstack and the PHP team: disable session.upload_progress.enabled, limit request size and field counts at the web server, use WAF rules (for example Cloudflare). They close only known paths and are not full protection: PHP says plainly that updating is the only reliable route.
5. Do not leave a site on PHP 8.1 or older without a plan. PHP will ship no new fixes for them.

If the site may have been breached

The flaws act below the application level, so site logs may show nothing. Warning signs: unusual requests with large bodies (multipart), sudden 500 errors and out-of-memory messages, unexpected PHP worker restarts, odd or oversized PHPSESSID cookies.

If you suspect a breach:

• change passwords for the admin area, database, FTP/SSH and API keys, since process memory may have been read;
• check for new files and administrators and compare files with a clean copy;
• restore from a backup made before 20 October, and only after updating PHP.

Why "just update" is not always simple

Updating PHP on an old project runs into its code. Old themes, custom modules and unmaintained plugins may not work on a new branch. The options are then: update the plugins, replace them, fix the code or move the site to a modern platform. This is decided after a short audit, not by guesswork.

What we can do

We update PHP on a copy of your site, check plugin and module compatibility, move the live site to a safe version, set request limits, monitoring and backups, and leave you a status report. Details are on the PHP update and site protection against hacking pages. Write to us and we will first take a free look at what is visible about your site from outside.

From our own practice. We are already moving our Stable store engine to a fixed build: the cloud version and demo images are built on PHP 8.5.12. In its release the engine runs on Laravel 13 (which requires PHP 8.3 or later). We run new Laravel stores the same way: we take the fixed PHP instead of leaving the build as it was. If your store runs on old PHP or OpenCart, see moving to Stable Shop.

No approach gives a 100% guarantee. Updating and hardening greatly reduce risk but do not replace regular backups and monitoring.

Sources: Patchstack, watchTowr, supported PHP versions.