PHP2Shell: Two Critical PHP Flaws (CVSS 9.2) and an Emergency Security Release

On Wednesday, 21 October 2026, at 14:00 UTC (16:00 in BiH), PHP has scheduled an out-of-cycle security release to fix two critical bugs. PHP scores both 9.2 under CVSS v4.0, and researchers at watchTowr say they let an attacker run code remotely (RCE). PHP has not yet published a technical description, and no attacks have been reported. The pair already has a nickname: "php2shell".

What we know and what we do not

PHP's notice, posted on 20 October, is very short. It gives the release slot, says two critical vulnerabilities are being fixed, scores each 9.2 on CVSS v4.0, and promises details and affected and fixed versions only once the update is out. It also warns the release may come early if the bugs become public or start being exploited. No CVE numbers appear in it.

The notice followed a leak. A post on news.ycombinator.com on 20 October claimed two PHP remote-code-execution bugs, scored 10.0 and reaching back to PHP 5, would be disclosed on 22 October; its author offered no proof. watchTowr then said on X that the leak was genuine and the bugs were under embargo. PHP then set its release a day before the date in the post. What leaked was a rating, a disclosure date and a pair of CVE numbers, with no technical explanation. So it helps to separate what is confirmed from what is merely repeated:

Still unknown: the exact version range, the vulnerable component, and whether an attack needs a special configuration, run mode or login. The release should settle all of that.

Who is exposed

Fixes are expected only for the four supported branches, PHP 8.2 to 8.5. Support status according to php.net:

Everything older, from 8.1 downward, is out of vendor support, so if those versions turn out to be affected there will be no official patch. A Shodan count by Mallory on 20 October hints at how many that could be: about 884,000 public hosts advertise PHP 8.1 or older in their banner, which is 59% of the ~1.5 million that show any version. A banner does not prove a system is vulnerable, so read the figure as a rough indication, not a list of vulnerable machines.

What to do: a preparation checklist

PHP has published no workaround, so preparation is mostly organisational. The checklist mostly follows Huntress guidance, with CERT-EU's isolation advice and a tool by Florian Roth added (as summarised by The Hacker News).

Before the release

1. Find every PHP in your estate, not only on web servers: appliances, Windows applications and hosting panels (for example cPanel and Plesk) often carry their own.
2. Set the order. Internet-facing systems first. Ask your Linux vendor or hosting provider whether fixes will be backported to the version you run.
3. For old branches, upgrade them, take them off the public internet, or put a VPN or web application firewall (WAF) in front of them until you do. If you cannot patch immediately, CERT-EU advises considering isolating internet-facing applications from public networks until a fix is available.

After the release

4. Apply the patch and confirm the new version is the one running.
5. Hunt for signs of attack: web server processes (php-fpm, php-cgi, httpd, apache2) that spawn shells, scripting interpreters or download tools. On Linux machines without EDR, Florian Roth's process-watcher can help by recording the processes PHP launches. It only records; it does not block.
6. If something looks wrong, isolate the server, preserve the logs of the web server and of PHP, and look for web shells, freshly added files in the web root, new cron or scheduled jobs, and unexpected accounts.

There is no public sign of exploitation so far: watchTowr's FAQ lists none, the bugs are absent from CISA's KEV list, and Huntress, as of 20 October, had seen nothing among its partners and knew of no public exploit code. History argues against complacency, though: after CVE-2024-4577 (PHP in CGI mode on Windows) went public in June 2024, Akamai recorded attacks on its honeypots in under 24 hours.

What this means for companies in BiH

PHP runs a huge part of the web: WordPress, Joomla, Drupal, Magento and WooCommerce, plus many custom-built business applications and portals. In our experience, many companies in BiH do not maintain PHP themselves but get it through a hosting provider, a web agency or a software vendor, so it is often unclear which version is running and who owns the patch. That is the biggest risk in the days after disclosure. Our recommendation:

1. Right away, ask your hosting provider and web agency which PHP version runs on your systems, when the patch will be applied and whether they offer backported packages.
2. Check whether you are on an old branch. If the application runs on PHP 8.1, 8.0 or 7.x, an upgrade plan is urgent because a fix for those branches may never come.
3. Make sure someone is watching. An exploitation attempt leaves traces: unusual web server processes, new files under the web root, unfamiliar cron jobs. 24/7 SOC monitoring can flag such signals quickly and trigger a response, and a web application penetration test shows what an attacker sees from outside.

Why fast patching of known vulnerabilities is decisive is also shown by our analysis of the attack on Romania's land registry.

Frequently asked questions

What is PHP2Shell?

An unofficial name researchers gave to a pair of critical RCE flaws in PHP; PHP itself does not use it. PHP rated both 9.2 on CVSS v4.0 and will publish the details with the release scheduled for 21 October 2026 at 14:00 UTC.

Which PHP versions are affected?

Not confirmed yet; PHP will name them with the release. Fixes are expected only for branches 8.2 to 8.5 (PHP patches only supported branches), and older branches are not expected to get an official patch. The leak's claim that everything since PHP 5 is affected has not been confirmed.

Is it being exploited, and what should I do right now?

As of 21 October 2026 there are no reports of exploitation. Inventory every PHP installation, prepare the upgrade and patch internet-facing systems first; upgrade old branches or shield them with a VPN or WAF. Earlier cases show attacks can start quickly, so do not postpone the patch.

Sources and credit

This news item draws on reporting by The Hacker News (author Swati Khandelwal), to whom we give credit, and on PHP's official notice on php.net. Exposure data comes from Mallory, technical claims from the watchTowr team, and preparation guidance from Huntress and CERT-EU. The text is our own write-up, not a translation of the original article.