On 21 October 2026 the PHP team rushed out fixes for two security flaws that became known as PHP2Shell. This was not another routine update. These bugs let someone run their own code on a server with no account and no password, and PHP powers most of the websites in the world. It touched almost everyone, including a good number of the sites we look after.
What the flaw was
Two identifiers, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. The category is the worst there is: unauthenticated remote code execution. An attacker could either run commands on the server or read chunks of its memory, exactly where passwords, tokens, keys and certificates pass through.
The interesting part is where the bug lives. Not in a plugin, not in sloppy application code. It is inside the PHP engine itself, in how it cleans up when a request blows up halfway through, usually because it runs out of memory. Half-built internal state is left behind, and the next request to land on the same worker finds it and touches it. That is where the memory leak or corruption begins. The specific pieces involve upload progress, a session cookie that leaks memory even when the site never starts a session, and the shared OPcache.
The scale explains the panic. PHP runs around 70% of the web, and every way it is served is affected: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP. Researchers showed it working against fresh WordPress, Drupal and Joomla. Since the problem sits below the application, how clean your own code is will not save you.
The flaw was found by a research team (Wiz Research) with help from AI models, the first piece as early as August. Details leaked two days ahead of schedule, so the fix shipped on 21 October instead of the 22nd. By then the attacks had already started. Honeypots logged exploitation from day one, and Amazon's network had caught an attempt on 17 October, before the advisory was even public. The US CISA marked it as actively exploited on 26 October.
What the providers did
The fix was one clear thing: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker. No configuration change fully covered the problem.
In the cPanel world, CloudLinux shipped fixed ea-php and alt-php packages, and Imunify360 added rules that blocked some attack paths. Those rules did not cover both flaws, so the update stayed the only real answer. There was also a trap that confused many: the EasyApache builds were fixed with a backport on top of the old version number. An ea-php84 could still read 8.4.26 while it was already patched. The number did not tell the truth, the changelog and the CVE did.
LiteSpeed on cPanel uses the same packages, so the same update covered it with a service restart. Linux distributions received the patches before public release. And one detail that cost a few people: the automatic security updates on some platforms do not touch PHP. Laravel Forge made that explicit. Updating PHP is a separate move, it does not come free with the rest.
What we did
We put it above everything else that day. First an inventory: which site runs which PHP version, and on which host. Then, for each one, we confirmed the build actually carried the patch by checking the changelog and the CVE rather than the version number. Where needed, we restarted the workers (PHP-FPM, Apache or LiteSpeed), because otherwise the processes already running held the old binary and the fix simply did not apply. On sites where the provider was slow, we put temporary brakes in place, WAF rules and restricted access, until the proper update arrived. And we watched the logs for the signs that had been described: odd or oversized PHPSESSID cookies, memory-limit errors, repeated 500s, workers dropping and respawning for no reason.
What we take from it
The version number is not proof. With a backport, the version stays the same and looks old while it is safe. Check the changelog.
PHP and the application update separately. A WordPress or Laravel update does not touch PHP, and the other way around.
Nothing moves without a restart. Until the workers start again, the old binary keeps running.
Some problems sit below your code. Even the most careful site is exposed if the engine underneath has a hole.
The reaction window shrank. With AI both finding and weaponising the flaw, attacks begin almost at the same time as the advisory, sometimes before. Here there was an attempt before anything went public.
A WAF buys time, it does not finish the job. It is a shield to breathe behind until the update, not the update itself.
Old PHP has no safety net. The 7.x releases and the very old 8.x ones got no official fix. Being on 8.2 and above is the baseline, not the exception.
Incidents like this will happen again. What makes the difference is knowing at any moment what each site runs, and having someone to call when the next one hits. If you are not sure which PHP version your site is on, or whether it is up to date, we can check it together.
Sources: Wiz Research, watchTowr, Help Net Security, CISA, CloudLinux, Imunify360, Laravel Forge, CERT-EU.
