php2shell: PHP's two critical flaws and what to do today

On 21 October the PHP project released versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. They fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as php2shell, which let anyone run code on a server without logging in. If your site runs on PHP (WordPress, WooCommerce, Joomla, Drupal, Magento, or business software written in PHP), the thing to find out today is whether the PHP on your server is already patched. Updating WordPress and its plugins won't help here: the bug is in the language underneath the site.

What the two flaws do

The first, CVE-2026-109618, is triggered when PHP runs out of the memory allowed for a request. If that happens at one specific moment, PHP shuts the request down while reading memory that is in an invalid state, and a crafted file upload is enough to cause it. According to the project's advisory, code execution has been demonstrated on Apache with mod_php using the default settings, before a single line of the application runs.

CVE-2026-109619 relies on the fact that a PHP process handles one request after another. One request leaves behind a reference to memory it no longer owns, and the next request to reach the same process uses it. The way in is session upload progress tracking, which is on by default even if the site never starts a session. The advisory confirms code execution with both mod_php and PHP-FPM.

Who is most at risk

The PHP project considers every installation that serves web pages exposed: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. The risk is highest with mod_php. With PHP-FPM, the most common setup on modern hosting, the first flaw is harder to exploit: Red Hat explains that FPM workers exit before they reach the corrupted memory. The second flaw works there too, though, so if you're on FPM you still update today.

How serious it is right now

Sources disagree on real-world exploitation. Amazon logged an attempt on its honeypots on 17 October, four days before disclosure, and says php2shell is now "being broadly exploited in the wild", although it can't tell whether those attempts would have worked against real systems. Sansec, in an update on 22 October, thinks mass exploitation is less likely than expected, because the public exploits don't work against a PHP install with default settings. CISA had not seen exploitation as of 21 October, and as of 22 October neither CVE is in its Known Exploited Vulnerabilities catalog.

We'd treat it as urgent anyway. The people who found the flaws have working exploits, and on 20 October a video of one leaked by mistake, which pushed the release forward by a day (PHP Foundation). Taking over the server needs no credentials at all. We wouldn't wait to find out whether Amazon or Sansec is right.

The version number can mislead you

Many hosts don't install the project's new releases. They backport the fix into the version you already have, and the number stays the same. CloudLinux, which runs on a huge number of shared hosts, says it plainly: the package release changes, the PHP version doesn't, so you check the changelog. Plesk also patched 7.4.33, 8.0.30 and 8.1.34, which keep their numbers but include the fix if built on or after 21 October 2026. cPanel shipped it for all its PHP versions, 7.4 through 8.5, in the EasyApache 4 update of 21 October. Many Linux distributions do the same.

So a site reporting PHP 8.1.34 may be patched, and one reporting 8.3.36 may not be, if nobody restarted the processes after the update. To know for sure, look at the build date (php -v shows it) or the package changelog, or get your host to confirm in writing.

What to do today

1. 01Find out which PHP version the site uses and how it runs (mod_php, PHP-FPM, LiteSpeed). In the hosting control panel it's usually under PHP; on the server, php -v shows the version and build date.
2. 02If you're on shared hosting, write to your host using the message below.
3. 03If the server is yours, update the PHP packages, check that the changelog mentions CVE-2026-109618 and CVE-2026-109619, and restart every PHP process: Apache, PHP-FPM, LiteSpeed. As long as the old processes are running, the new package is just sitting on disk.
4. 04If you can't update today, apply the temporary measures described further down.
5. 05Go through the logs from 17 October onwards, even if you've already updated, as CSIRT Italia recommends. According to Sansec, every known attack path goes through file upload requests (multipart/form-data). If you find them hitting pages that have no forms, together with out-of-memory errors or PHP processes crashing, copy the logs and files before you touch anything.

The message for your host, to adapt:

Temporary measures, if you can't update

The PHP project is clear about what they are: they close some attack paths and leave the rest open. They go in the server or FPM pool configuration, not in a .user.ini file or in ini_set(), because they have to apply before PHP parses the request:

• memory_limit=-1, set so the application can't change it, for example with php_admin_value
• post_max_size = 8M, or 32M if the site accepts uploads, with upload_max_filesize set lower
• session.upload_progress.enabled=0, then restart every process
• on PHP 8.5, also fatal_error_backtraces=0

With no memory limit, a single heavy request can eat all the server's RAM, so you need a cap at container or system level. The researchers at watchTowr consider these changes ineffective at preventing exploitation. Cloudflare has had firewall rules active since 21 October for every customer using its firewall, free plan included, but a firewall only stops the attack patterns it knows about. We'd use these measures only to cover the hours until the update.

If the site runs on PHP 8.1 or older

On 12 October we wrote that PHP 8.2 stops getting security fixes on 1 January. Nine days later 8.2 got its fix; from 2027 it won't get any more.

For 8.1, 8.0 and 7.4 the PHP project has released no new version, only minimal source patches for people who build PHP themselves, and points to distributions and long-term support vendors. In practice, on these versions you're covered only if your host uses CloudLinux, Plesk, cPanel or an extended-support distribution and has installed their fix. For sites that can't be updated right away, CSIRT Italia recommends considering taking them offline until they're fixed, and CISA says to take them offline.

Send your host the same message. If the answer is no, or never comes, migrating to a supported version is this week's job.

If you don't know which PHP your site runs on, or your host isn't answering, write to us. We'll look at how PHP runs on your server, tell you whether you're exposed and, if you're on an unsupported version, how much work it takes to move the site to a patched one.