PHP2Shell Checklist for Startup Teams: Inventory Every PHP Install, Check for Compromise

Two critical flaws in PHP itself, nicknamed PHP2Shell, were fixed on Wednesday, 21 October 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP's advance notice of 20 October rated both at CVSS v4.0 9.2, and its advisory says they can allow remote code execution without logging in, on any PHP installation serving web requests.

For a startup, the fix is less a single upgrade than an inventory. PHP runs inside vendor appliances, control panels and containers, and some of it does not advertise that it runs PHP under the hood.

Find Every PHP Install, Including the Ones Hiding in Vendor Software

Huntress recommends inventorying every PHP install, including those bundled inside vendor software, control panels and CMS platforms. Patchstack names WordPress and Laravel as PHP applications exposed on vulnerable PHP versions, alongside Drupal, Magento and Joomla.

Public exposure gives a sense of scale. Tenable reports that Silas Cutler estimates more than 1.3 million potentially vulnerable hosts, and that a Shodan search by Henk Poley counts more than 1.9 million internet-exposed PHP hosts. Those figures measure exposure, not attacks.

Tenable also lists scanner plugins that detect PHP installations and unsupported versions.

Move to the Published Fixed Versions

PHP's 21 October advisory names the fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, one for each supported branch. It says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates the risk highest on mod_php. Container images built on an older PHP keep it until they are rebuilt on a fixed version.

Severity figures also differ. The leaked post and watchTowr's early statements used 10.0, according to BleepingComputer and Tenable, while PHP's official rating is 9.2.

Linux distributions may backport fixes, so organizations should check their vendor's advisories. Sansec reports that The PHP Foundation says the Remi repository will not publish updates on 21 October, so teams that rely on it should move to distribution packages or build from source.

PHP 8.1 and Older Get No New Release

Tenable describes PHP 5.x through 8.1.x as end-of-life, and the PHP project released no new versions for them. Given the severity, PHP's security team published minimal source backports for PHP 7.4, 8.0 and 8.1, for teams that build from source or have no long-term-support vendor. Otherwise, servers on 8.1 or older need a distribution or vendor backport, or an upgrade.

The affected range is disputed. The leaked post claimed PHP 5 onward. Sansec says an exploit banner claims support back to 5.4.0. Tenable cites CERT-EU as saying all versions from PHP 5 onward could be affected. PHP's advisory does not list affected versions either; it says every PHP installation serving web requests is at risk.

For end-of-life installs, Huntress lists three options: upgrade, take the server off the internet, or put it behind a VPN or WAF. Tenable, citing CERT-EU, suggests isolating internet-facing applications from public networks where patching is not possible.

Stop-Gap Measures and What They Can Break

Stop-gaps can break things, and none of them replaces the patch. Several have been suggested, and some carry a cost.

Blocking multipart/form-data requests at the web server breaks file uploads such as product images and media libraries, and can break carts and checkout forms. Sansec advises placing a test order after any such rule and removing the rule once the site is patched.

Putting a site behind Cloudflare brings WAF rules that Cloudflare says cover all plans, including free. Cloudflare calls them a stopgap, and they protect only traffic routed through Cloudflare. The origin must accept only Cloudflare IP ranges, and a nameserver switch can take hours.

Taking a site offline is one option, and read-only mode is the fallback if it cannot go offline. Read-only mode rejects every method except GET and HEAD. Sansec says built-in maintenance modes do not help, because PHP still parses each request. Gina Peter Banyard, a PHP core developer, prefers the offline option, according to Sansec.

Two PHP settings, session.upload_progress.enabled and session.use_strict_mode, are a separate group. Disabling upload progress removes PHP's native progress bars, and strict mode has no effect on Redis or database session handlers. Patchstack says these settings reduce exposure without fixing the flaw, and PHP 8.6 release manager Joe Ferguson says they will not protect a site on their own. PHP's advisory lists its own interim measures for servers that cannot update at once, such as setting session.upload_progress.enabled=0 in php.ini or the FPM pool (not through ini_set() or .user.ini) and restarting every worker, and a low post_max_size, but says only an update is a complete solution.

Patchstack also warns against unofficial fix plugins and copy-pasted snippets, which it says are unverified and may break sites.

Signs of Compromise, and Who Says Attacks Have Started

Huntress lists PHP worker processes, such as php-fpm, php-cgi, httpd and apache2, starting shells, interpreters or download tools as a warning sign. Command lines containing /dev/tcp/, fsockopen or mkfifo, and reconnaissance commands such as whoami, id or uname -a run from a web server, are also on its list.

Teams should also check the web root for webshells and new files, and review cron jobs, scheduled tasks and accounts for new entries. Huntress points to Florian Roth's process-watcher, in observe mode, as a free option on Linux servers without endpoint detection. If compromise is suspected, Huntress recommends isolating the server and preserving the web server and PHP logs.

Exploitation reports conflict. Cloudflare's CTO, Dane Knecht, said on 21 October that Cloudflare was seeing early attacks, and Sansec cites Cloudflare placing those attacks at 07:43 UTC. Patchstack says it received reports of active exploitation from multiple hosting partners at 07:34 UTC.

The Hacker News reports that no exploitation has been reported so far, and that Cloudflare says it is seeing early attempts to exploit the flaws. watchTowr said on 20 October that it had not observed exploitation in the wild, and Huntress said that as of its 20 October post it had seen none in its partner environments.

The Hacker News reports that neither flaw is in CISA's Known Exploited Vulnerabilities catalog.