PHP2Shell: two critical remote code execution vulnerabilities in PHP — what is known and how to prepare

The PHP security team has announced two critical vulnerabilities with a CVSS v4.0 score of 9.2 and scheduled an out-of-band security release for 21 October 2026 at 14:00 UTC. According to researchers from watchTowr, both vulnerabilities allow remote code execution (RCE). Only the four supported branches — 8.2 through 8.5 — will receive patches. By the calculations of Mallory, about 884,000 internet-exposed hosts are running outdated PHP versions and will not receive vendor fixes. As of the publication date, there have been no observations of exploitation in the wild, but the history of similar PHP vulnerabilities shows that attacks can start within 24 hours after details are disclosed.

What is known about the vulnerabilities

The official PHP advisory confirms the existence of two critical vulnerabilities, but does not disclose technical details, affected versions, or even the CVE identifiers. Full information is expected to be published together with the release. The identifiers CVE-2026-109618 and CVE-2026-109619 appear in researchers’ publications and in a Hacker News leak, but PHP does not name them in its advisory.

It is important here to separate confirmed facts from unconfirmed claims. Officially, the following has been established:

• Both vulnerabilities are rated by the PHP security team as CVSS v4.0 9.2 (Critical)
• Patches are being released for PHP branches 8.2, 8.3, 8.4 and 8.5
• Technical details, including the vulnerable component and attack vector, have not yet been disclosed

A Hacker News leak from 20 October mentioned a CVSS score of 10.0 and claimed that the vulnerabilities affect all versions starting with PHP 5. However, the 10.0 score is a figure from an unverifiable leak, not an official vendor rating. As watchTowr notes in its FAQ, the claimed coverage “starting with PHP 5” is not confirmed by the official vendor advisory, nor have the technical root causes of the vulnerabilities or configuration requirements for their exploitation been established.

Matrix of affected versions and scale of the problem

Based on the available data, the following picture emerges:

• Branches 8.2–8.5 — supported and will receive patches. According to Mallory, the fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (these version numbers are provided by Mallory, not in the official PHP advisory)
• PHP 8.1 and earlier — branches that have reached end of life (end of life) and will not receive vendor patches
• PHP 5 and onward — unconfirmed vulnerability range from the leak

It is this last point that creates the greatest uncertainty. If the vulnerabilities do in fact affect versions all the way back to PHP 5, the scale of the problem increases significantly. According to Mallory’s estimates, of approximately 1.5 million internet-exposed hosts that report their PHP version via HTTP banners in Shodan, 883,717 (59%) are running branches that will not receive fixes. Another 740,000 hosts report the presence of PHP without specifying the version. These figures reflect banners, not confirmed vulnerable systems or unique organizations, but they do indicate a substantial potential impact.

Exploitation status

According to watchTowr, as of 21 October 2026 there has been no observed exploitation in the wild. Huntress reports that as of 20 October it had not observed exploitation among its partners, had not reproduced a proof of concept, and had no information about public exploit code. The vulnerabilities are not listed in the CISA Known Exploited Vulnerabilities catalog. There are also no confirmed indicators of compromise (IOC) at the time of publication.

However, the absence of observed exploitation is a point-in-time assessment. By way of comparison: when CVE-2024-4577 (a PHP vulnerability in CGI mode on Windows) was disclosed in June 2024, Akamai observed exploitation attempts on honeypots within 24 hours.

Timeline of the leak and responses

The situation unfolded in an unusual way. On 20 October, a post appeared on Hacker News with information about two RCE vulnerabilities in PHP, allegedly with a CVSS score of 10.0, listing CVE identifiers and a disclosure date of 22 October (Thursday). The author of the post admitted that the source was “trust me, bro.” After that, watchTowr confirmed on X that the leak was real, the vulnerabilities were under embargo, and everyone was supposed to wait until Thursday. PHP published its advisory that same evening, at 19:33 UTC, scheduling the release for Wednesday — one day earlier than the date mentioned in the leak. The advisory includes a caveat: the release may be accelerated if vulnerability details become public or evidence of active exploitation appears.

The leak revealed the fact that the vulnerabilities exist, their severity rating, the date, and the CVE identifiers, but not how the vulnerabilities work. This is an important distinction: the leak did not contain enough information to create an exploit.

Practical recommendations

PHP has not published any workarounds. Until the patch is released, the following set of actions is recommended, based on guidance from Huntress and CERT-EU:

1. Inventory: identify all PHP installations, including embedded PHP in vendor appliances, Windows applications and control panels (cPanel, Plesk)
2. Update readiness: prepare to install the patch as soon as the release is available. Prioritize internet-exposed systems. Check whether your Linux distribution or hosting provider offers backported packages
3. Outdated versions: systems running PHP 8.1 and earlier must be upgraded, removed from the internet, or placed behind a VPN or WAF
4. Isolation: CERT-EU recommends considering the isolation of internet-exposed PHP applications from public networks until a fix is available
5. Process monitoring: configure alerts when php-fpm, php-cgi, httpd or apache2 start shells, interpreters or loaders. On Linux servers without EDR, you can use process-watcher by Florian Roth — the tool logs every program started by a PHP process, together with its command line. Important: it records the process only after it has started and, in the author’s words, “prevents nothing”
6. Incident response: if you detect suspicious activity, isolate the server, preserve web server and PHP logs, check for web shells, new files in the site root, new cron jobs and new accounts

Patching priorities should be set with the understanding that systems on outdated PHP branches (8.1 and earlier) will not receive a vendor fix. According to Mallory, there are about 884,000 such internet-exposed hosts. For these systems, the only options are to upgrade to a supported branch, restrict network access or place them behind a WAF. Organizations on supported branches (8.2–8.5) must install the patch as soon as it is published, starting with internet-exposed servers.

The release should clarify the key unknowns: exactly which versions are affected, which PHP component contains the vulnerability, whether exploitation requires a specific PHP mode or configuration, and how the vendor itself describes the vulnerabilities. Until then, all actions are preventive in nature, and the most critical step is to ensure readiness for immediate updating of supported branches and to isolate or decommission systems running outdated PHP versions.