PHP2Shell: What WordPress Site Owners Need to Do Today

What PHP2Shell actually is

Both bugs sit in how PHP handles a request, before any WordPress code runs.

CVE-2026-109618 is memory corruption after PHP runs out of memory mid-request. PHP can be left with partly set-up memory that it then works on during shutdown. The PHP advisory names multipart parsing as one way to get there: a request with endless part headers, no usable Content-Length, or nested field names.

CVE-2026-109619 is stale state. Something a request owns survives after that request ends, and a later request on the same worker uses it. The confirmed path is session upload progress, a PHP feature that's on by default.

Multipart is the format browsers use to send forms and file uploads, and PHP parses it before your site's code gets the request. That's why a security plugin can't help here. By the time Wordfence, Solid Security or any other plugin loads, PHP has already parsed the body.

Key finding

PHP2Shell is fixed by updating PHP on the server and restarting it. Updating WordPress, plugins or themes does nothing for it.

Who's exposed

The PHP advisory lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, with mod_php the highest. That covers nearly every way WordPress is hosted. For FPM, the setup most managed hosts use, the advisory says it's susceptible, though nobody has shown a complete FPM exploit yet. Don't read that as safe. It means the public work so far targeted mod_php first.

Every PHP release before the four fixed versions is affected. PHP 8.1 and older get no official release, because the PHP project no longer supports them. The project did publish minimal source patches for 7.4, 8.0 and 8.1, but those help only people who compile PHP themselves or hosts that backport fixes for you.

We looked at our own scan data to see how many sites tell the world which PHP they run. Of 749 sites we've scanned since March, 83 announce their exact PHP version in the X-Powered-By response header. That header is a ready-made target list for anyone hunting unpatched servers today.

Eighteen of those 83 sites (22%) run PHP 8.1 or older, so there's no official update for them to install. Nine are still on PHP 7. The other 65 can be fixed with a normal update, and every one of them was scanned before today's release.

If your host manages PHP for you

This is most WordPress sites: managed WordPress hosting, shared hosting and cPanel plans where you pick a PHP version from a menu.

1. Check your host's status page or support news for a PHP2Shell or CVE-2026-109618 notice. Big hosts usually patch on their own schedule and say so. Our PHP2Shell hosting status tracker lists what GoDaddy, Pantheon, DreamHost, Cloudways, Kinsta, SiteGround and others have said, with links.
2. Find the PHP version your site really runs. In WordPress go to Tools > Site Health > Info > Server and read the PHP version line. It reports the PHP your web server uses, which can differ from the PHP your terminal runs.
3. Compare it with the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and newer. Anything lower on those branches isn't patched yet.
4. If you're on 8.1 or older, switch to 8.3 or 8.4 in your host's PHP selector. Test on staging first if you can, because old plugins sometimes break on newer PHP. Our guide to checking and updating your WordPress PHP version has the steps for each major host, and our PHP version timeline explains which versions still get fixes.
5. If the version still isn't patched by tomorrow, open a ticket and ask the host directly when it will be. Ask for a date, not "soon".

If you run your own server

VPS, dedicated servers and panels like Plesk, CyberPanel, RunCloud or GridPane on your own box are your responsibility.

1. Install the patched PHP from your package source: your distro's security repo, the ondrej/php PPA, Remi's repo, or your panel's PHP updater. Check the package changelog mentions CVE-2026-109618, because distros often backport the fix without changing the version number.
2. Restart PHP. A running PHP-FPM or Apache worker keeps the old code in memory until it restarts, so restart php-fpm (or php8.3-fpm and so on) and Apache if you use mod_php. Long-running workers such as FrankenPHP need it too.
3. Confirm the new version from the web side, through Site Health or a phpinfo page you delete straight after. Don't trust php -v alone, since the command-line PHP is a different install on many servers.
4. Turn off expose_php in php.ini so your server stops announcing its version in the X-Powered-By header.

If you can't patch today, the PHP advisory lists stopgaps. They narrow the risk but don't close it:

WordPress core doesn't use PHP sessions, so turning off upload progress rarely breaks a WordPress site. A plugin that starts its own sessions could still care, so check after the change. Restart every PHP worker after editing any of these, or the old values stay live. A firewall rule from Cloudflare or your host is another layer while you patch, not a replacement for patching.

If you look after client sites

Agencies have the hardest version of this, because the answer differs per host. Make a list of every client site with its host and PHP version from Site Health. Sort it into "host patches", "we patch" and "8.1 or older". The last group needs a PHP upgrade plan this week, and it's the one most likely to be running plugins that haven't been updated in years. Our agency security guide covers how to keep that inventory current.

If you think a site was already hit

Exploitation started the same day as the fix, so a site that ran unpatched PHP today could already be compromised. Look for new admin users, PHP files in wp-content/uploads, and plugins you didn't install. Our list of signs your WordPress site was hacked walks through the checks. Malware dropped through a server bug often comes back after a simple clean, the way the self-healing sc backdoor does, so follow the full malware removal guide rather than deleting one file.

Check your own site

Run a free surface scan at wpvanguard.com. It reports the PHP version your server announces and flags the header that gives it away, along with any plugins carrying known vulnerabilities. PHP2Shell won't be the only thing to patch this week, either. Our weekly patch list has the plugin side.

References

• PHP security team: upcoming critical PHP security release (October 20, 2026)
• php.net news archive: October 21, 2026 security release
• GitHub advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• watchTowr: PHP CVE-2026-109618 FAQ
• Help Net Security: PHP2Shell vulnerabilities patched
• Codeable: PHP security release, what WordPress site owners need to do