PHP2Shell: Check Your WordPress PHP Version Now, and What to Do If You Cannot Patch

On 21 October 2026 the PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws that can allow unauthenticated remote code execution. Nothing in WordPress, WooCommerce or any plugin can fix them, because the bug is in the interpreter that runs all of them. The only complete fix is a patched PHP build, and the PHP release notes say so plainly: there are no complete mitigations.

This guide is the owner’s checklist, in the order we would work through it on a real site. Find the PHP version that actually serves your pages, move to a patched build, decide what to do if your branch has no upstream fix, then look for signs that something got in before you patched. Every version number, CVE id and date below comes from the primary pages we list at the end. Where we could not read a primary page, we say so.

The short version: your next hour

1. Open Tools > Site Health > Info > Server in wp-admin and read the PHP version. Do the same for every other site on the same server, including staging copies.
2. If you are on 8.2, 8.3, 8.4 or 8.5, check that the patch level is at or above 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then ask your host or update the package yourself. If the number is lower, check the package changelog before you panic, because some builds carry the fix under an older version string (details in step 1).
3. If you are on 8.1 or older, the PHP project issued no fix. Ask your host or OS vendor whether they backported it, or move to a supported branch.
4. After the update, restart PHP workers, confirm the new version from the web, not just the command line, and run the compromise checks near the end of this post.
5. Treat anything the PHP workers could read, such as database passwords and API keys in wp-config.php, as something to rotate if you cannot rule out an earlier break-in.

What was actually announced

The PHP security team pre-announced the release on 20 October: two critical vulnerabilities, both rated CVSS v4.0 9.2, release scheduled for Wednesday 21 October at 14:00 UTC. The 21 October advisory on php.net gives the two identifiers and a one-line description each.

That second description matters for how you think about risk. A PHP worker handles many requests in its life. If state from one request can be reused by the next, then what an attacker sends and what a visitor sends can meet inside the same process. This is why the worker-memory reads reported by the researchers (more on that below) include secrets.

The patched releases are the only fixes the project published:

The end dates come from php.net’s supported versions page, which lists only branches still supported. That page does not list 8.1, and the 21 October advisory says 8.1 and older no longer receive updates from the PHP project. PHP 8.2 gets a patch now but stops receiving security fixes at the end of this year, so patching 8.2 buys you about ten weeks of breathing room, not a destination.

Who found it, and how bad is it

The researchers at Wiz, who reported the bugs, name the issue set PHP2Shell. Their write-up says every PHP version released in the last decade is affected by at least one of the vulnerabilities, with 5.4 the oldest version it names. They group four underlying bugs under the two CVE ids (an upload-progress unserializer use-after-free, a remote process-memory disclosure, a fatal-error backtrace use-after-free and an OPcache type confusion) and report pre-authentication code execution against stock WordPress, Drupal and Joomla setups, plus reads of worker memory that can hold passwords, tokens and API keys.

Wiz’s own timeline: first bug found 19 August, unauthenticated code execution against WordPress confirmed 21 August, reported to the PHP security team 24 August, acknowledged 21 September, public with patches on 21 October. The page does not say whether anyone is exploiting this in the wild. Patchstack, in its alert, says it received reports of multiple active incidents from hosting partners on the morning of the 21st (07:34 UTC), that Cloudflare’s CTO said he was seeing early attacks, and that its own telemetry at 13:57 UTC showed only probing with no hard evidence of breaches yet. Read those as three separate claims from three different vantage points. None of them is a count of compromised sites, and we have not seen one from any primary source.

Patchstack lists the affected server models as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and says the PHP project considers the risk highest for mod_php, where a request can trigger the attack before any application code runs. That last detail is why a WordPress security plugin is not a defence here. A plugin is PHP code that loads after the interpreter has already taken the request. We could not read Wordfence’s own page on this issue (our fetch of it failed), so we make no claim about what its firewall rules do or do not cover.

WooCommerce’s developer blog, also on 21 October, states that no WooCommerce or WordPress update is required or planned for these issues, that WordPress.com, WordPress VIP, Pressable and WP Cloud sites are already protected, and that other hosts may already be updating PHP and adding WAF rules, but you should still check.

Step 1: find the PHP version that actually serves your site

The number you want is the version running behind the web server for your domain. That is not always the number a command line shows, and on a shared server it is rarely the number you assumed when you signed up.

From wp-admin

Go to Tools, then Site Health, then the Info tab, and open the Server section. WooCommerce’s guidance points to the same screen. You get the PHP version, the server software and the PHP SAPI (the way PHP is attached to the web server). Write down all three. The SAPI tells you whether you are running PHP-FPM, Apache’s module, CGI or LiteSpeed, which tells you which service to restart later.

From the command line, with one trap

WP-CLI will happily tell you a PHP version, but it is the version of the PHP binary on the shell’s path, which on many servers differs from the version the web server uses.

wp cli info | grep -i "php binary\|php version"
php -v

On a cPanel or Plesk server with several PHP versions installed, or a VPS with more than one FPM pool, the CLI can say 8.3 while the site runs 7.4. Treat the CLI result as the version of the tool, and the Site Health result as the version of the site.

If you have shell access to the server and want a quick pass/fail from the binary you point it at, this small script compares the running version to the fixed floor for its branch. To test the web side, run it as a temporary file under your own control, or point the same binary path your FPM pool uses at it.

<?php
// Fixed floors per supported branch, from the php.net advisory of 21 Oct 2026.
$floor = array(
	'8.5' => '8.5.12',
	'8.4' => '8.4.27',
	'8.3' => '8.3.36',
	'8.2' => '8.2.35',
);
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
if ( isset( $floor[ $branch ] ) ) {
	$ok = version_compare( PHP_VERSION, $floor[ $branch ], '>=' );
	echo PHP_VERSION . ' (' . PHP_SAPI . '): ' . ( $ok ? 'patched upstream' : 'VULNERABLE, need ' . $floor[ $branch ] ) . "\n";
} else {
	echo PHP_VERSION . ' (' . PHP_SAPI . '): no upstream fix on this branch, ask your vendor about a backport' . "\n";
}

We ran this on a laptop with Homebrew PHP 8.5.5 and it reported VULNERABLE, need 8.5.12, which is the correct answer for that build. Delete any file like this from a public web root as soon as you have the answer, and never leave a script that prints version details reachable by visitors.

When the version number lies in both directions

One limit of any version check: distribution and hosting packages often patch a fix into a build without changing the upstream version string. Patchstack notes, for example, that Ubuntu 22.04’s PHP 8.1 package is patched as 8.1.2-1ubuntu2.28, while still calling itself 8.1. A script like the one above would call that build unpatched upstream, because for 8.1 there is no upstream floor to compare against.

The same trap shows up on supported branches. Our sister site WPVanguard keeps a hosting status page, PHP2Shell Hosting Status: Is Your Host Patched Yet?, last checked at 11:30 UTC on 22 October. It reports that CloudLinux EasyApache builds dated 21 October still report PHP 8.3.35 and 8.4.26, below the fixed releases, yet their changelogs list both CVEs. It names the builds to look for as ones ending 8.3.35-2.cloudlinux.2 or 8.4.26-2.cloudlinux.1, and says that if the changelog names CVE-2026-109618 or CVE-2026-109619, you are patched whatever the version string says. So a version below the floor is a reason to read the package changelog, not proof of exposure, and a version at or above the floor is the simple good case.

# Debian and Ubuntu: look for the CVE ids in the package changelog
apt changelog php8.1-fpm 2>/dev/null | grep -i "CVE-2026-10961" | head
# or ask the package manager for the installed version string
dpkg -l | grep -E "php[0-9.]+-(fpm|cli|common)"
# RPM based systems (AlmaLinux, CloudLinux, RHEL): changelog of the installed package
rpm -q --changelog ea-php83-php-fpm 2>/dev/null | grep -i "CVE-2026-10961" | head

If the changelog mentions CVE-2026-109618 and CVE-2026-109619, your vendor shipped the fix. If it does not and the package version has not moved, assume it has not been fixed. Package names differ by distribution and panel; adjust for yours. On shared hosting where you cannot run any of this, the host-status page above and a support ticket are the route.

The sites you forgot

Patchstack’s advice is to inventory every PHP install, including containers, staging sites, and bundled appliances or third-party software. For a WordPress owner that translates to a short list: the live site, the staging copy, the old site you never took down, the subdomain with a forgotten test install, any Docker image used in CI, and any control panel that is itself written in PHP. The attacker does not care which of them is important to you.

Step 2: choose a version to move to

If you are updating inside your current branch (for example 8.3.30 to 8.3.36), you take on very little risk, because patch releases contain security and bug fixes rather than new language behaviour. That is the fastest route and the one to take first on any site you have not tested on a newer branch.

If you are choosing a branch, two official statements frame the choice. WooCommerce recommends PHP 8.3 or newer. Patchstack says PHP 8.2 gets security fixes only until 31 December 2026 and suggests aiming for 8.4 or 8.5. We would read that as: patch your current 8.2 or 8.3 today, and schedule the branch move after you have tested your plugins on it. Our post on the end-of-year upgrade calendar already has a week-by-week staging plan for the 8.2 deadline, and See What a PHP Upgrade Will Break Before Your Host Does It for You covers the staging test itself.

Step 3: apply the update for your hosting type

Managed WordPress hosting

Automattic’s own platforms are listed as already protected. For everyone else, log in to the host’s dashboard, find the PHP version setting for the site, and look at the exact patch level if it shows one. Many hosts show only 8.3, not 8.3.36. For what individual hosts have said, use the WPVanguard hosting status page rather than a table here, since it tracks hosts with sources and is updated as they change. If the dashboard does not show the patch level, open a support ticket and ask a direct question: which exact PHP build is running on my plan, and was the 21 October security release applied to the PHP-FPM pool serving my site. Keep the answer. A vague reply (“we monitor all security issues”) is not an answer.

cPanel and CloudLinux

Patchstack notes that CloudLinux publishes ea-php packages covering ea-php52 through ea-php85. On a server where you hold root, update the EasyApache PHP packages with your normal process, then rebuild or restart the PHP handler, and read the changelog as described in step 1 rather than trusting the version string. On shared accounts you cannot do this yourself, so the ticket in the previous section is the route.

A VPS with packages from the distribution or the Sury repository

Patchstack lists Ondrej Sury’s packages (packages.sury.org and ppa:ondrej/php) as covering PHP 5.6 through 8.1 on Debian and Ubuntu. For a supported branch, update the packages, then restart the service your SAPI uses. These commands assume Debian or Ubuntu with PHP 8.3 from a repository that has already published the patched build, so check the version afterwards rather than trusting the command.

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
php8.3 -v
sudo systemctl restart php8.3-fpm
# Apache with mod_php instead of FPM:
sudo systemctl restart apache2

The restart is part of the fix. Patchstack’s guidance includes restarting all workers, and a long-lived FPM process keeps running the old code in memory until it is restarted. After the restart, confirm the version again from Site Health, because that is the version your visitors reach.

Docker and container images

Patchstack states that the official php image has no fix for 8.1 or older. For 8.2 and newer, pull the current image for your tag, rebuild your own image on top of it, and redeploy. Check the version from inside the running container, not from the tag you wrote in the file.

docker pull php:8.3-fpm
docker run --rm php:8.3-fpm php -v
# then rebuild and redeploy your own image, and check inside the running container:
docker exec your-wp-container php -v

If the pulled image still reports a version below the floor for your branch, the maintainers’ rebuild may not have reached your registry mirror yet. We did not verify image rebuild timing, so check the number, not the assumption.

Step 4: if your branch has no upstream fix

This is the hard case: a site on PHP 8.1, 8.0, 7.4 or older, often because an old plugin or a licence tied to an old version blocks the upgrade. php.net says some distributions and LTS vendors provide backported fixes, so contact your vendor or upgrade. Patchstack’s alert gives the detailed picture, as of 22 October, and it says to check your vendor for updates because the list will keep moving.

Patchstack also points to source-only backport branches in the php-src repository: PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619. It labels them a last resort, a minimal mitigation only. Building PHP from a branch yourself is a fair option for someone who already compiles PHP and has a way to rebuild every extension they use. It is not a plan for someone who has never done it, and we would not recommend building from source under time pressure on a production site. Run it on a copy first, run your full test path, and write down how you will rebuild next month when there is another release.

A decision path

1. Does your vendor ship a fix for your branch? Use the table above or ask. If yes, install it, restart workers and verify with the package changelog. Done.
2. Can you move to 8.3 or newer this week? If the site is small and the plugin list is short, test on a copy and do it. Section below covers what breaks.
3. Neither? Then you are choosing a stopgap while you plan the real fix. Combine the partial measures below, and decide honestly whether the site should stay online.

Partial measures Patchstack lists, and what they are worth

Patchstack calls the following interim mitigations partial and not safe. Treat them as friction for an attacker, not as protection. We list them as reported and have not tested their effect against the exploit.

• Set memory_limit=-1 through php_admin_value, and avoid RLIMIT_AS and RLIMIT_DATA. This relates to the out-of-memory path in CVE-2026-109618. Unlimited memory has its own costs, since a runaway request can now exhaust the server, so this only makes sense for a short window.
• Set post_max_size to 8M if the site takes no uploads or 32M if it does, with upload_max_filesize below it.
• Set session.upload_progress.enabled=0 in php.ini or the pool config, then restart all workers. Wiz lists an upload-progress unserializer bug among the four it describes. You can see your current values with php -i.
• On PHP 8.5 only, set fatal_error_backtraces=0 and restart workers.

php -i | grep -E "session.upload_progress.enabled|post_max_size|upload_max_filesize|memory_limit|fatal_error_backtraces"

Note that php -i on the command line reads the CLI configuration, which may differ from the FPM pool’s. Check the pool file or use a temporary protected diagnostics page to read the web value, and remove it afterwards.

A WAF is a stopgap, and where it fails

Patchstack reports that Cloudflare deployed initial WAF rules for known exploit vectors to all customers, including the free plan, and describes them as a stopgap only. It adds that the rules help only if your origin accepts traffic exclusively from Cloudflare. If an attacker can reach your server’s IP directly, the request never passes the filter. Our post on why a host firewall is not the patch shows how to test that for your own setup, and ten checks for a host’s security claims covers the host side. To lock the origin down, allow only Cloudflare’s published IP ranges at the server firewall and keep it that way.

Patchstack also warns against unofficial “fix” plugins and copy-pasted snippets. Given what the flaw is, a PHP-level snippet cannot repair interpreter state. If you see a plugin that claims to patch PHP2Shell, treat it as a likely supply-chain risk, not a remedy.

Going offline for a while

WooCommerce’s post quotes the UK National Cyber Security Centre: where immediate remediation is not feasible, organisations should consider taking the system offline. Patchstack gives the same advice for high-risk sites that cannot be patched: take it offline or into maintenance mode. That is a legitimate choice for a site that holds customer data and runs on a branch with no fix.

If you do it, serve the maintenance page from the web server or CDN, not from PHP, because PHP is the thing you are trying to keep out of the path, and send an HTTP 503 status so search engines treat the outage as temporary. We cover the nginx side, including the trap that breaks maintenance mode, in When PHP Goes Down, Keep Serving Pages. We have not verified Google’s current guidance on how long a 503 can last before pages drop out of the index, so we will not quote a number. Keep the outage short and patch quickly.

Stuck on PHP 7.4 or 8.0: what breaks if you jump

The reason most sites are still on old PHP is not neglect. It is a plugin nobody updates, a theme that was custom built, or a licence key tied to a version. A move from 7.4 straight to 8.3 changes a lot. Rather than guess, scan the code that will run.

PHPCompatibilityWP is a PHP_CodeSniffer ruleset that flags code that will fail on a target PHP version. Install it with Composer and scan your plugin and theme directories against the target:

composer global require --dev phpcompatibility/phpcompatibility-wp
phpcs --config-set installed_paths "$(composer global config home)/vendor/phpcompatibility/php-compatibility,$(composer global config home)/vendor/phpcompatibility/phpcompatibility-paragonie,$(composer global config home)/vendor/phpcompatibility/phpcompatibility-wp"
phpcs -p --standard=PHPCompatibilityWP --runtime-set testVersion 8.3- --extensions=php wp-content/plugins wp-content/themes wp-content/mu-plugins

Read the output by severity. Errors are code that will fatal on the target version. Warnings are deprecations that will log notices today and may become errors later. Plugins that are on wordpress.org will usually already have a fixed release, so an update in staging resolves most of them. The remaining list, the plugins that are abandoned or custom, is the real size of your problem.

Then test on a copy of the site with WP_DEBUG and WP_DEBUG_LOG on, exercise the money paths (checkout, forms, logins, imports) and read the log, as described in our staging test walkthrough. If one abandoned plugin blocks the move, there are three honest options: replace it, fork and fix it, or isolate it. Leaving the whole site on an unpatched interpreter so that one plugin keeps working is no longer a safe trade, as this release makes clear.

“It works, do not touch it” was a defensible habit for a site with low exposure. With a critical, unauthenticated flaw in the interpreter and no patch for the branch, it becomes a standing liability, and the cost of waiting rises with every day the details are public.

Step 5: check whether anything got in

Two timelines matter. Patchstack saw probing and hosting-partner incident reports on the day of release, and Wiz says it confirmed code execution against WordPress two months before the patch shipped. We cannot know how many people held the details before 21 October, so a site that ran an unpatched PHP for a while should be checked even if nothing looks wrong.

Indicators from the researchers

Wiz suggests looking for these signs: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker churn. These are hunting leads, not proof either way, because a busy site produces some of them for harmless reasons. The commands below are our adaptation of those leads to the common log formats, and are heuristics rather than a detection rule.

# Memory-limit errors in the PHP error log (path varies by host)
grep -i "allowed memory size" /var/log/php*/error.log /var/log/php-fpm/*.log 2>/dev/null | tail -50

# Bursts of 500s in an nginx access log, grouped by minute
awk '$9 == 500 {print substr($4,2,17)}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Unusually long Cookie headers need a log format that records them;
# if yours does not, look at request sizes for POSTs instead
awk '$6 == "\"POST" {print $10, $7}' /var/log/nginx/access.log | sort -rn | head -20

Adjust the paths and field positions to your log format. These work on the default combined format in nginx. If your host gives you no access to logs, ask for them for 20 to 23 October, since that is the period of interest.

WordPress-side checks

Look for what an attacker with code execution leaves behind: new administrators, new or modified plugins, new scheduled tasks, files in places that should not hold PHP. The WP-CLI commands below are real, standard ones.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp core verify-checksums
wp plugin verify-checksums --all
wp plugin list --fields=name,status,version,update
wp cron event list --fields=hook,next_run_relative
ls -la wp-content/mu-plugins
find wp-content/uploads -name "*.php" -print
find . -name "*.php" -mtime -7 -not -path "./wp-content/cache/*" -print

What to read in the output: an administrator you did not create; a plugin that fails checksum verification and is not a premium plugin (those are not in the wordpress.org checksum set, so a failure there is expected and not a finding); a cron hook you do not recognise; any PHP file in uploads; a recently modified file in a place nobody edits. The file listing from the last command is noisy right after an update, so compare against what you changed yourself. For the full walk, see the hidden admin account audit and our compromise assessment for an earlier core flaw, which uses the same approach.

Rotate the secrets the workers could have held

Wiz’s write-up states that the memory reads can expose passwords, tokens and API keys held in worker memory. A WordPress process holds the database password, the authentication keys and salts, and often payment, mail and storage keys. If you cannot rule out an earlier break-in, rotate them. Patchstack’s guidance for a suspected compromise is the same: treat the server as potentially compromised and rotate credentials it held.

# Replace the salts in wp-config.php (logs everyone out)
wp config shuffle-salts
# List the secrets-bearing constants you now need to review
wp config list --fields=name | grep -Ei "DB_PASSWORD|KEY|SECRET|TOKEN|PASS"

Change the database user’s password in the database first and in wp-config.php straight afterwards, so the site is never pointed at a password that does not exist. Then work outward: administrator passwords, application passwords (wp user application-password list <user> lists them), payment gateway and mail API keys, backup storage keys, and deployment tokens. Rotating a key is only finished when you have confirmed that nothing still uses the old one, so watch the provider’s usage log for the old key after the change.

After the emergency: a maintained setup

PHP2Shell is a reminder that part of your site’s security is a job somebody has to do every month: know which PHP version each site runs, confirm that the host applied a patch and restarted the workers, test updates before they go live, keep restorable backups, and know where your secrets live. Whether you do that yourself, with an in-house person or through a provider, write the duties down. A short list that any maintenance arrangement should cover:

• A current inventory of sites, PHP versions and SAPIs, and who can restart the workers.
• Updates tested on a staging copy before they reach production.
• Off-site backups with a restore you have actually tested.
• Uptime monitoring and a vulnerability scan on a schedule.
• A named person who reads vendor and host security notices the day they arrive.
• A secrets list with an owner and a rotation routine, so a week like this one is a checklist rather than an improvisation.

If you would rather hand that to a team, Wbcom Designs, the team behind this site, sells fixed monthly care plans, per site. From its care plans page: every plan includes updates tested on a staging copy, off-site encrypted backups kept for 30 days and test-restored monthly, malware removal at no extra charge, 24/7 uptime monitoring from three regions and a weekly written report, and it works with your current host. Essentials is $99 a month, Professional $179 (backups every 12 hours, one hour of support work a month and unlimited content edits), Ultimate $299 (adds emergency help when the site is down and two hours of support work), and Care Pro $499 (adds four developer hours a month and a direct Slack channel). Hosting, premium plugin and theme licences, redesigns and new features are not included. There is no contract and the first 30 days are refundable. Check the care plans page for current terms.

Common questions

Is my site safe because it is behind Cloudflare?

Not on that fact alone. Cloudflare’s WAF rules are described by Patchstack as a stopgap, and they help only if the origin accepts traffic exclusively from Cloudflare. Patch the PHP.

Do I need to update WordPress or WooCommerce?

No. WooCommerce’s post says no WooCommerce or WordPress update is required or planned for these issues. Keep updating them for their own sake, but it does not address this.

My host says it is handled. How do I confirm?

Ask for the exact PHP build and the date the patched build went onto your plan, then check the version in Site Health yourself, and the package changelog if the number is below the floor. A host can patch the packages and forget to restart the pool, and a restart is part of a real patch. The same logic is in our guide to testing your host’s security claims.

I updated. Do I still need to check for a compromise?

If the site ran an unpatched PHP while details were public and exploit attempts were being seen, yes, a quick pass is cheap. Patching closes the door but does not tell you whether someone was already inside.

Is PHP 8.2 fine to stay on?

Patch to 8.2.35 now. Upstream security support for 8.2 ends on 31 December 2026, so schedule the branch move rather than stay.

What we could not verify

• Wordfence’s own page on this issue (our fetch failed). We make no claim about its firewall coverage.
• Whether any compromise of a WordPress site through these CVEs has been confirmed in the wild. Patchstack reported probing and hosting-partner reports, with no hard evidence of breaches as of 13:57 UTC on 21 October. Later updates may differ.
• Host-by-host patch status. We do not keep a table here. WPVanguard’s hosting status page tracks it, and we have relied on it only for the CloudLinux version-string point above.
• Which of Wiz’s four underlying bugs maps to which CVE id. The page’s table did not render clearly for us, so we follow php.net’s description of each CVE and keep Wiz’s four bugs as a separate list.

Sources

• php.net news archive, 20 and 21 October 2026 announcements
• php.net supported versions
• Wiz Research, PHP2Shell
• Patchstack, PHP major vulnerability alert (status as of 22 October)
• WooCommerce developer blog, PHP security release
• WPVanguard, PHP2Shell hosting status

If you maintain several sites, the useful habit from this week is the inventory: a single list of every site, its PHP version, its SAPI and who can restart it. Building that list on a quiet day is much cheaper than building it during a critical release.