On 21 October 2026 the PHP project released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell. Both are rated 9.2 (critical) and allow an attacker to run code on a server remotely, with no login, by sending crafted requests to any PHP page. The researchers who found the flaws demonstrated working attacks against out-of-the-box WordPress, Drupal and Joomla installs. If your website runs on PHP, and nearly every WordPress and WooCommerce site does, this applies to you. This post covers how to check whether you are exposed, what to do, and how we can help.
What happened
Wiz Research discovered the flaws in August 2026 and reported them to the PHP security team, which released fixes in a coordinated disclosure on 21 October. The two bugs sit in PHP itself, not in any plugin or theme, so any application running on an affected PHP version can be attacked, even a site with every plugin up to date. Security agencies including CISA have told organisations to patch immediately, and Cloudflare has already reported attack traffic probing for these flaws. A public exploit is expected quickly because technical details circulated before the patches were released.
The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older are end of life and will not receive an official patch, so sites on those versions need to upgrade to a supported branch.
Is your site affected?
Select the PHP version your site runs and the checker below will tell you where you stand:
Interactive: check your PHP version
How to check your PHP version
- WordPress: go to Tools, then Site Health, then the Info tab, and open the Server section.
- cPanel hosting: look for Select PHP Version or MultiPHP Manager.
- Managed hosting (Kinsta, SiteGround, WP Engine and similar): the PHP version is shown in the hosting dashboard, and support can confirm it.
- Anything else: ask your developer or host, and get the answer in writing.
What to do now
- List every site you run, including staging copies, old microsites and internal tools. Attackers scan for the forgotten ones.
- Check the PHP version on each using the steps above.
- Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later. On managed hosting this is often one setting; on a VPS or dedicated server it is a package update and a service restart.
- On PHP 8.1 or older, plan the upgrade now. There is no official patch for end-of-life versions. Test on staging first, because older plugins and themes can break on newer PHP.
- Take a full backup, then update WordPress core, plugins and themes. The PHP patch fixes these two flaws; an outdated stack is still the usual way in.
- Confirm, do not assume. If your host manages PHP, get written confirmation that every environment is on a patched version.
If you cannot patch today
The PHP project is clear that updating is the only complete fix. Until you can update:
- Keep a web application firewall with current rules in front of the site. Cloudflare and other vendors have shipped rules for this attack traffic. This filters known patterns only.
- For technical teams, the PHP advisory lists interim settings that reduce exposure, including disabling session upload progress (
session.upload_progress.enabled=0) at the server level. These reduce the attack surface; they do not fix the bugs. - CISA advises taking PHP systems that cannot be patched offline, especially anything public that does not need to be, such as old staging sites and abandoned projects.
How the attack works
You do not need the internals to act, but it helps to understand why this one is serious. Both flaws abuse how PHP workers handle memory between requests. Step through it:
Interactive: the PHP2Shell chain, simplified
- The attacker sends crafted requests to any PHP page on the site. No login, no vulnerable plugin needed.
- The requests push a PHP worker out of memory in the middle of handling a request.
- The worker survives and is reused, but internal state still points at memory that was freed.
- A follow-up request reaches the same worker and turns that stale state into code execution with the web server user.
Signs to watch for
The researchers suggest watching for unusual multipart requests followed by memory limit errors, repeated 500 responses, unusually large or malformed PHPSESSID cookies, and PHP workers restarting for no clear reason. The standard compromise signs also apply: admin users you did not create, changed or unfamiliar files, unexpected redirects, and browser or Search Console security warnings. If you see any of these, treat it as an incident: isolate, investigate, restore from a clean backup, and rotate every credential.
On managed hosting? You still have homework
Good managed hosts moved quickly: several deployed server-level mitigations before the patches were public, and are rolling the patched PHP versions out now. That covers the platform layer. Two things remain yours: confirm in writing that every one of your environments, production, staging and any old sites, is on a patched version, and keep the WordPress stack on top of PHP updated. A patched PHP does not protect a site with a vulnerable plugin.
How we can help
We have been checking and patching client sites since the disclosure. If you are not sure where your site stands, we can help with:
- Checking the PHP version and patch status across all your sites, including staging and forgotten ones
- Coordinating the PHP update with your host and confirming it landed
- Upgrading sites stuck on PHP 8.1 or older, with staging tests so WooCommerce, plugins and themes keep working
- Checking a site for signs of compromise and cleaning up if something got in
EUX is a Sydney WooCommerce and WordPress development agency and one of only three WooCommerce Pro Partners in Australia. Get in touch and we will check your site today, or start with our ecommerce audit for a full review.
FAQ
Is WordPress itself vulnerable?
The flaws are in PHP, not in WordPress. But WordPress runs on PHP, and the researchers demonstrated a working attack against a standard WordPress install. Any WordPress or WooCommerce site on an unpatched PHP version is exposed, regardless of how up to date the site itself is.
My host says PHP is updated. Am I done?
Verify it yourself in Site Health, check it is 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, and check every environment, not just production. Then update WordPress core, plugins and themes, which stay your responsibility on any host.
We are on PHP 8.1 or older. What now?
There is no official patch for end-of-life versions, so the fix is an upgrade to PHP 8.2 or later. Some Linux distributions ship limited backports, but an upgrade to a supported branch is the real answer. Test on staging first: this is a routine project for us, including WooCommerce compatibility testing.
Does a firewall protect us?
A web application firewall with current rules filters known attack patterns and buys time. It is an interim measure, not a fix. The PHP project states that updating to a patched version is the only complete remediation.
Sources
- Wiz Research: PHP2Shell writeup (the researchers who found the flaws)
- CISA alert, 21 October 2026
- Rapid7 technical analysis and interim mitigations
- Official PHP changelog
- Help Net Security coverage
