php2shell: The Critical PHP Flaws That Leaked Before the Patch

PHP has released the fix, and it came out earlier than planned. If you run PHP on any server, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart your services. There is no complete mitigation: PHP itself says updating is the only safe choice.

Updated October 21, 2026, 8:50 a.m. Colombia time.

For anyone who missed the story: on October 20, two critical remote code execution vulnerabilities in the PHP core leaked online, CVE-2026-109618 and CVE-2026-109619, which researchers started calling php2shell. PHP had planned to fix them on the 21st at 14:00 UTC, but it released the versions before that.

What to do now

Three things, in this order. First, update to one of the fixed versions, or to the package from your distribution or provider that already includes it. Second, restart PHP-FPM, Apache, FrankenPHP and any long-running process, because installing the package is not enough: whatever was already running keeps the old code. Third, check your logs from 15:00 UTC on October 20 (10:00 a.m. in Colombia), in case someone got in before the patch.

What it fixes

PHP's advisory describes two separate flaws.

CVE-2026-109618 comes from PHP running out of memory. The handling of that error can cut PHP off with the request data half initialized, and the cleanup afterwards treats that broken data as if it were fine.

CVE-2026-109619 is internal state that survives after its memory has been freed. The next request handled by the same worker can use that stale state before it gets reset.

Both allow code execution without authentication, and both are rated 9.2 on CVSS v4.0. With mod_php, PHP says it has a demonstrated exploit where an ordinary request triggers the attack before a single line of your application runs. That is why updating WordPress, Laravel or a plugin does nothing for you here: the problem is in the interpreter, not in your code.

It affects any PHP that serves web requests: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest with mod_php.

How to update

Ubuntu and Debian. PHP says distributions received the patches in advance, so your package may already be ready:

bash
sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm

Replace php8.3-fpm with your version, and restart apache2 too if you use mod_php. Watch out for the version number: a package can carry the fix without changing the PHP number. To confirm, look at the changelog:

bash
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | head -20

It has to mention CVE-2026-109618 and CVE-2026-109619. Then check what is actually running:

bash
php-fpm8.3 -v
systemctl status php8.3-fpm --no-pager | head -5

If you have more than one PHP branch installed (ls /etc/php shows them), update all of them.

Docker and Dokploy. The PHP version lives inside the image, so restarting the container changes nothing. Rebuild with the new base image and redeploy:

bash
docker build --pull --no-cache -t my-app:new .
docker run --rm my-app:new php -v

It has to print 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If it still prints the old version, the base image has not been updated yet and you will have to wait a bit.

Shared hosting. Ask your provider to confirm the fix is deployed in the runtime of your domains. "Scheduled" is not the same as "deployed".

Windows. PHP publishes the source code and the binaries on its downloads page.

PHP 8.1 or older. The project no longer updates them. Some distributions and extended support vendors offer their own fixes, so ask yours, or move to a supported version. If you build from source, the security team published minimal patches for PHP 7.4, 8.0 and 8.1 in its repository.

RHEL and the Remi repository. PHP warns that rpms.remirepo.net, which is run by volunteers, will not have updates today, and recommends using the distribution's packages or building from source.

If you really cannot update today

PHP published some measures that reduce exposure to specific attack paths, but it warns that they do not make an installation safe. Use them only as a stopgap.

For the memory flaw (CVE-2026-109618): set memory_limit=-1 in a way applications cannot change, for example with php_admin_value in the FPM pool, and check that nothing puts a limit back. This removes the failure an attacker can cause through PHP's memory limit, but an allocation failure further down can still reach the vulnerable path. Also set a low post_max_size: 8M if your application does not receive files, 32M if it does. And if you use containers, a container memory limit helps as an availability boundary, but do not use RLIMIT_AS or RLIMIT_DATA, because they can cause the very failure you are trying to avoid.

For the stale state flaw (CVE-2026-109619): set session.upload_progress.enabled=0 and restart all workers. It has to go in php.ini, in the FPM pool or in the server configuration, not through ini_set() or in .user.ini. That blocks the confirmed session paths, but not other variants. On PHP 8.5 also add fatal_error_backtraces=0, which closes the confirmed fatal-error backtrace path.

After updating

Check your logs from 15:00 UTC on October 20: PHP-FPM crashes, strange requests, and new or modified files in web directories. Installing the patch does not erase an intrusion that already happened.

The most likely sign of exploitation, according to Huntress and researcher Florian Roth, is suspicious child processes launched by PHP: a php-fpm, php-cgi, apache2 or httpd that suddenly runs a shell, python, perl, curl, wget, nc, or commands like whoami and id. If you have an EDR, set an alert for that pattern. If not, Huntress mentions process-watcher, a free tool by Roth for watching that on Linux.

If you find something, isolate the server, keep the logs, and look for webshells, cron jobs and new accounts. To limit the damage of a future intrusion, store less data on the server, give the PHP user and service accounts fewer permissions, and send your logs somewhere else (advice from GMO Flatt Security).

What was said before the patch, and how it turned out

A lot circulated on the morning of the 21st, and not all of it turned out to be true. The versions that were rumored (8.5.12, 8.4.27, 8.3.36 and 8.2.35) were the right ones. The idea that everything came from session upload progress was only partly true: PHP confirms it is one of the paths of the second flaw, but there are two flaws, not one, and turning that feature off is not enough. The 10.0 score that circulated came from leaked reports, and the official one is 9.2. And the reports of early attacks, such as the one attributed to Cloudflare's CTO, were never confirmed by PHP.

Quick questions

Is it true that 80% of the internet is compromised? Nothing supports that. PHP is used by about 71% of the sites whose server-side language is known (W3Techs, July 2026), which is where the number comes from. But being exposed is not the same as being compromised, and PHP has not confirmed mass attacks.

I installed the package. Am I protected? Not until you restart. PHP-FPM, Apache and long-running processes, such as queue workers or Octane, keep the old version until you restart them.

I use PHP 7 or 8.1. What do I do? The project will not update them. Ask your distribution or support vendor whether there is a fix of their own, or move to a supported branch (8.2 to 8.5). Meanwhile, take that server off the internet or put it behind a VPN or a WAF.

Should I shut down my PHP sites? What you need to do is update, and on most servers it takes minutes. For sites you do not need today, like test environments, shutting them down or restricting them by IP until you patch does make sense.

Sources

• PHP advisory: https://www.php.net/archive/2026.php#2026-10-21-5
• PHP downloads: https://www.php.net/downloads.php
• watchTowr: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
• Huntress: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
• Sansec: https://sansec.io/research/php2shell
• CERT-EU: https://cert.europa.eu/publications/security-advisories/2026-018/
• GMO Flatt Security: https://blog.flatt.tech/entry/php2shell
• W3Techs (PHP usage): https://w3techs.com/technologies/comparison/pl-php