Critical PHP RCE Flaws (CVE-2026-109618 and CVE-2026-109619): What They Mean for WordPress

On October 20, 2026, early details of two critical flaws in PHP itself leaked online. The PHP team confirmed the problem and scheduled an emergency security release for Wednesday, October 21, 2026, 14:00 UTC. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and both are remote code execution (RCE) bugs. WordPress runs on PHP, so this affects almost every WordPress site, WooCommerce shop and most online stores.

What we know for sure

• The PHP security team rated both flaws critical, CVSS v4.0 9.2. A score of 10.0 is also circulating, but it is not the official rating.
• Both flaws are in PHP core, not in WordPress or in plugins. Updating WordPress, your theme or your plugins will not fix them.
• The fix is a PHP update on the server. Your host or server admin does it, not the WordPress dashboard.
• watchTowr reproduced one of the flaws (CVE-2026-109618) in a lab. Huntress reported on October 20 that it had not seen attacks in the wild yet.
• The PHP team said it could release earlier if details become public or attacks begin.

What we do not know yet

• The exact affected and fixed versions. Sources agree that the supported branches PHP 8.2 to 8.5 will get a fix. The numbers being passed around (8.5.12, 8.4.27, 8.3.36, 8.2.35) come from a single source and are unconfirmed.
• How far back it goes. Sansec writes about servers running PHP 5.4 or later, other sources about the whole family from PHP 5. PHP 8.1 and older are past end of life, so an official fix for them is unlikely.
• The root cause and attack conditions. Unofficial reports mention use-after-free bugs in the session upload progress handler (session.upload_progress) and in the multipart/form-data parser. No vendor has confirmed this.
• Whether the attacker needs to log in. The reports describe a remote attack, but no official conditions have been published.

Why this matters for your WordPress site

WordPress, WooCommerce, Joomla, Drupal, Magento and most shop platforms are PHP applications. If the bug is in the language itself, an attack can happen before any application-level protection runs: a security plugin, .htaccess rules or filters in your shop code. That is why experts say to patch PHP first on every internet-facing server.

This is different from our earlier posts about WordPress, such as WordPress 7.1 (CVE-2026-87902) or WordPress 7.0.3 (CVE-2026-65640). There, one click on "Update" in the dashboard was enough. Here, WordPress has nothing to patch.

Check your PHP version

1. In WordPress, go to Tools → Site Health → Info → Server and note the PHP version.
2. Keep in mind that hosts sometimes patch PHP without changing the version number (a backport). Ask your host directly whether the fix for CVE-2026-109618 and CVE-2026-109619 is installed and how they confirm it.
3. If you run PHP 7.4, 8.0 or 8.1, you are on a version without upstream support. Plan a move to PHP 8.3 or newer. PHP 8.2 gets security support only until December 31, 2026.

What to do now, before the patch

• Contact your host and ask when the fix will go live. Good hosts are already announcing emergency maintenance windows.
• Take a backup of files and database, stored off the production server. After the PHP change, test login, forms, search and checkout.
• A partial workaround. Some authors suggest setting session.upload_progress.enabled = Off in php.ini or .user.ini. They say it closes only one of the two suspected paths, so it is not a fix.
• Limit multipart/form-data traffic in your firewall or reverse proxy on pages that do not accept uploads. Only do this if you can do it without breaking your forms.
• Unsupported versions (PHP 5, 7, 8.0, 8.1): move to a supported version. If that is not possible, restrict access with a VPN or an IP allowlist.
• Be careful with "exploits" you can download. Files going around under the name PHP2Shell may be malicious. Do not run them on your own computer or server.

Do not treat a security plugin as a replacement for the PHP patch. It cannot repair a bug inside the interpreter.

How to tell if someone already got in

Experts expect fast, mass attack attempts after the patch is published. In the first days after the release, watch for:

• new, unknown .php files in wp-content/uploads, wp-content and the site root,
• new administrator accounts and new cron jobs,
• changes in core, theme or plugin files that you did not make,
• PHP processes that start a shell or download tools,
• a sudden rise in outgoing traffic or server load.

If you see any of this, isolate the server, keep the web server and PHP logs, and only then clean the site. For more signs of infection, read How to Detect Malware on Your WordPress Site.

Summary

This is a flaw in PHP, so a site owner cannot fix it inside WordPress. Three things matter: check your PHP version, ask your host for the patch date, and leave PHP versions that have no support. When the patch is out, update PHP right away, because attackers usually start within hours. We will update this post when the official version numbers and flaw descriptions are published.

Sources

• Sansec: Critical PHP RCE (CVE-2026-109618 and CVE-2026-109619)
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Phoenix Security: PHP Core RCE
• Thrive: Critical PHP vulnerabilities, what WordPress owners need to know
• Wordify: PHP critical security release, October 2026