Published October 21, 2026. Based on the PHP project's advisory available on that date; details may change.

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution, and urged all users to update immediately. WordPress runs on PHP, so every WordPress site is in scope: check which PHP version your server runs, and get it updated to the fixed release for its branch today, either yourself or through your host.

What happened

The PHP project pre-announced the release on October 20, rating both vulnerabilities 9.2 under CVSS v4.0, and published the fixes on October 21. The advisory describes them like this:

  • CVE-2026-109618: out-of-memory handling can interrupt PHP while internal request data is only partly set up, and request cleanup may then treat that invalid data as valid.
  • CVE-2026-109619: internal state belonging to one request can survive after its memory is freed, and a later request handled by the same worker may use that stale state.

Both can lead to remote code execution without logging in. The PHP project says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where it has a working exploit that triggers before any application code runs. That last point matters for WordPress owners: no plugin, firewall rule inside WordPress, or WordPress setting can block an attack that happens before WordPress loads.

Which versions fix it

Update to the fixed release on your branch:

  • PHP 8.5: 8.5.12
  • PHP 8.4: 8.4.27
  • PHP 8.3: 8.3.36
  • PHP 8.2: 8.2.35 (the PHP project notes that 8.2 reaches end of life on December 31, 2026)

Linux distributions and long-term support vendors received the patches in advance, so their packages may carry a different version number with the fix included. If your server uses distribution packages, check your vendor's security notice rather than comparing version numbers alone.

PHP 8.1 and older no longer receive updates from the PHP project. Some vendors provide backported fixes. Otherwise, the fix is upgrading to a supported version, which also means checking that your theme and plugins work on it.

How to check your WordPress site's PHP version

The version that matters is the one serving web requests, which can differ from the command-line version on the same server.

  1. In the WordPress dashboard, open Tools → Site Health → Info → Server and read PHP version.
  2. On managed and shared hosting, the hosting control panel usually shows the PHP version per site.
  3. On your own server, php -v shows the command-line version only. Check the web version through Site Health, or check the installed PHP-FPM or Apache module package with your package manager.

Check every site, including staging copies. Agencies should collect the versions for all client sites in one list so nothing is missed.

What to do now

On shared or managed hosting: your host normally applies PHP updates. Check your version in Site Health. If it is older than the fixed release, contact your host's support and ask when the update will be applied to your server.

On your own server or VPS:

  1. Take a backup of the site's files and database.
  2. Install the updated PHP packages from your distribution or the PHP project.
  3. Restart PHP-FPM, Apache or LiteSpeed so the new version is actually serving requests. A package update without a restart leaves the old code running.
  4. Confirm the new version in Site Health, then test the homepage, login, forms and checkout.

If you cannot update right away, the PHP advisory lists configuration changes that reduce exposure to specific attack paths (such as disabling session.upload_progress.enabled and limiting post_max_size), but it states plainly that they do not make an installation safe. Treat them as a stopgap for server administrators, applied at the server level, and update as soon as you can.

After updating

Because this flaw allows code execution without a login, a site that ran an unpatched version could have been attacked before you updated. Updating PHP closes the door; it does not remove anything already placed on the server. Watch for signs such as unknown admin users, new PHP files in wp-content/uploads, or unexpected redirects. Our signs your WordPress site has been hacked checklist and the guide to finding a backdoor in WordPress cover the checks.

Keeping PHP current is part of routine maintenance, not just emergencies. Our WordPress maintenance plan checklist includes it.

When to get help

If you run your own server and are unsure how PHP is installed, or you find signs of compromise after updating, get help before making more changes. Our WordPress hardening service covers server-level configuration, and WordPress malware removal handles cleanup if the site was already attacked.

Sources