Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHP released fixes for two critical vulnerabilities on October 21, 2026. Updating WordPress or plugins does not fix them. Learn how to check whether your hosting environment is affected and what steps to take.

In brief: what happened

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. Under certain conditions, they allow an unauthenticated attacker to run code on the web server. These are flaws in PHP itself, not in WordPress core, themes, or plugins, so the fix has to come from a patched PHP build installed on the server.

Recommended action: Ask your hosting provider to confirm that the PHP build serving your site is patched against both vulnerabilities. If you manage the server yourself, install a patched PHP package and restart PHP.

The PHP project’s advisories name them RCE via OOM corruption (CVE-2026-109618) and RCE via stale global state (CVE-2026-109619). In both cases, a request that fails at the wrong moment can leave internal data in an invalid state that PHP later uses.

A successful attack runs code with the privileges of the account that PHP runs under. Depending on how the server is configured, this could let an attacker read wp-config.php and the database credentials it contains, access or change the database, or modify the site’s files and content. A compromised PHP worker does not automatically give the attacker root access to the server.

Exploitation status (as of October 21, 2026)

The PHP Foundation stated that its security team had not found a functional exploit among the proof-of-concept (PoC) code that appeared before the release, but that PoC development had accelerated. On October 21, Cloudflare, which refers to the vulnerabilities as “php2shell”, reported that it had observed attack traffic targeting its customers and that attackers were modifying their payloads to try to bypass its protections. Neither source reports a confirmed successful compromise. Attack traffic shows that attackers are actively trying, but it does not by itself confirm that any site was breached. We will update this section as the situation develops.

Who is potentially affected

Potentially any website served by an unpatched PHP build is affected, regardless of which versions of WordPress, themes, and plugins it runs. The PHP project’s advisory covers all PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

The PHP project considers the risk highest for mod_php, where it has demonstrated an exploit that an unauthenticated request can trigger before any application code runs. This does not mean that other configurations are safe. Every PHP installation that serves web requests needs the fix.

How to check your PHP version and patch status

In the WordPress dashboard, go to Tools → Site Health → Info and expand the Server section. It shows the PHP version and the PHP SAPI (server API) that serve your site. Most hosting control panels show the same information. If you use WP Cerber, WP Cerber → Tools → Diagnostic also lists the PHP version and Server API.

The following upstream releases from the PHP project contain the fixes:

PHP branch	Upstream fixed release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0	No upstream release. Check your vendor for a patched build, or upgrade.
7.4	No upstream release. Patched vendor builds exist, for example Ubuntu 20.04 LTS with Ubuntu Pro (7.4.3-4ubuntu2.29+esm5) and, on systems that already use the Remi repository, Remi 7.4.33-31 (RHEL 8, 9, 10 and compatible). Check your vendor, or upgrade.

Important: these are upstream versions, not a universal minimum-version test. Linux distributions and commercial long-term support (LTS) vendors can backport the fixes into builds that keep an earlier version number, including builds of the supported 8.2, 8.3, and 8.4 branches. For example, Ubuntu 24.04 LTS maintains its PHP 8.3 packages under an 8.3.6-based version string and ships both fixes in package version 8.3.6-0ubuntu0.24.04.13. Site Health alone cannot establish whether a vendor’s build contains both fixes. Check the vendor’s security advisory or package changelog, or ask your host. Do not switch to a third-party PHP package repository just because your version number is lower than the upstream fixed release.

PHP 7.4, 8.0 and 8.1. Patched builds of these branches that are based on the PHP project’s source backports address both vulnerabilities with a minimal mitigation for end-of-life versions, which is narrower than the complete fix shipped in 8.2 and later. With this mitigation, a PHP process that runs out of memory is terminated immediately, so a site that exceeds its memory limit may show a generic server error instead of the WordPress critical error screen. On such builds, Site Health may show the same version number before and after the update, so confirm the fix with your host or in the package changelog. Upgrading to a supported branch remains the recommendation.

PHP 8.2 support ends soon. The PHP project’s security support for PHP 8.2 ends on December 31, 2026. If you upgrade from PHP 7.4, 8.0, or 8.1, choose PHP 8.3 or later, back up the site first, and check that your theme and plugins are compatible. Alternatively, ask your host for a patched build of your current branch.

Why the fix must be applied on the server

The vulnerable code is part of the PHP runtime that executes WordPress, not part of WordPress itself.

Updating WordPress does not address these PHP vulnerabilities. Updating WordPress core, themes, or plugins does not change the PHP runtime.
Security plugins cannot fix the runtime. Some exploitation paths can run before WordPress loads, so no plugin gets a chance to inspect the request. Web application firewall (WAF) rules at the hosting or network level may reduce certain attack paths, but they are not a complete substitute for patching.
Settings changed from within the site are not a reliable fix. The PHP project’s advisory warns against relying on ini_set() or FPM .user.ini files to apply its configuration mitigations, and the same applies to PHP settings changed in wp-config.php or by a plugin. Even the server-level measures described in the advisory only reduce exposure to specific attack paths and do not make an installation safe.

A note for WP Cerber users. WP Cerber runs inside WordPress. It cannot patch PHP, and it cannot inspect a request that triggers one of these vulnerabilities before WordPress loads. For the same reason, WP Cerber’s logs may not record such an attempt, so a log without suspicious entries does not prove that the site was not targeted. WP Cerber still protects WordPress at the application level, but it is not a substitute for updating PHP.

What to do now

If you do not manage the server

This applies to shared and managed hosting, where your provider is responsible for maintaining the PHP runtime. Ask them to confirm that the PHP build serving your website contains fixes for both vulnerabilities. You can send this question as is:

Is the PHP build serving my website patched against CVE-2026-109618 and CVE-2026-109619? Have the relevant PHP workers been restarted to load the patched build?

If you manage a VPS or dedicated server

Update PHP. Install the upstream patched release, or a distribution or vendor package whose advisory or changelog confirms that it contains both fixes.
Restart PHP. Restart or reload PHP-FPM, Apache, or any other service that runs PHP for your sites. Running workers keep using the old binary until they are restarted.
Verify. Check in Site Health that the expected PHP build is now serving each site. Then confirm separately, in the vendor’s advisory or package changelog, that the installed package contains both fixes. Site Health shows the running version but cannot prove that a backport is included. The php -v command may report a different PHP installation than the one serving your website, so do not rely on it alone.

Whichever case applies to you, keep a recent backup that you know you can restore. If you suspect the site was compromised before PHP was patched, keep in mind that updating PHP does not remove malware or backdoors. In that case, contact your hosting provider first, because access gained through PHP may not be limited to WordPress files. For cleaning up the WordPress installation itself, see our guide What to do if your WordPress site has been hacked.

Frequently asked questions

Is my computer or browser at risk when I visit an affected website?

Not directly. The vulnerabilities are in PHP on the web server, not in visitors’ devices or browsers. A site compromised through them, however, could be altered to serve malicious content, so visitors can face indirect risks.

Do I need to reinstall WordPress?

No, not to address these vulnerabilities. They are fixed by updating PHP on the server, and reinstalling WordPress does not change PHP. A reinstall may still be part of cleaning up a site that has been compromised.

Can I fix this without help from my hosting provider?

That depends on whether you control the PHP runtime. On a VPS or dedicated server, you can install the patched packages yourself. On shared or managed hosting, the host controls PHP. Many control panels let you switch a site to a different PHP version, but whether that build is patched still depends on the host.