PHP emergency patch PHP2Shell: check and patch your servers

On 21 October 2026 the PHP team released emergency updates for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, together “PHP2Shell”, 9.2 each on CVSS 4.0). They sit in the runtime, not in an application: even a “Hello World” page on a vulnerable PHP version can be attacked, without any account. The fix is in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Researchers at Wiz, Calif and OpenAI found them.

Why updating the application is not enough

Updating WordPress, Laravel or Nextcloud changes nothing about the PHP version underneath. That comes from the server package, the host or the container image. According to the PHP advisory every way of running PHP is affected (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). mod_php is the most dangerous: a single request can trigger the attack before any application code runs. In addition, memory of the PHP process can be read, and it may hold passwords, tokens and keys of other requests.

Step 1: find every PHP installation

A server rarely has just one PHP. Typical places:

The distribution package (php -v, php-fpm).
Panel-provided versions, for instance Plesk under /opt/plesk/php/*.
Containers: Nextcloud, WordPress and others ship their own PHP in the image (docker exec NAME php -v).
Extra handlers per website that sit on a different version than the rest.

php -v
ls /opt/plesk/php/ 2>/dev/null
for c in $(docker ps --format '{{.Names}}'); do echo -n "$c: "; docker exec $c php -v 2>/dev/null | head -1; echo; done

Compare each version with the table: below 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 is vulnerable. PHP 8.1 and older no longer get updates, there are only source backports for 7.4, 8.0 and 8.1; 8.2 ends on 31 December 2026.

Step 2: patch and restart

On Debian/Ubuntu the usual apt update && apt upgrade. Important: distributions often ship the fix under an “old” version number, so check the package changelog for the CVE number, not just the version string. Then restart PHP-FPM or Apache, including long-running PHP workers. Without a restart the old code keeps running.

Worked example: my server tonight

On my Plesk server I had three sources: the Ubuntu system package (8.3.6), Plesk PHP 8.5.11 and two Docker images with their own PHP. Result:

Plesk PHP 8.5 updated to 8.5.12 through the Plesk installer.
For the Ubuntu package there was no fix yet. Instead of waiting I installed Plesk PHP 8.3 (now 8.3.36) and moved the websites to that handler. Same minor version, so little compatibility risk. Then I tested each site individually.
The containers (Nextcloud AIO) still carry an older PHP. Only the new image helps there, once it is released.

A few tips

Inventory first: write down where PHP runs (system, panel, containers). Next emergency you save the search.
Avoid mod_php: switch to PHP-FPM where you can. It reduces the attack surface and allows separate pools.
Test after every switch: home page, login, forms, cron jobs. A 200 on the home page is not enough.
Workarounds are not a fix: limits such as a small post_max_size only reduce individual attack paths. The update stays mandatory.
Plan for end of support: anyone on 8.1 or older needs a migration plan, not just this patch. 8.2 ends in two months.
Watch your secrets: because memory could be read, rotate tokens and keys if you see suspicious traces.

Sources: The Hacker News and the PHP security advisory.