PHP2Shell: is my WordPress site at risk and what to do

Every WordPress site running on a php.net build of PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is vulnerable to PHP2Shell (Linux distribution packages keep their own version numbers, see below). These four PHP versions came out on 21 October 2026 and fix two critical vulnerabilities that allow remote code execution without logging in. The flaw sits in PHP, so updating WordPress, the theme or plugins does not remove it. PHP on the server has to be updated, or you need to confirm that your host has done it.

The php.net notice for each of the four releases contains the same sentence:

There are no complete mitigations, updating is the only safe choice.

(php.net, release announcements of 21 October 2026)

#What is PHP2Shell

PHP2Shell is a pair of bugs in the PHP engine that, according to the researchers’ own page, were discovered by Calif, OpenAI and Wiz. The research and write-up are by Ryan Austin of Calif, and the bugs were found as part of OpenAI’s Patch the Planet initiative (Calif). Wiz Research published its own analysis (Wiz). The PHP project tracks them as two vulnerabilities:

Both are use-after-free memory safety bugs in the way PHP handles fatal errors, including out-of-memory errors, and a crafted HTTP request can trigger them before any WordPress code runs. The entries in the GitHub Security Advisories database for the php-src repository were published on 21 October 2026 at 13:34 UTC. They list every version below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

According to the timeline Calif published, the researchers reported the first bug to PHP on 11 August 2026, PHP confirmed on 15 August that their remote code execution proof of concept worked, and the patched releases came out on 21 October 2026 (Calif).

A day earlier, on 20 October, the PHP security team announced the release for 21 October at 14:00 UTC and stated that both vulnerabilities score 9.2 on the CVSS v4.0 scale (php.net, announcement of 20 October).

At around 14:05 UTC the Wordfence website showed only this message: “Wordfence services are temporarily unavailable as we implement mitigations for the currently unpatched PHP2Shell vulnerability. Thank you for your patience.” (wordfence.com, as seen on 21 October 2026 at around 14:05 UTC). When we checked again at 15:16 UTC, the site still showed only that message. Even a security vendor for WordPress took its own services offline for that time to roll out protections.

Three findings in the Wiz Research publication matter to a site owner:

• PHP versions back to 5.4 are affected,
• in Wiz’s tests, unauthenticated remote code execution worked on the wordpress:latest container image, as well as on Drupal and Joomla,
• a separate bug lets an attacker read part of the PHP process memory, which can hold passwords, authentication tokens, API keys and certificates, even when the application never starts a session (session_start()).

Wiz also notes that beyond the four bugs it described there are further variants of the same problem, and the PHP project’s fix removes all of them (Wiz).

#Is my WordPress site vulnerable

Yes, if it runs on a PHP version lower than the fixed release in its branch. According to php.net, every PHP installation serving web requests is at risk: PHP-FPM, Apache with the mod_php module, php-cgi, FrankenPHP and LiteSpeed. php.net assigns the highest risk to setups with mod_php, for which a demonstrated exploit exists that is triggered by an unauthenticated request before application code starts (php.net).

The WordPress, theme and plugin versions do not matter here, because the bug is in the PHP interpreter and automatic WordPress updates do not touch PHP on the server. Clean site code does not protect you either: according to Wiz, even a simple “Hello World” application on a vulnerable PHP version can be a target. A security plugin runs inside WordPress, and the request can trigger the bug before WordPress loads.

A WooCommerce store has more to lose in this situation than a company website. The database and configuration hold customer data, orders and payment gateway keys, and the memory disclosure affects exactly this kind of secret.

Calif confirmed unauthenticated remote code execution on WordPress 7.1.2, and also on Magento 2.4.9, phpMyAdmin 5.2.3 and WHMCS, among other applications (Calif). In our assessment, phpMyAdmin or a client panel running on the same server’s PHP is exposed the same way, so the server needs the PHP update even if WordPress itself is not reachable.

Static sites are out of reach of this flaw. If the site is generated into HTML files and the server does not run PHP to handle requests, the php.net notice does not apply, because it describes PHP installations that serve web requests.

#How to check the PHP version on a WordPress site

The simplest way is through the WordPress dashboard:

1. Log in as an administrator.
2. Open Tools, Site Health.
3. Go to the Info tab and expand the Server section.
4. Read the PHP version row.

Compare the number with the table:

The support dates come from the supported versions table on php.net.

The PHP version shown in Site Health is the one serving the website. The hosting control panel may show a different version for the command line or for another domain on the same account, so the reading from WordPress is the one that counts.

Packages from Linux distributions are the exception. According to php.net, distributions and LTS support vendors received the fixes earlier and publish their own packages (php.net). A distribution backports the fix into its own PHP version and keeps its own number. Ubuntu 24.04 LTS fixed PHP with package 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), so a patched site on such a server still shows 8.3.6 in Site Health. Debian 13 (trixie) received php8.4 8.4.27-1~deb13u1 (DSA-6574-1), while the Debian security tracker still listed php8.2 in Debian 12 (bookworm) as vulnerable when we checked on 21 October 2026 at 15:14 UTC (Debian security tracker). On a VPS with PHP from the distribution repository, the version number alone does not settle the question. Check the distribution’s security notice or the package changelog for the fixes for CVE-2026-109618 and CVE-2026-109619, and on hosting ask the host.

#What to do if your host has not updated PHP yet

On shared hosting, the hosting company updates PHP. The site owner has four moves:

1. Switch the version in the control panel. Many hosting panels let you choose the PHP version per domain. If a fixed version is already on the list, switch the site to it and confirm it in Site Health.
2. Open a ticket with the host. Write to technical support with the numbers CVE-2026-109618 and CVE-2026-109619 and ask when the server will get PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a package with these fixes.
3. Back up before the change. Moving to a newer PHP branch can break an old plugin or theme. A copy of the files and database from before the change shortens the way back to a working site.
4. Take the site offline until the update. If PHP cannot be updated quickly, take the site offline or serve a static maintenance page without PHP in its place. Our note: a maintenance mode plugin inside WordPress is not enough, because the request still reaches PHP. John Mueller of Google wrote on 21 October: “If you’re taking PHP sites down to schedule time to deal with ‘unplanned updates’, use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN.” (John Mueller, Bluesky). The maintenance page with status 503 then comes from the web server, the CDN or another server after a DNS switch, without PHP, because a maintenance page with status 200, timeouts, 404 or 500 can hurt indexing. Google Search Central recommends 503 when a site has to be disabled urgently for 1 to 2 days, an indexable home page with status 200 for a longer break, and warns against returning 503 for robots.txt (Google Search Central).

WordPress.org wrote on 21 October that the flaws are not specific to WordPress and that “No WordPress update is required or planned for these issues” (WordPress.org). The same post advises owners who manage their own server with PHP older than 8.2 to consider taking it offline while they prepare the update, and points to the UK NCSC, which advises considering taking the system offline until it can be fully mitigated if the temporary mitigations cannot be applied quickly enough (NCSC). Before the fix was released, CERT Polska recommended temporarily disabling internet-facing PHP services (CERT Polska, 195/2026) and later listed its own php.ini values in notice 196/2026. Patchstack gives the same offline advice for high-risk sites and warns against unofficial “fix” plugins and copy-pasted snippets, which “are not verified and can break your site” (Patchstack). A plugin runs inside PHP, so it cannot fix a flaw in PHP itself.

php.net describes temporary server settings for administrators who cannot update PHP right away. They include request size limits and disabling session upload progress tracking. These settings only work at the server configuration level: php.net points out that for the session setting neither ini_set() nor a .user.ini file in the site directory is enough. The notice also stresses that none of these settings makes an installation safe:

while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

(php.net, security notice of 21 October 2026)

As a temporary, partial mitigation, Calif suggests session.upload_progress.enabled=0 together with memory_limit=-1 for PHP-FPM and memory_limit=-1 alone for mod_php, and warns that -1 removes PHP’s memory cap, which raises the risk of memory exhaustion (Calif).

php.net also says to remove invalid or deprecated PHP settings applied per request that emit diagnostics before initialization, and hiding diagnostics with error_reporting, display_errors or @ does not help. Our example, not one php.net gives: since PHP 8.3 all assert.* INI settings are deprecated, so on PHP 8.3 and newer check .htaccess, FPM pools and php.ini for leftover assert.* lines, for example php_value assert.active.

We have collected the details of these settings for server administrators in the section on the critical PHP release in our WordPress security hardening guide.

If your site’s traffic is proxied through Cloudflare (orange cloud on the DNS record), there is an extra layer. Cloudflare says that from 03:02 UTC on 21 October 2026, customers using its free or paid WAF were protected against PHP2Shell by default, including the Free plan, and that Pro, Business and Enterprise customers should check that the Managed Ruleset is deployed in block mode (Cloudflare). Patchstack adds that these rules only help if your server accepts traffic exclusively from Cloudflare (Patchstack). If the server answers anyone, a request sent straight to its IP address bypasses the WAF. Cloudflare also reports that it observed attack traffic targeting its customers before the official release, after the vulnerability had leaked, and saw attackers mutating payloads to bypass its rules. Patchstack’s timeline records “Multiple active exploitation incidents reported to Patchstack by hosting partners” at 07:34 UTC (Patchstack), while Huntress wrote that it had not seen in-the-wild exploitation across its partner base as of 10am ET (14:00 UTC) on 21 October (Huntress). Cloudflare itself treats the WAF as defense-in-depth and says to patch PHP anyway, and restricting uploads and upload sizes does not replace the fix either.

#How to spot an attack attempt in server logs

Wiz points out that the bugs operate below the application layer, so WordPress logs may show little. Until the update, look for three signals in the server logs (Wiz):

• unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses,
• unexpectedly large or malformed PHPSESSID cookies in server responses,
• unexplained restarts of PHP worker processes.

These signals show where to start looking. Their absence does not mean there was no attack, and their presence does not replace the update.

#Do I need to change passwords after the update

The php.net notice does not require a password change. This is our recommendation, based on the Wiz finding: the flaw lets an attacker read PHP process memory, which can hold passwords, tokens and API keys from other requests (Wiz). A site that ran on a vulnerable version for some time may have leaked such a secret without any trace in the WordPress dashboard.

Rotate secrets only after the PHP update, because a new password set on an unpatched server can leak the same way the old one did.

What to change:

• Keys and salts in wp-config.php. The official WordPress.org generator produces a new set of eight constants. After the swap, all logged-in users are logged out.
• The database password. Change it in the hosting panel and enter the new one in wp-config.php as DB_PASSWORD.
• Passwords of administrator accounts and other accounts with editing rights.
• API keys: WooCommerce REST API keys, payment gateway keys, SMTP credentials and third-party service tokens stored in plugin settings.

#What about PHP 7.4, 8.0 and 8.1

The PHP project no longer releases fixes for PHP 8.1 and older. The php.net notice points to two paths: some distributions and LTS vendors ship backported fixes, and everyone else should move to a supported version. Given the severity of the flaws, the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1, intended for people who build PHP from source or have no access to an LTS vendor (php.net).

For a site owner on shared hosting, source backports change nothing, because the host compiles and installs PHP on such a server. The real choice is moving to PHP 8.3, 8.4 or 8.5 in the fixed version. PHP 8.2 also got the fix, but its security support ends on 31 December 2026 (php.net), so choosing 8.2 means another change in two months.

The WordPress and PHP compatibility table is in the article is it worth updating WordPress. If an old theme or plugin blocks the move to a newer PHP version, the migration plan is in the guide to modernizing legacy WordPress codebases. If a WooCommerce store stopped taking orders or shows critical errors after the PHP version change, the WooCommerce rescue sprint helps. A review of the server configuration, PHP version and accounts after an incident is part of the WordPress security audit.

#Checklist for WordPress site and WooCommerce store owners

Status as of 21 October 2026, around 17:30 UTC, based on the php.net notice, the GitHub Security Advisories entries, the Calif and Wiz Research publications and the notices from Ubuntu, Debian, WordPress.org, NCSC, CERT Polska, Patchstack and Huntress.