PHP2Shell: Exploitation Began Days Before Patches, Over 1.5 Million Servers Still Exposed
A pair of critical PHP remote code execution vulnerabilities, collectively nicknamed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, has become the center of a fast-moving security story. Official patches arrived on October 21, 2026, but according to reports, exploitation attempts may have started days earlier, raising questions that many observers say deserve closer scrutiny.
Timeline: Exploitation Began Before Patches Existed
Reports indicate that Amazon detected what it described as the first exploitation attempt on October 17, four days before patches were made available. Vulnerability details reportedly leaked online on October 20, ahead of what was intended to be a coordinated disclosure. Official fixes for CVE-2026-109618 and CVE-2026-109619 followed the next day, on October 21.
This sequence has led some in the security community to raise the possibility of an embargo breach or leak, though the exact source has not been confirmed in available reporting. A recurring concern among industry observers is simply how a patch timeline can be undermined before it even begins.
What PHP2Shell Actually Is
PHP2Shell refers to two critical PHP remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Because PHP underlies an enormous share of web applications and platforms, researchers have described the potential reach of these flaws as substantial, though the practical impact appears to depend heavily on how quickly affected systems are patched.
Post-Disclosure: Mass Exploitation Scales Fast
Following public disclosure, exploitation activity reportedly scaled quickly. Cloudflare reported millions of exploitation attempts within hours of disclosure. Alongside this, proof-of-concept exploit code proliferated rapidly online, including variants that researchers suggest may be fake or non-functional.
Notably, security firm WatchTowr has indicated that, as of its reporting, none of the publicly circulating proof-of-concept exploits it reviewed had been confirmed to achieve successful remote code execution, a detail that tempers some of the more alarming early claims circulating about the vulnerabilities.
The Unpatched Exposure Problem
Exposure estimates vary by source. Some reporting places the number of unpatched, internet-facing PHP servers above 1.57 million as of the patch release date, while other scanning organizations, including Censys, VulnCheck, and VirusTotal, have reported differing figures. These discrepancies likely reflect differing scan methodologies rather than a single agreed-upon count.
A further complication many observers note is the large population of end-of-life PHP installations that no longer receive vendor support, as well as so-called shadow IT: forgotten or undocumented deployments that are difficult to identify and remediate even when organizations are actively trying to patch.
Why Comparisons to Log4Shell Are Being Made
Some security commentators have drawn comparisons to the 2021 Log4Shell incident, citing PHP's broad footprint across the web as a similar source of risk. The combination of pre-disclosure exploitation, leaked vulnerability details, and a large population of slow-to-patch systems is seen by some as creating conditions for a prolonged exploitation window. It remains uncertain whether the ultimate scale will match Log4Shell, and such comparisons at this stage appear to be more about potential risk than confirmed outcome.
Vendor and Government Response
The Cybersecurity and Infrastructure Security Agency, or CISA, issued an alert urging immediate upgrades to patched PHP versions: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Additional advisories have reportedly been published by Drupal, Cisco, Trend Micro, Sophos, Tenable, eSentire, and Qualys, along with the Dutch National Cyber Security Centre, or NCSC. Several of these advisories also flag downstream platforms built on PHP as potentially exposed, though the specific scope of affected downstream software appears to still be under assessment by various vendors.
What Organizations Should Do Now
Security advisories broadly converge on a few recommended actions. Organizations are urged to prioritize immediate patching to the specified PHP versions and to audit internet-facing systems for unknown or forgotten PHP installations. Monitoring vendor advisories for downstream software dependent on PHP is also recommended, given that many applications and platforms rely on PHP without that dependency being obvious to administrators.
Given the reported pre-disclosure exploitation and rapid scaling of attack attempts after public disclosure, several advisories suggest organizations treat unpatched systems as potentially already targeted rather than only theoretically vulnerable.