PHP2Shell: Two PHP Core RCEs Need Patch and Restart Now

PHP shipped emergency fixes on 21 October 2026 for two critical flaws in the PHP interpreter itself that allow an attacker without an account to run code on a web server. The flaws are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0 and called PHP2Shell. If you serve any request with PHP, you are affected until you update to a fixed version and restart the worker.

The details here come from the PHP security advisory published 21 October 2026 around 14:00 UTC, Google Cloud and Unit 42 advisories on the same day, and BleepingComputer and Tenable coverage of the release. Patch details were pulled forward by a day after details leaked on 20 October.

What was fixed on 21 October?

Researchers at Calif, Wiz and OpenAI who used AI assisted discovery are credited by the PHP team. Calif notes the earliest affected code path it found dates to PHP 5.4.0. The release was planned for 22 October but was pulled forward after a leak.

Why does an unauthenticated PHP bug affect so many sites?

PHP still powers roughly 70 percent of websites, including WordPress, Drupal, Magento, Joomla and Laravel apps. The flaws are in the interpreter itself, not in a plugin. Any request that reaches PHP can trigger the path before application code runs, especially with mod_php where the request is processed inside Apache.

According to Cloudflare, the flaws affect all web servers running PHP 5.4 or later and may allow denial of service, RCE and data exposure. According to CISA on 21 October, patch immediately. In shared hosting where one pool serves dozens of vhosts, one worker flaw becomes every site. CVE-2026-109619 can also leak server memory, including passwords and tokens, without code execution, according to Tenable.

Which version should you install?

Fixed builds: 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 7.4 through 8.1 gets minimal source backports only. PHP 5.4 through 7.3 gets no fix. Linux distributions got the patches in advance, so check distribution errata.

I patched a lab pool running php-fpm 8.3.35 and 8.2.34 on Ubuntu this morning. The package update took seconds. The restart is what made the fix active.

Do you need to restart after updating?

Yes. Without a restart of php-fpm, Apache, or the FrankenPHP worker, the old interpreter stays resident. The PHP advisory, Qualys and Rapid7 all list restart as required. I audited a pipeline last quarter where the base image updated PHP but the running container was not rebuilt. The image was fixed, the container was not. Check the running worker, not php -v.

How was this found and why was the release early?

The PHP team planned disclosure for 14:00 UTC on 22 October, but details leaked on 20 October. WatchTowr then confirmed both flaws, and Huntress published a rapid response. The team moved the release to 21 October at 14:00 UTC and shipped around 09:30 ET. Cloudflare and other edges deployed WAF rules the same day, which buys time but does not replace the patch.

What should you do before and after the patch?

I ran the checklist against three WordPress hosts and one Magento 2.4.9 lab. First, inventory every host that serves PHP, including php-fpm, mod_php, php-cgi, FrankenPHP and LiteSpeed.

Second, patch and restart the PHP worker. Verify worker age after restart.

Third, rotate secrets that CVE-2026-109619 could have disclosed, specifically database passwords, tokens, API keys and certificates, even without code execution.

Fourth, review logs for anomalous OOM events. At Krova Cloud we treat a PHP worker that can run code as a host that can affect every vhost it serves, so we do not share a pool across trust boundaries as described in container vs microVM isolation.

What is the verdict and what remains uncertain?

According to Google Cloud, distributions got the patches in advance. According to CISA, patch immediately. According to BleepingComputer, about 884,000 end of life hosts will receive no fix at all.

The verdict is to patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart workers now. No workaround fully replaces the patch, and mod_php sites can be exploited before application code runs.

The limitations are threefold. First, there is no official binary fix for 8.1 and earlier. You must migrate or apply minimal source backports, which leaves 7.4 through 8.1 at higher risk. Second, proof of concept code has not been broadly published, but multiple researchers have confirmed unauthenticated RCE, so weaponization is expected quickly. Third, edge WAF rules help but do not fix the interpreter. An attacker who reaches the origin directly bypasses the edge.

FAQ

Does this affect WordPress?

Yes. WordPress runs on PHP. Every WordPress site on a vulnerable PHP version is exposed until the underlying PHP interpreter is patched and the worker restarted. The application version does not matter.

Do I need to patch if my app limits request size?

Yes. The flaws are in core request handling, not application validation. An unauthenticated request can trigger them before your app validates anything.

What about PHP 8.1 and 7.4?

The PHP project is not releasing binary fixes for 8.1 and earlier. It provides minimal source backports for 7.4, 8.0 and 8.1 only. You should plan to move to 8.2.35 or newer. Hosts that must stay on an older branch should treat the worker as exposed and isolate it.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud