Are you ready for the storm? PHP2Shell: two unpatched critical PHP flaws (CVSS 9.2) spark RCE fears for millions of websites

The PHP security team announced on 20 October 2026 that it will publish a security release on Wednesday, 21 October 2026 at 14:00 UTC. The release fixes two critical vulnerabilities, both rated 9.2 on CVSS v4.0.

The team says "all PHP users are encouraged to prepare now so they can upgrade as soon as the release is available." It also says it may release earlier if details of either flaw become public or if there is evidence of active exploitation.

What do we know about the vulnerabilities? #

Very little so far, by design. The advance notice gives only the number of flaws and their severity. PHP says full details, affected versions and fixed versions will be published with the release. PHP's own notice does not name CVE identifiers.

What is being reported beyond PHP's notice? #

Details have started to circulate before the official release. Security firm Huntress says a post on the Hacker News forum on the morning of 20 October claimed two critical PHP vulnerabilities were headed for disclosure. The post was taken down, but screenshots spread on social media. Researchers have nicknamed the pair "PHP2Shell"; the name does not come from PHP.

None of these claims has been confirmed by PHP. Treat the affected version range and the remote code execution label as unverified until the official release.

CERT-EU advises immediate patching once fixes are out, and says organizations that cannot patch straight away should consider isolating internet-facing applications from public networks until a fix is available.

How many websites run on PHP? #

PHP is used by 69.3% of all websites whose server-side programming language is known, according to web technology survey W3Techs on 21 October 2026. That makes it by far the most common server-side language on the web, powering platforms such as WordPress, Drupal, Magento and Laravel applications.

This does not mean 69.3% of websites are vulnerable. Which sites are affected depends on the PHP versions and features involved, which PHP has not yet disclosed. What it does mean is that a very large share of the web will need to check whether it is affected once details are out.

How many PHP sites run versions that no longer get security fixes? #

PHP currently provides security fixes for four branches:

Every older branch, including PHP 8.1, 8.0, 7.x and 5.x, is end of life and will not receive this fix.

W3Techs data shows how many sites that leaves behind. Among PHP websites, 27.0% use PHP 7, 7.7% use PHP 5 and 0.1% use PHP 4. Another 21.0% of PHP 8 sites run 8.0 or 8.1. Combining those figures, AppSecNews calculates that roughly 48.5% of PHP websites run a version that no longer receives official security fixes, and only about 51.5% run a supported branch. If the new flaws affect older code, those sites will have no official patch.

Internet scans point the same way. Threat intelligence firm Mallory counted 883,717 internet-facing hosts on 20 October whose Shodan banners reported PHP 8.1 or older, about 59% of roughly 1.5 million hosts that reveal a PHP version. About 740,000 more hosts reported PHP without a version. Mallory notes these are banner counts, not confirmed vulnerable systems, and that some Linux distributions backport fixes to older-looking versions.

Why does a pre-announcement matter? #

Once a fix is public, attackers can compare the old and new code to work out how to exploit the flaws. That makes the hours and days after the release the riskiest time for unpatched servers. The advance notice gives teams time to line up testing and maintenance windows before that clock starts.

What should PHP users do now? #

1. Find every PHP installation. Check web servers, containers, CI images and command-line tools. php -v shows the installed version.
2. Know your patch path. If you use a Linux distribution's packages, a hosting provider or container images, check when they plan to ship the fix. Some distributions backport security fixes without changing the main version number, so check their advisories rather than relying on php -v alone.
3. Book a maintenance window for shortly after 14:00 UTC on 21 October, and prepare to test the update on staging first.
4. Plan upgrades for end-of-life versions. Sites on PHP 8.1 or older cannot rely on official fixes. PHP 8.2 also reaches end of life on 31 December 2026.
5. Protect what you cannot patch. For end-of-life versions, Huntress suggests upgrading, taking the system offline or placing it behind a VPN or web application firewall.
6. Watch for signs of attack. Huntress recommends alerting when PHP worker processes start shells, interpreters or download tools.
7. Watch php.net for the release notes, affected versions and CVE IDs, and patch as soon as your testing allows.

This is a developing story. AppSecNews will update it with affected and fixed versions once PHP publishes the release.