Most website security advice is about the application: keep WordPress, plugins and themes up to date. This one is different. The flaws are in PHP, the language runtime underneath, so every PHP application on an affected server is exposed, however well it is maintained. This post reflects what was published up to 23 October 2026.
What happened
On 20 October 2026 the PHP project gave notice of an upcoming critical security release, and on 21 October it published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities that PHP rates 9.2 out of 10 under CVSS v4.0:
- CVE-2026-109618, remote code execution via out-of-memory corruption. When a request runs out of memory, PHP can be interrupted while internal request data is only partly set up, and cleanup may then treat that invalid data as valid.
- CVE-2026-109619, remote code execution via stale global state. Internal state belonging to one request can survive after its memory is freed, and a later request handled by the same worker may use it.
PHP's advisory says the risk is highest for Apache's mod_php, but that every web setup is at risk: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. The US agency CISA describes the flaws as affecting all PHP installations serving web requests, and the UK's NCSC warns they may allow attackers to execute commands on web servers running PHP.
Is it being exploited?
When CISA published its alert on 21 October, it had not observed exploitation. Since then, several security companies have reported public proof-of-concept code and attack attempts aimed at the flaws. Treat it as urgent either way: these are unauthenticated, remote flaws in software that runs a large share of the web, and reports of attack traffic tend to grow quickly after a fix is published.
Which versions fix it
| PHP branch | Fixed in | Note |
|---|---|---|
| 8.5 | 8.5.12 | Supported |
| 8.4 | 8.4.27 | Supported |
| 8.3 | 8.3.36 | Supported |
| 8.2 | 8.2.35 | Security fixes end on 31 December 2026 |
| 8.1, 8.0, 7.4 and older | No official release | Out of support. PHP has published minimal source backports for 7.4, 8.0 and 8.1, and some vendors ship backported fixes |
If your PHP comes from a Linux distribution's packages, the fixed package may carry a different version number. Linux distributions received the patches in advance, so check your vendor's security notice rather than comparing version numbers alone.
What to do today
- Find every PHP installation. Websites and web applications, intranet tools, hosting control panels, and appliances or software that bundle PHP internally. The NCSC points to an inventory of potentially affected products published by NCSC-NL.
- Check the version on each. On a server,
php -vor the package manager shows it. Do not leave aphpinfo()page public to check: it gives attackers the same information. - Update, internet-facing servers first, then internal ones.
- Restart every PHP worker after updating: PHP-FPM pools, Apache or the web server, so that no worker keeps running old code.
- On shared or managed hosting, ask your provider whether their PHP builds include the fix, and switch your site to a fixed version in the control panel if they offer a choice.
- Ask vendors of any appliance or product that bundles PHP when their fix ships.
If you cannot update yet
PHP is plain that there are no complete mitigations and that updating is the only safe choice. Its advisory lists settings that reduce exposure, including disabling session upload progress in php.ini or the FPM pool configuration and then restarting every worker. A web application firewall may help as a stopgap. If you cannot update or mitigate quickly, CISA and the NCSC both suggest considering taking the system offline. Systems still on PHP 8.1 or older are the hardest case, because they receive no official fix.
On anything left exposed, look for signs of compromise: PHP worker processes starting shells or downloading tools, unexpected new files in web directories, and administrator accounts nobody recognises.
WordPress and other applications
Updating WordPress, Joomla, Drupal, Magento or their plugins does not fix PHP2Shell, because the flaws sit below them in PHP itself. The application can be fully up to date and still exposed. The fix is the PHP runtime on the server.
A follow-up advisory
On 23 October PHP published a further, informational advisory, CVE-2026-115560, which needs an unusual session configuration to matter. Its suggested setting, disabling session upload progress until the next regular release, is the same one listed for PHP2Shell.
The longer lesson
The businesses that fix this fastest are the ones that already know where PHP runs and what is exposed to the internet. If this week was a scramble, see what the internet can see and a patching routine that actually happens. Our VAPT services include checking web servers for exactly this kind of exposure.
Sources
- PHP project announcements and security advisory, 20 to 23 October 2026
- CISA alert, 21 October 2026
- UK NCSC: critical security issue affecting PHP, 21 October 2026