What happened
On 21 October 2026 the PHP project published a security release that fixes two vulnerabilities rated critical. The same day, the WordPress.org news site published a short notice for site owners, asking them to update PHP as soon as possible. The key point of that notice is that the problem is not in WordPress. The flaws are in PHP, the programming language that runs on the web server, so every website and application that runs on an affected PHP version is exposed, whether it uses WordPress, another content management system or custom code.
The WordPress notice says that no WordPress update is required or planned for these issues. That is why this event feels different from a normal WordPress security release: updating WordPress core, plugins and themes does not fix it. The fix has to happen on the server, by moving to a patched PHP version, and on most websites the person or company that controls that is the hosting provider.
The notice itself does not list the technical details of the vulnerabilities or the exact patched version numbers. Those are published by the PHP project in its release announcement and security advisory, and you should read them or ask your host for the version you need. This guide explains what the notice means in practice and how to respond without guessing.
Why this matters even if you do not use WordPress
PHP is one of the most widely used server-side languages on the web. WordPress runs on it, and so do Drupal, Joomla, Magento, WooCommerce stores, Laravel and Symfony applications, forums, and a very large number of custom business systems. Surveys of the web put PHP behind roughly three quarters of the sites whose server-side language can be detected, and WordPress itself runs on roughly four in ten of all websites. The exact percentages change from month to month, but the scale is the point: a critical flaw in PHP is a flaw in a large part of the internet.
That scale also explains the urgency. When a critical vulnerability is announced, attackers start scanning for unpatched servers within hours, because the technical information is public and the number of possible targets is huge. Sites that are patched quickly are overlooked. Sites that wait can be found by automated tools long before anyone notices a problem.
Step 1: Find out which PHP version you are running
You cannot judge your risk without knowing your version. If you use WordPress, sign in to the dashboard and open Tools, then Site Health, then the Info tab, and expand the Server section. It shows the PHP version in use. Your hosting control panel, such as cPanel, Plesk or your host's own dashboard, normally shows the same information in a PHP version selector.
If you have command-line access, run php -v on the server, or use WP-CLI with the command wp --info. If you run several sites on one server, check each one, because different sites can use different PHP versions. If you manage client sites, make a list with the site, the host, the PHP version and the date you checked it, which becomes your record for the next advisory as well.
- WordPress dashboard: Tools, Site Health, Info, Server
- Hosting control panel: look for PHP Selector, MultiPHP Manager or the equivalent
- Command line: php -v, or wp --info if WP-CLI is installed
- Ask your host to confirm the exact version and whether it includes the security fix
Step 2: Ask your host what they have done
Many hosting companies react quickly to announcements like this. Some patch PHP on shared servers for all customers, and some add rules to a web application firewall that block known attack patterns. The WordPress notice mentions both. Do not assume this has happened for your account, though. Open a ticket or use live chat and ask three plain questions: is my PHP version patched, if not, when will it be, and can you move my site to a patched version now?
Firewall rules are a useful layer, but they are a mitigation, not a cure. A rule can block known attack requests, while the vulnerable code is still on the server. The recommended action stays the same: update PHP.
Step 3: Update PHP safely
Updating PHP is usually a setting in the hosting panel, but a version change can break a site if a plugin or theme is not compatible, so do it in a careful order. First take a full backup of the files and the database and store it away from the server. Second, if you have a staging copy of the site, switch it to the new PHP version and test the main pages, forms, checkout, logins and any custom features. Third, check the error logs for deprecation warnings and fatal errors.
When staging works, change the live site, then test again immediately and keep the backup ready. If something fails, the fastest fix is usually to update or replace the plugin or theme that is not compatible, not to go back to an unpatched PHP. If a critical plugin has not been updated for years and cannot run on a supported PHP version, treat that as a signal to replace it.
WordPress publishes guidance on updating PHP and a compatibility page that lists which WordPress versions work with which PHP versions. Use them when choosing the version to move to, and keep WordPress itself current so that it supports the newer PHP version.
- Back up files and database, and keep the backup off the server
- Test on staging with the new PHP version before touching the live site
- Check plugin and theme compatibility, and update or replace those that are not compatible
- Switch the live site, then test logins, forms, checkout and key pages straight away
- Watch the error logs for several days after the change
If you run a PHP version older than 8.2
The WordPress notice makes a point that many site owners overlook: versions of PHP older than 8.2 no longer receive security updates from the PHP project. That means a new critical flaw will not be fixed for them at all, however long you wait. For those sites, updating to a supported version is the only real remedy.
For a server that you manage yourself and that cannot be upgraded immediately, the notice points to guidance from national cyber security agencies, including the UK National Cyber Security Centre, which says that where a system cannot be fully mitigated right away, taking it offline until it can be is an option. That is a heavy step for a business website, but for a site that handles customer data or payments it may be the right one, and a simple maintenance page is better than a breached server.
If you are on an old version because a legacy plugin, theme or custom application depends on it, make a dated plan to move. Ask the developer what it would take to run on a current version, and decide whether to rebuild that part instead of carrying the risk for another year.
After patching: check for signs of compromise
Updating closes the door, but it does not tell you whether someone has already walked through it. If your site ran on an unpatched version while the vulnerabilities were public, review it for signs of intrusion. Look for administrator accounts you do not recognise, files that changed recently, especially PHP files in the uploads folder, unexpected redirects, spam pages in Google, and warnings from your host or from Google Search Console.
WP-CLI can check the integrity of WordPress core and of plugins from the official directory with the commands wp core verify-checksums and wp plugin verify-checksums --all. A malware scan and a look at the server access logs for unusual requests around the announcement date are also worth doing. If you find anything, follow a proper cleanup, change all passwords and keys, and review the site in Search Console. Our guide on what to do when a WordPress site is hacked sets out those steps in order.
How to avoid being exposed to the next one
Critical advisories will keep arriving, so build a routine instead of reacting each time. Use hosting that patches PHP promptly and lets you choose current versions. Keep a list of all sites and their PHP versions. Subscribe to the security announcements of PHP, WordPress and your host. Keep automatic backups and test restoring them. Remove plugins and themes you do not use, because less code means less to break when a version changes.
Architecture also matters. A website whose public pages are built ahead of time and served as static files, for example with Next.js or Astro, does not run PHP when visitors request a page, so a PHP flaw cannot be exploited through those pages. If a CMS such as WordPress is still used behind the scenes, it should sit on a patched, access-controlled server. This does not make a site immune to every risk, but it reduces the number of places where one unpatched component can expose the whole business.
Related services