PHP2Shell update set for two critical PHP RCE flaws
PHP2Shell is the name researchers have given to two critical PHP vulnerabilities that watchTowr says can enable remote code execution (RCE), meaning an attacker may be able to run commands on a vulnerable server from elsewhere. PHP scheduled an out-of-cycle security release for 14:00 UTC on October 21 and rated both flaws 9.2 under version 4.0 of the Common Vulnerability Scoring System (CVSS), a standard scale for assessing vulnerability severity. At the time of writing, the update had not been released, and PHP had not disclosed the affected versions, technical cause, required configuration or fixed versions.
The emergency notice followed an October 20 post on Hacker News that claimed two RCE vulnerabilities affected every PHP version from PHP 5 onward. That post assigned a CVSS score of 10.0, listed October 22 as the expected disclosure date and offered no supporting evidence. watchTowr subsequently said the existence of the embargoed flaws was genuine, but did not release technical details. PHP published its own notice at 19:33 UTC that evening and scheduled the update one day earlier than the date in the leak. The notice also said the release could be accelerated if vulnerability details became public or evidence of active attacks appeared.
Researchers are using the identifiers CVE-2026-109618 and CVE-2026-109619, both of which appeared in the leaked post. PHP's notice did not name either identifier, so their official association with the flaws had not been confirmed there. The leak's claim that all releases since PHP 5 are vulnerable was also unconfirmed. watchTowr's frequently asked questions page said no official vendor advisory had established that scope, and no required PHP feature or configuration had been described. The PHP2Shell label likewise comes from researchers rather than PHP.
Only PHP's four supported branches, 8.2 through 8.5, are eligible to receive fixes. Trackers cited ahead of the release expected updates numbered PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, but PHP had not confirmed those versions. As of September 24, the current releases were 8.5.11, 8.4.26, 8.3.35 and 8.2.34. PHP 8.5 was in active support until December 31, 2027, while PHP 8.4 was in active support until December 31, 2026. PHP 8.3 was receiving security-only support until December 31, 2027, and PHP 8.2 until December 31, 2026.
PHP 8.1, 8.0, all 7.x releases and all 5.x releases are end of life, meaning PHP no longer supplies security updates for them. If the vulnerabilities are eventually confirmed to affect those branches, installations still using them will not receive a vendor patch. This is especially relevant to older websites, hosting accounts, control panels, vendor appliances and Windows applications that may include an embedded PHP installation administrators do not routinely see.
Security company Mallory counted about 884,000 internet-facing hosts whose HTTP banner, the identification information a web server may expose, reported PHP 8.1 or older to the Shodan search engine on October 20. That represented 59% of roughly 1.5 million hosts that disclosed a PHP version. Another 740,000 hosts reported using PHP but did not reveal a version. These figures describe visible banners, not systems confirmed to contain either PHP2Shell vulnerability, so they cannot establish the number of affected servers.
PHP had not published a workaround before the scheduled release. Huntress recommended identifying every PHP installation, including copies packaged inside appliances, Windows software, cPanel and Plesk, then preparing to update internet-facing systems first. Administrators should also check whether their Linux distribution or hosting provider supplies a backported package, which applies a security repair to an older packaged release without replacing it with the newest full version. Systems on an end-of-life branch should be upgraded, removed from public internet access, or placed behind a virtual private network or web application firewall until they can be updated. CERT-EU additionally advised considering isolation of public-facing applications from public networks while no fix was available.
Monitoring can help identify suspicious activity but does not replace patching. Administrators were advised to alert when php-fpm, php-cgi, httpd or apache2 starts command shells, interpreters or download utilities. A researcher-published process-watcher utility can record every program launched by a PHP process on Linux, together with its command line, but it observes a program only after execution begins and does not block it. If suspicious activity is found, guidance calls for isolating the server, preserving PHP and web server logs, and checking for web shells, which are malicious files that provide remote server control, as well as unexpected files in the website directory, new cron jobs, scheduled tasks or accounts.
Huntress said that as of October 20 it had not observed exploitation in partner environments, had not created or reproduced a proof of concept, and knew of no public exploit code. watchTowr similarly listed no reported exploitation as of October 21 and said the flaws were not in the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog. That status could change after technical details become available. For comparison, Akamai observed attempts to exploit CVE-2024-4577, a separate PHP vulnerability affecting CGI mode on Windows, against its honeypot systems within 24 hours of that flaw becoming public in June 2024.
The official release was expected to establish which versions are vulnerable, which PHP component is involved, whether exploitation depends on a particular operating mode, configuration or login, and which releases contain the repairs. Website owners should ask their host or administrator to confirm the installed PHP branch and update status rather than relying on an unverified version range. For WordPress site owners seeking managed operations, AEU Hosting provides managed WordPress hosting, secured end to end. Until PHP publishes the final advisory, the precise exposure remains uncertain, but unsupported PHP installations already require an upgrade or isolation because they cannot receive a vendor fix.