PHP2Shell: check your PHP version, mitigate, then patch

PHP2Shell is the name given to two flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, made public on 21 October 2026 and rated 9.2 out of 10 (CVSS v4.0). Combined, they allow code to be executed on the server, remotely and without an account. They sit in PHP itself: a WordPress, Drupal, Symfony or custom-built site is exposed in the same way as long as the PHP version serving it is not patched. This post brings together, with their sources, the three steps to take in order: check the version actually served, set up an emergency mitigation if needed, then apply the fix or migrate.

What is known about the flaw

The security advisories published by the PHP team describe two mechanisms. The first (CVE-2026-109618) occurs when a request exhausts the memory allocated to PHP: the interruption leaves request data in an invalid state, which the end-of-request routine then reads. According to the advisory, several ways of triggering this memory shortage go through the parsing of multipart request bodies, the format used for file uploads. Sansec adds that this flaw can send fragments of server memory back to the client.

The second (CVE-2026-109619) comes from global PHP states that keep a pointer to the memory of a request that has already been freed: the next request handled by the same process can read this stale state, which opens the way to code execution.

The PHP advisory describes Apache with mod_php as the most exposed case: code execution was demonstrated there over HTTP, with the default configuration, before the application code even runs. PHP-FPM is also affected according to the source code analysis. Details leaked the day before the fix, and both SecurityWeek and Sansec expected mass exploitation: the time between publication and the first automated attacks is counted in hours, not weeks.

Affected and fixed versions

According to Sansec, every PHP version since 5.4 contains the vulnerable code. The official fix, released on 21 October 2026 at 14:00 UTC, covers only the branches that are still maintained:

The support dates come from the official php.net schedule. Two consequences: an application on PHP 8.1 or older has no fix and must migrate; an application on PHP 8.2 can be patched today, but its branch stops being maintained in two months.

Step 1: check the version actually served

Several PHP installations often live on the same server: the command-line one, one or more PHP-FPM, sometimes mod_php, and those built into containers. The php -v command only reports the first.

1. List the installed PHP versions. php -v gives the command-line version (useful for scheduled tasks). On Debian and Ubuntu, ls /etc/php/ shows each installed version.
2. Query each PHP-FPM. Each version has its own binary (php-fpm8.3 -v, for example) and its own pools. Then find, in the web server configuration, which pool or socket serves each site.
3. Check a request actually served. Only a page executed by the web server is conclusive. If the expose_php directive is on, the X-Powered-By header gives the version (curl -sI on the site). Otherwise, use a temporary phpinfo() with an unpredictable name and restricted access, deleted right after reading.
4. Do not forget containers. In a container, PHP is part of the image: updating the host changes nothing. Query each service, then rebuild the image on a fixed version.

On shared hosting without server access, only the served request tells you: also ask your host for the version.

Step 2: the emergency mitigation

According to Sansec, every known trigger goes through a multipart/form-data request, which PHP parses before the application runs; the PHP advisory also recommends blocking these requests upstream when the application does not need them. The mitigation therefore consists in rejecting them in the web server, before they reach PHP: a rewrite rule that returns a 403 error to POST requests of this type in Apache, or an equivalent condition in nginx.

Test the configuration before reloading the server (apachectl configtest or nginx -t), then check that a multipart upload is rejected and that a regular form still goes through. Keep the side effect in mind: the mitigation blocks all file uploads (CVs, documents, images), and some order forms are also sent as multipart. It is not a fix: remove it as soon as PHP is up to date.

On our own servers, we applied this mitigation on 21 October 2026.

Step 3: apply the fix

For PHP 8.2 to 8.5, the fix is a version update, provided it reaches the PHP that serves your sites.

• Get the fixed version from your distribution’s packages, the rebuilt official Docker image or your host. Check that your package source actually offers the new version: Sansec reported that a common third-party repository did not yet publish it on 21 October.
• Restart every PHP process. A PHP-FPM or Apache already running keeps the old binary in memory until it is restarted.
• Check again on a served request, site by site: this check confirms the fix, not the package manager.
• Remove the mitigation, then test file uploads again.

If the server stayed exposed, Sansec points out that the first flaw can return memory containing passwords, session tokens or API keys: list the secrets that went through this server and renew the most sensitive ones.

Versions with no fix: migrate

PHP 5.x, 7.x, 8.0 and 8.1 are end of life: the PHP project no longer publishes fixes for them, neither for PHP2Shell nor for future flaws. A fix backported by a distribution or a host may exist; it is not a version maintained by the PHP project. The lasting way out is a migration to PHP 8.3 or 8.4, and often of the framework that goes with it. The post on the end of PHP 8.2 security support details the schedule and a six-step migration plan.

For support: the PHP2Shell page sums up the flaw, the security hardening offer includes a fixed-price emergency intervention, and the migration offer covers versions with no fix.