This one isn’t a plugin bug or a theme issue. It sits one floor below WordPress, in PHP itself, and that changes who has to fix it.
On October 20, the PHP security team announced an emergency security release for two critical vulnerabilities, both rated CVSS 9.2. It is scheduled for Wednesday, October 21, 14:00 UTC (10:00 a.m. ET), or earlier if details leak or attacks start. The EU’s cyber security service CERT-EU advises organisations to prepare for immediate patching.
The short version: If your WordPress or WooCommerce site runs on PHP, and every one does, you need the PHP update on your server as soon as it ships. A WordPress update won’t fix this. A security plugin won’t either. Find out today who updates PHP on your server, and check your PHP version.
What happened
The PHP team had planned a quiet, coordinated release. Then the details leaked. A post on Hacker News announced two PHP remote code execution flaws before the embargo ended, and security firm watchTowr confirmed they were real. The PHP team responded by moving the release forward.
Here’s what is known so far:
Two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both are rated critical.
Type: Researchers describe them as remote code execution in PHP’s core. That would mean an attacker could make your server run commands of their choosing. PHP itself has not published technical details yet.
Affected versions: According to the leaked reports, possibly every PHP version from PHP 5 onwards. PHP will confirm affected and fixed versions with the release.
Exploitation: As of October 20, Huntress and watchTowr had not seen attacks in the wild. That usually changes quickly once a fix is published. Attackers compare the patched and unpatched code to find the bug. E-commerce security firm Sansec expects mass attacks within 15 minutes of the release.
Researchers are already calling it “PHP2Shell.”
Why this one is different
Most WordPress security news is about one plugin. You update that plugin and you’re done.
This time, the vulnerable code runs before WordPress even starts. That has three consequences:
Your WordPress dashboard can’t fix it. Updating core, plugins or themes changes nothing. The fix is a new PHP build on the server.
Security plugins can’t reliably block it. They run inside WordPress, and based on current reports the attack hits PHP before that. Sansec says the same about its own application firewall: don’t wait for a rule to protect you.
Every site on the server is affected. That includes the live site, the staging copy, the forgotten test install on an old subdomain, and the microsite from 2019.
Three typical setups, three different answers
Example 1: A shop on shared or managed hosting, running PHP 8.3.
Your host updates PHP, not you. Supported versions will be patched, so you’re in good shape. But “the host will handle it” is an assumption until you’ve confirmed it. Send a short message today: “Will you apply the October 21 PHP security release, and when?” Then check the version number afterwards.
Example 2: A WooCommerce store on its own VPS or cloud server.
Nobody updates PHP for you. Whoever manages the server has to install the new PHP packages from the operating system’s repository as soon as they’re available, restart PHP-FPM, and confirm that the web server actually runs the new version. The PHP version you see on the command line isn’t always the one that serves your site. If nobody on your side feels responsible for the server, you’ve found your real problem.
Example 3: An older site still running PHP 7.4 or 8.1.
This is the risky one. PHP only supports version 8.2 and newer. Older versions will most likely get no official fix. Some hosts and Linux distributions backport security fixes to older versions, so ask yours directly. If the answer is no, the site has to move to a supported PHP version. On an old site that usually takes more than a click, because plugins and the theme have to be tested first. Until that’s done, CERT-EU recommends considering taking internet-facing applications offline if they can’t be patched.
What to do today
Check your PHP version. In WordPress: Tools → Site Health → Info → Server. Do this for every site you own, including staging.
Find out who updates PHP. On shared or managed hosting, that’s your host. On a VPS, it’s whoever manages the server. Ask now, not after the release.
Plan for anything older than PHP 8.2. Ask your host about backports. If they don’t offer them, schedule the upgrade and test it on staging first.
Clean up forgotten installs. Old test sites and abandoned subdomains are easy targets because nobody watches them. Delete what you don’t need.
Make sure you have a recent offsite backup before anything changes on the server. “Offsite” means not on the same server as your website. That’s one of the basics a maintenance plan should cover.
What to do once the fix is out
Confirm the new version number. Check Site Health again and compare it with the patched versions in the update at the top of this post. Don’t just trust “we’ve updated.”
Check every site on the server, not only the main one.
Watch for warning signs over the next few days. These include new administrator accounts you didn’t create, unknown PHP files in
wp-content/uploads, unexplained file changes, or a sudden spike in server load.
What you don’t need to do
Don’t panic-install a security plugin. It runs on top of the problem, not underneath it.
Don’t take a patched site offline. If your PHP version is supported and patched quickly, you’re fine. Taking a site offline only makes sense for unpatchable sites on outdated PHP versions.
Don’t download “proof of concept” exploits to test your own site. Security researchers warn that some of the circulating files may themselves be malicious.
The bigger picture
October has been a busy month. We’ve had three WordPress security releases in nineteen days, a WooCommerce security release, and now PHP itself. None of this is a reason to give up on WordPress. It’s a reason to know, at any moment, which software versions your site runs and who is responsible for updating each layer.
If you’re not sure who handles PHP on your server, or you’re stuck on an old version, talk to us.
