News / Industry
PHP2Shell: two critical PHP flaws are now under active attack
PHP shipped emergency patches for two critical remote code execution flaws called PHP2Shell. CISA added CVE-2026-109618 and CVE-2026-109619 to its KEV catalog.
The PHP Foundation broke its own release schedule on October 21, 2026, shipping emergency patches for two critical flaws in the PHP interpreter. The pair is tracked together as PHP2Shell, and both can be driven to remote code execution. The fixes did not get much quiet time. Researchers were reproducing one of the bugs before the release, exploitation attempts followed the same day, and on October 26 the US Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities (KEV) catalog. For software that sits under a large share of the public web, that is a short fuse.
| Key fact | Detail |
|---|---|
| CVEs | CVE-2026-109618, CVE-2026-109619 |
| Severity | Critical, both |
| Impact | Remote code execution |
| Fixed in | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Exploitation | Attempts observed from October 21, 2026 |
| Added to CISA KEV | October 26, 2026 |
What happened
Both flaws live in how PHP manages memory for a single request. CVE-2026-109618, which CISA labels a "PHP Memory Corruption Vulnerability," turns on out-of-memory handling: when PHP runs out of memory, it can interrupt a request while that request's internal data is only partially initialized, leaving the interpreter holding memory it should not trust. CVE-2026-109619, the "PHP Stale Internal Request-State Vulnerability," is a lifetime bug: request-owned internal state can survive after the memory backing it has been freed, so later code can reach into memory that no longer belongs to it. Different triggers, same destination. Each can be pushed from a crash or a corruption into remote code execution. The PHP Foundation fixed both in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The flaws were understood before they were public. Technical details leaked ahead of the scheduled release, and the security firm watchTowr reported reproducing CVE-2026-109618 and assessed that both bugs could enable code execution (Recorded Future). Earlier in the research cycle, Wiz had already demonstrated unauthenticated remote code execution against common content management systems, including WordPress, Drupal, and Joomla, which is the detail that makes PHP2Shell broad rather than academic. Those platforms run on countless shared hosts whose owners rarely patch the day a fix drops.
Why it matters
The exposure is defined by how much of the internet runs on PHP. The web-technology surveyor W3Techs puts PHP at around 70% of the websites whose server-side language is known (W3Techs). That population skews heavily toward CMS-driven sites on shared hosting, exactly the systems that are internet-facing, numerous, and slow to update. A critical interpreter flaw in that setting is not a single patch job. It is millions of separate ones.
Exploitation tracked the disclosure closely. watchTowr reported activity against the new flaws on October 21, and Cloudflare, whose CTO said the company had seen early attacks, shipped an emergency update that day adding seven managed ruleset rules to filter known exploit traffic (Help Net Security). One caution belongs here: the public reporting so far describes attempts and probing more than confirmed compromise, and indicators of compromise remain limited (Recorded Future). The point is not that mass breaches are proven. It is that the quiet window between a public patch and reliable exploitation is the part that is closing.
A KEV listing raises the stakes beyond a severity label. Binding Operational Directive 26-04, which CISA cited when it added the two flaws, directs federal civilian agencies to prioritize rapid remediation of high-risk vulnerabilities in the catalog and to check whether a system was compromised before the patch was applied. CISA urges every organization, not only federal agencies, to treat the catalog as a priority queue (CISA). When two flaws from the same release land on that list within days, the message is plain: stop reading and start patching.
When a flaw sits in the interpreter that runs most of the web, the real question is not whether it reaches you, but whether you know where it runs.
The exposure-management read
For most teams, the patch is the easy part. The hard part is knowing where PHP actually runs. One organization can carry PHP on a managed CMS, a legacy intranet app, a vendor appliance, a container base image, and a staging box that someone left reachable from the internet. Each is a distinct instance to locate, version-check, and update, and the instances that slip are almost always the ones nobody remembered owning.
That inventory problem is the work of exposure management: keep a current, accurate picture of what you run and what is reachable from outside, so that when a PHP2Shell lands you are mapping a CVE to real assets instead of guessing. It is also why the difference between an attack surface and a raw list of findings matters. Knowing your surface is what turns "PHP has a critical RCE" into a short, specific set of hosts to fix, starting with the ones an attacker can reach. For teams buried in advisories, that is the difference between patching on evidence and patching on noise.
One more clock is running. PHP 8.2 reaches end of life on December 31, 2026, so the oldest systems in scope need an upgrade plan, not just this month's patch. The fix closes today's hole. Knowing where you run PHP is what makes you ready for the next one.