PHP2Shell explained for small site owners and how to check your site

PHP2Shell is two critical flaws in PHP itself

PHP2Shell is two critical remote code execution flaws in the PHP engine, and the fix is a PHP update. If your site runs a release older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on its branch, or runs PHP 8.1 or older, ask your host to move it now.

Remote code execution means an attacker can run their own code on your server without logging in. Tenable rates both flaws 9.2 on the CVSS v4.0 scale.

Your own code can be spotless and you can still be exposed. A bare "Hello World" page on an affected PHP version counts. PHP runs a very large share of websites, including WordPress, Drupal and MediaWiki (the software behind Wikipedia). Researchers used WordPress, Drupal and Joomla to demonstrate the attack, and exploitation does not need any of them.

BleepingComputer reports that both flaws can be exploited for remote code execution, and that the attacker's code runs with the web worker's privileges. In plain terms, it runs as the account that serves your pages. Sites on the latest patched PHP releases are protected.

Both flaws start when a request ends abnormally

Microsoft describes both as PHP mishandling memory when a request terminates abnormally, for example through memory exhaustion or a fatal error.

The first flaw comes from out-of-memory handling. Tenable and Qualys both say that when memory runs out while PHP's request data is only partly set up, the cleanup that follows treats that half-built data as valid. That opens a path to remote code execution.

The second flaw is stale global state. Per Tenable, leftover state from one request points to memory that has already been freed, and a later request handled by the same worker can use it. Vendors word the details of the two flaws a little differently, and you do not need those details to act.

Datadog reproduced the out-of-memory corruption on PHP 8.5.11 with an unauthenticated HTTP POST request. That request never reached the target application's code.

Check your PHP version against four numbers

watchTowr's FAQ says PHP lists every release before these as vulnerable, and CISA names the same four fixed releases.

• PHP 8.2.x needs 8.2.35 or newer
• PHP 8.3.x needs 8.3.36 or newer
• PHP 8.4.x needs 8.4.27 or newer
• PHP 8.5.x needs 8.5.12 or newer

The research behind this piece found no single way to read your PHP version that works on every host, so asking your host is the method. Email them two questions: which PHP version does my site run, and when will it be on the fixed release for its branch? Ask them to confirm when the change is done, then check the version again.

Here is a hypothetical, not a customer story. A one-person WordPress shop learns it runs PHP 8.3.30. That is below 8.3.36, so the owner asks the host to update it.

CISA says the flaws affect all PHP installations serving web requests, including Apache with mod_php (which PHP considers highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Your choice of web server does not take you out of scope.

If you are on a hosted store platform where you never see PHP, ask the provider which PHP version they run and whether it is on a fixed release.

The PHP project is blunt on php.net: there are no complete mitigations, and updating is the only safe choice. It adds that Linux distributions and LTS vendors received the patches in advance, so your host may deliver the fix as a package update.

If you run your own server, the update is yours to do. Laravel's Forge advisory, which covers Forge-managed servers, says you must update PHP on each of your servers yourself.

Attackers are already using these flaws

watchTowr says it has observed exploitation in the wild, and CISA added both flaws to its Known Exploited Vulnerabilities catalog.

PHP 8.1 and older will not get a fix from the PHP project

Zend reports that the PHP project is not releasing a patch for PHP 8.1 or older, and that every PHP version back to 5.4 is hit by at least one of the two flaws. watchTowr confirmed the same for older unsupported branches, PHP 5 included.

Qualys says 110 million (71%) run end-of-life or end-of-support PHP, from 5.4 to 8.1. It adds that most of these will never get a vendor patch, and that upgrading to a supported branch is the only remedy.

If your site cannot move yet, there are bridges. Zend says it released patches for PHP 7.2, 7.3, 7.4, 8.0 and 8.1 through its long-term support service. php.net notes that some distributions and LTS vendors provide backported fixes. Laravel's Forge advisory lists patched package revisions for 8.1 down to 7.2, such as 8.1.34-9 for PHP 8.1. So a vendor package may exist for your old branch even though the project ships none. Treat any of these as time bought while you plan the upgrade.

CISA goes further. It says organizations that cannot update immediately, or that keep using PHP 8.1 or earlier, should take PHP-based systems offline until they are patched or updated. For a small shop that is a hard call, and the host's patch date is the number you need to weigh it, so ask for it now.

Before any jump between PHP versions, ask your host or developer whether your theme and plugins support the newer version.