The October 2026 PHP flaws reach every website that runs on PHP

The PHP project published two advisories that day. Both are rated Critical, 9.2 out of 10 on the CVSS version 4 scale. One, CVE-2026-109618, comes from how PHP behaves when it runs out of memory. The other, CVE-2026-109619, comes from state that PHP keeps between requests. The project’s advisory confirms that, with Apache’s mod_php and default settings, an attacker with no login can run code on the server as the web server’s account. Security writers call the pair PHP2Shell.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On the first flaw, the project says updating is “the only complete mitigation”. On the second it says no complete mitigation through settings alone exists. Changing settings can reduce the exposure. It does not remove it.

On 26 October the US Cybersecurity and Infrastructure Security Agency added both flaws to its list of known exploited vulnerabilities. Its alert says they “affect all PHP installations serving web requests” and tells organisations to update immediately.

W3Techs, which surveys the web every day, finds PHP in use on 69.2 per cent of the websites whose server-side language it can identify (29 October 2026). Many of the best-known content management systems and shops are written for it. WordPress recommends PHP 8.3 or greater. Drupal says it is designed to work with PHP. Joomla 6 needs PHP 8.3.0 at the least. Craft CMS describes itself as “a PHP application”, and it is licensed under its own proprietary licence. The current release of Adobe Commerce lists PHP 8.5.

Whether a system is free or paid, built by a company or by volunteers, makes no difference to these flaws, because they sit in the language underneath. Sansec, a security firm that watches online shops, reports that researchers found an attacker without a login could run code on recent versions of Magento, WordPress, Drupal and Joomla. Its advice to shop owners is that the flaws cannot be fixed from inside the shop’s own code.

The flaws are in PHP. WordPress’s own code is not where they sit, so we do not treat this as a WordPress problem. WordPress is one of many systems standing on the same ground.

CISA listing the flaws as exploited means attacks have been seen. Sansec reports attack attempts hours before the fix was public.

The same Sansec report says mass exploitation is “less likely than we first expected”, because attacks need specific knowledge of the target and particular server settings. It also cites a researcher who found that public proof-of-concept code fails against a default PHP install and mostly needs a second flaw in the application, a local file inclusion bug. Palo Alto Networks counts more than 22.6 million exposed instances as potentially vulnerable. That is the firm’s own estimate from its telemetry, and “potentially vulnerable” is a wide net. The firm also withdrew an early report that tied a real intrusion to these flaws.

We found no published count of sites compromised and we will not guess one. Not every PHP site is under attack. Updating costs little against the risk of being the exception, and once a fix is public every attacker can study it.

The PHP project released fixes for 8.2 to 8.5 only. Sansec reports that for PHP 8.1 and older, php.net published source patches but no fixed release, and that some operating system vendors have backported the fix. CISA says systems that cannot be updated at once, or that run PHP 8.1 or earlier, should be taken offline until they are patched or updated.

W3Techs puts 26.5 per cent of PHP sites on PHP 7, 7.7 per cent on PHP 5 and 0.1 per cent on PHP 4. Added together, that is 34.3 per cent on PHP 7 or older. Its figures do not split PHP 8 into minor versions, so the share without an official fix is higher than that.

1. Which version of PHP does our website run on, and is it 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a later release, or a fix your hosting company has backported?
2. If it is older than that, what is the plan and the date?
3. Does anything else we run use PHP, such as a booking system, a separate shop, a forum or an old microsite?
4. How would you know the next time a flaw like this was announced, and how many days would you take to act?

The answers will tell you more than any reassurance. A host that can say its version number and the date it updated has the flaw under control.

The sites we build are static files served from a content network. No PHP runs on the public server, so these flaws have nothing to reach, and there is nothing on that side for us to patch when the next one is announced.

That does not remove every risk. The hosting account, the domain, the editor’s sign-in and any PHP system your business runs somewhere else still need attention, and we treat them as part of the job. If you are staying on WordPress, the four questions above and a short patch window are the answer.