Skip to content
WordPress Maintenance

The October 2026 PHP Vulnerabilities (CVE-2026-109618/109619): What WordPress Site Owners Should Check

On October 21, 2026, two critical vulnerabilities were disclosed in PHP itself — the language WordPress runs on. This is not a plugin or theme problem; it sits underneath WordPress. Any site running on PHP is affected, whether or not it uses WordPress.

This article summarizes what happened, based on public advisories, and walks through what to check if you look after WordPress sites.

Note: This article reflects the situation as of October 28, 2026. Details may change, so check the advisories linked below (such as the CISA alert) for the latest information.

What happened

The key points:

  • Affected: PHP itself (CVE-2026-109618 and CVE-2026-109619)
  • Impact: an unauthenticated attacker may be able to run arbitrary code remotely
  • Severity: 9.2 (Critical) on CVSS v4.0
  • Fixed releases: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (released October 21, 2026)
  • PHP 8.1 and older: no official fix will be released
  • Exploitation: attempts to exploit the flaws have been observed, and the U.S. CISA has added them to its catalog of known exploited vulnerabilities

Note: A CVE (Common Vulnerabilities and Exposures) ID is a shared, worldwide identifier for a published vulnerability. CVSS rates severity on a scale of 0 to 10; scores of 9.0 and above are in the most severe “Critical” band.

A further vulnerability (CVE-2026-115560) was disclosed afterwards, along with a mitigation. See the CISA alert and your host’s notices for details.

Who updates PHP?

This is where it differs from a plugin update. PHP is part of the server, so you can’t update it from the WordPress dashboard. Who does it depends on your hosting:

  • Shared hosting: your host applies the fix. Your part is to check the host’s announcement and, if needed, switch PHP versions in the control panel.
  • VPS, dedicated servers and cloud instances: whoever installed PHP (you, or the team that built the server) updates it — usually through OS package updates or by rebuilding PHP.
  • Managed WordPress hosting: the host usually handles it, though some services let you choose the PHP version yourself.

Rather than assuming “the host will take care of it,” start by confirming which of these applies to each site.

What to check

1. Read your host’s announcement

On shared or managed hosting, look for your host’s notice first. Many hosts around the world have published their response to this issue. You want to know two things:

  • Whether the fixed PHP has been applied (and when)
  • Whether there’s anything you need to do, such as switching PHP versions

2. Check the PHP version each site actually uses

You can only tell whether a site is patched by looking at the full version, down to the patch number. On the 8.3 branch, for example, 8.3.36 or later is fixed, and 8.3.35 or earlier is not.

A couple of ways to check:

  • In the WordPress dashboard: go to Tools → Site Health → Info tab → Server, which shows the PHP version.
  • With WP-CLI: log in over SSH and run wp --info, which prints the PHP version.
wp --info

Note: wp --info shows the PHP version used on the command line. On some servers, the PHP that serves web pages and the PHP used on the command line are separate and can be different versions. The web-facing PHP is the one that matters for your site’s exposure, so also check Site Health and the PHP setting in your hosting control panel.

If you manage many sites, list each site’s PHP version side by side so you can see at a glance which ones are patched and which aren’t.

3. Plan an upgrade for sites on PHP 8.1 or older

PHP 8.1 and older will not receive this fix. As long as a site stays on an unsupported version, future vulnerabilities won’t be fixed either.

You can check each branch’s support dates on php.net’s supported versions page. As of October 2026, security support for PHP 8.2 ends on December 31, 2026.

When you switch PHP versions, order matters:

  1. Take a backup (both files and database)
  2. Update WordPress core, plugins and themes first (compatibility with newer PHP usually arrives in newer releases)
  3. Switch PHP, then check the site’s pages and key features (and keep a way to switch back if something breaks)

For what tends to break when you move to a newer PHP, see “What Breaks When You Upgrade PHP? Deprecated vs. Removed, Tested Across PHP 7.0–8.5.”

4. Look for unexpected changes

A site could have been attacked before the fix was applied. Following your host’s and the authorities’ guidance, check for things like:

  • Files or administrator accounts you don’t recognize
  • Pages or redirects that have changed without your doing
  • Any notice from your host about unauthorized access

If you find anything suspicious, don’t try to fix it on your own — contact your host first.

Keeping things up to date

This time it was PHP itself, but vulnerabilities in WordPress core, plugins and themes are published almost every month. Once a vulnerability is public, attackers keep going after sites that haven’t applied the fix, long after the patch is out. The basic defense is to apply fixes as soon as you reasonably can.

In practice, the main reason updates get postponed is the worry that an update will break the site. A few habits make that risk much smaller:

  • Always back up before updating, so you can roll back
  • Update one item at a time and check the site after each, so a problem is easy to trace
  • Record what you updated, when, and to which version, so you can review and explain it later

For backups, see “The 3-2-1 Backup Rule Explained: Why “3”?“; for post-update checks, see “Verifying a WordPress major upgrade — a 7-step post-upgrade checklist.”

WP Maintenance Manager, the tool behind this blog, also records each site’s PHP version so you can view and filter by it in the site list. (As explained above, PHP itself is updated on the server side.)

Summary

  • On October 21, 2026, critical vulnerabilities in PHP itself (CVE-2026-109618 and CVE-2026-109619) were disclosed. Fixed releases: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.
  • PHP 8.1 and older will not get an official fix.
  • PHP is part of the server. On shared hosting, check your host’s announcement; on servers you manage, update PHP yourself.
  • Check the full PHP version, down to the patch number. wp --info shows the command-line PHP, so check the web-facing PHP as well.
  • When moving off an old PHP version: back up, update WordPress, plugins and themes, then switch PHP.

A vulnerability this big is also a good moment to revisit how you maintain your sites. Take it one step at a time.

References: CISA alert / JPCERT/CC advisory (Japanese) / php.net supported versions