Critical PHP Core RCE CVE-2026-109618/109619: Detection Guidance for Elastic Users

What happened

On October 20, 2026, details of two unauthenticated remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, were posted online before any official patch existed. The PHP security team announced an emergency release scheduled for October 21, 2026 at 14:00 UTC, rating both flaws as critical with a CVSS v4.0 score of 9.2. Researchers at watchTowr confirmed the bugs and demonstrated a proof‑of‑concept for CVE-2026-109618, though no in‑the‑wild exploitation has been observed to date. The community has dubbed the exploit vector php2shell, reflecting its tendency to spawn a shell on the target web server.

These memory‑safety bugs reside in the core PHP interpreter, meaning any PHP runtime—whether embedded in a CMS, a shared hosting environment, or a custom application—can be impacted. The rapid disclosure cycle and lack of an immediate PoC create a challenging environment for defenders, who must rely on behavioral detection rather than signature‑based methods.

Who is affected

Because the flaws are in PHP core, every installation that runs PHP 8.3 or earlier is potentially vulnerable. This includes the most common content management systems such as WordPress, Drupal, Joomla, and Magento, as well as shared hosting providers, control panels, and a long tail of vendor software that bundles PHP without explicitly advertising it. Any organization that hosts PHP applications on a web server—whether on-premises or in the cloud—must evaluate its inventory for exposure.

Organizations that rely on custom PHP scripts, legacy frameworks, or third‑party libraries that embed PHP are also at risk. Even if a site does not expose a public PHP endpoint, internal administrative interfaces or API gateways that process PHP code can be exploited if the core is unpatched.

Impact

The primary consequence of these vulnerabilities is the ability for an attacker to execute arbitrary code on the web server with the privileges of the PHP worker process. In practice, this often manifests as the creation of a reverse shell or the deployment of a web shell, providing a foothold for further lateral movement or data exfiltration.

Because the exploitation flow converges on a PHP worker process performing actions it should not, the attack surface is limited to the web server and its associated services. However, the impact can be severe if the PHP worker runs with elevated privileges or if the server hosts sensitive data or critical infrastructure.

Exposure

Exploit convergence means that regardless of the specific payload, the attacker will typically trigger anomalous behavior in the PHP worker: unexpected system calls, creation of new processes, or execution of shell commands. This convergence allows detection engines to identify attacks even without a known exploit signature.

"The convergent post‑exploitation flow is what we detect, and it is what this post is about."

Elastic has developed detection rules that flag these patterns, such as a PHP worker spawning a shell or executing unexpected binaries. These rules can be deployed immediately, providing early warning while a patch is applied.

What to do

• Apply the PHP 8.3 emergency release immediately; verify the version with php -v.
• Enable Elastic detection rules for PHP worker anomalies; review the rule set for "php2shell" and related behaviors.
• Audit all PHP installations across your infrastructure; document version, configuration, and access controls.
• Implement least‑privilege for PHP workers; restrict file system access and disable unnecessary extensions.
• Monitor logs for unexpected exec calls, new process creation, or shell activity originating from PHP worker processes.
• Deploy network segmentation to isolate web servers from critical assets; enforce strict firewall rules.
• Consider hardening PHP with suhosin or similar patches to mitigate memory‑safety issues.

What to watch

Keep an eye on the PHP security team's updates; a full proof‑of‑concept may appear later, potentially revealing new attack vectors. Monitor threat intelligence feeds for indicators of compromise related to php2shell, such as specific payload signatures or command‑and‑control domains.

Watch for changes in the Elastic detection rules; new rules may be released to cover additional behaviors or to reduce false positives. Regularly test the rules against simulated attacks to ensure they trigger appropriately without flooding your alerting system.