If your website is running on WordPress or any other PHP application then there is an emergency to attend to. The PHP security team announced two important security patches on 21st October 2026. Both would give an attacker the ability to execute their own code on a Web server without having to sign on.
The patched releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. But the PHP team says there is no complete workaround to block the vulnerabilities, making installing a fixed version the only guaranteed solution.
Table of Contents
Why updating WordPress will not solve this
There is a common misconception which needs to be clarified. PHP is a programming language that processes the code on your server; it’s different from WordPress, your theme, and your plugins. Changing any of those will NOT change your PHP version. That’s your host’s responsibility.
If you host with the PHP version selector in cPanel, don’t think that selecting a PHP branch like PHP 8.3 is the same as getting the patched build. Make sure that the version you get has the emergency fix. To determine which version your site is currently using, you can go to your WordPress dashboard, under Tools, click Site Health, and then click on the Info tab, and expand the Server section.
Who is most exposed
According to the PHP project, all installations that run website requests are at risk. The most vulnerable are Apache servers with mod_php, in which PHP is installed inside Apache. If you have a successful attack on that configuration, your site’s own code hasn’t even started to run! Therefore, careful coding and a precise list of plugins would not have saved you.
Before the release, it was evident that it was a serious situation. According to International Cyber Digest, the Dutch parliament and cyber agency websites were down before the patch, as were the web services provided by the Finnish government and some university sites. As a precaution, Sansec separately said it shut down its sites and the Dutch House of Representatives and the country’s National Cyber Security Centre took theirs down.
The Finnish shutdowns were also said to be precautionary and not due to a breach. Organisations had been warned by both CERT-EU and the UK National Cyber Security Centre to think about either temporarily isolating or shutting down systems where they are not able to immediately protect. Prior to publishing of the fix, there were also reports of there being an attack tool spreading around.
What if you run an older version
PHP 8.1 and earlier are end-of-life and no longer get regular official updates. The PHP team did release a limited amount of fixes for their source code for PHP 7.4, PHP 8.0 and PHP 8.1 which are intended for team compiling PHP, but that is the extent of their publishing. Some long-term supporting vendors or hosting companies can also provide their patches.
Use any of these as temporary solutions. They don’t restore the continuous support, which is really only fixed by transitioning to one of the supported releases. In the interim, check with your host if they will implement a vendor-provided solution and make sure to have it written in a contract.
A Practical Checklist
- Check the version of PHP you have installed on your site using the Site Health steps above.
- Talk with your host and request that they install one of the fixed versions, or to check if the updates they provide are already containing the fixes.
- If you are running PHP 8.1 or below, backup your site, discuss it with your vendor until they can provide a version fix and then schedule an upgrade to a supported version.
- If it’s not possible to patch immediately, discuss it with your host or developer and consider placing the site offline until it can be patched.
- Ensure that you have a web application firewall in place, but not as the sole security measure. A service like Cloudflare may be able to stop some of the attacks, but it is not a substitute for the patch. Be sure that all traffic does go through it, as an attacker who can reach your server directly can bypass the firewall altogether.
- Post-patching, check for signs of compromise. Look for any web shells (malicious scripts that allow attackers to have continued access), admin accounts you don’t know of, or PHP files that have been modified for no apparent reason.
The final step is in fact quite significant. A patch will simply close the door, but not remove anyone who has walked through it.
