PHP2Shell (CVE-2026–109618 and CVE-2026–109619): Critical PHP RCE Vulnerability and Patch Guide

Why PHP2Shell Matters

Some vulnerabilities remain hidden for years before someone discovers a reliable way to exploit them. PHP2Shell is a critical example: two PHP core vulnerabilities turned long-standing memory-management weaknesses into unauthenticated remote code execution (RCE).

Disclosed on October 21, 2026, CVE-2026–109618 and CVE-2026–109619 affect the PHP engine itself rather than a specific plugin or application. This means vulnerable PHP deployments can remain exposed even when their WordPress, Drupal, or Joomla installations are otherwise properly maintained.

The incident also highlights how AI-assisted vulnerability research can accelerate the process of turning previously difficult-to-exploit bugs into practical attack chains.

What Are CVE-2026–109618 and CVE-2026–109619?

Both vulnerabilities involve PHP memory handling when requests terminate unexpectedly, potentially leaving invalid internal state that can be exploited by subsequent requests.

The first vulnerability involves improper handling of memory after an out-of-memory condition. The second involves references to memory that has already been freed but remains accessible through stale internal state.

Together, these weaknesses can enable attackers to corrupt memory and execute code under the privileges of the PHP worker.

Which PHP Versions Are Affected?

According to the original advisory coverage, PHP releases from 5.4 through 8.5 were affected by at least one of the vulnerabilities.

The primary patched releases are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Organizations running older, end-of-life branches should check for supported vendor backports or migrate to a supported release.

PHP deployments may exist in containers, hosting environments, appliances, and applications that bundle their own runtime. Consequently, checking only the system's command-line PHP version may miss vulnerable web-facing installations.

How the PHP2Shell Exploit Chain Works

PHP2Shell involves multiple stages rather than a single request. Broadly, an attacker can trigger an abnormal request termination, exploit stale memory state, obtain information that helps overcome memory-layout protections, and use the resulting memory corruption to achieve code execution.

The chain is particularly concerning because some attack paths can operate before application-level logic executes. Apache deployments using mod_php were identified as especially exposed to the demonstrated request-startup path.

The vulnerabilities can potentially enable attackers to:

• Execute commands with the web worker's privileges
• Access application configuration and secrets
• Expose credentials, session tokens, or API keys
• Establish persistence or move toward other internal systems

The precise impact depends on the PHP configuration, server architecture, permissions, and successful exploitation path.

PHP2Shell Timeline

The disclosure and exploitation timeline demonstrates the importance of rapid vulnerability response.

• August 2026: Researchers developed and reported exploitable attack paths involving PHP memory-management weaknesses.
• October 17, 2026: Amazon's MadPot honeypots recorded the first known exploitation attempt reported in the article.
• October 20, 2026: The CVE identifiers leaked publicly, prompting emergency advisories.
• October 21, 2026: PHP released patched versions, and public proof-of-concept activity emerged.
• October 22–23, 2026: Reported scanning and exploitation attempts escalated, with researchers describing improved exploitation techniques.

This timeline reinforces a critical lesson: organizations should not wait for confirmed compromise before patching an actively targeted, critical vulnerability.

PHP2Shell Exploitation and Threat Activity

The article reports that exploitation attempts began before public disclosure and expanded rapidly after proof-of-concept code became available.

Observed activity included vulnerability scanning, attempts to deploy web shells, credential theft, and malware delivery. Some activity was associated with botnet operations, while other activity appeared more targeted.

Even when successful compromise is not confirmed, repeated probing of vulnerable systems warrants investigation. Internet-facing PHP services should be reviewed for suspicious multipart requests, unexpected worker crashes, unusual PHP session cookies, unauthorized child processes, and unexpected outbound connections.

Because the reported vulnerabilities can expose sensitive information, incident responders should also consider whether secrets need to be rotated.

How to Patch and Mitigate PHP2Shell

Upgrading to a fixed release and restarting PHP workers are the primary remediation steps. Configuration changes and web application firewall (WAF) rules can provide additional protection but should not replace patching.

Recommended actions include:

1. Upgrade PHP: Deploy a fixed release or a verified vendor-backported package.
2. Restart all workers: Restart PHP-FPM pools, Apache, and other affected services so patched code is actually loaded.
3. Verify the web-facing runtime: Check the version used by the application server, not just the CLI binary.
4. Inventory all deployments: Review virtual machines, containers, appliances, and bundled PHP installations.
5. Hunt for suspicious activity: Review logs and endpoint telemetry for signs of exploitation, credential exposure, or persistence.
6. Rotate potentially exposed secrets: Prioritize credentials accessible to vulnerable workers.
7. Apply temporary controls: Use appropriate WAF rules, restrict unnecessary exposure, and isolate systems that cannot be patched promptly.

Detecting PHP2Shell Across Your Infrastructure

Finding every vulnerable installation requires more than network scanning. PHP can be installed through operating-system packages, custom builds, containers, or vendor-managed applications.

A structured inventory should compare actual installed versions against the relevant fixed releases. Organizations can use package-management data, vulnerability scanners, software inventories, and declarative assessment standards such as OVAL to identify affected systems.

Container images should also be scanned before deployment, and running workloads should be checked separately to verify that the patched runtime is actually active.

The End of the "Too Hard to Exploit" Era

PHP2Shell demonstrates how quickly the security landscape can change when a long-standing weakness becomes practically exploitable.

The central lesson is that a vulnerability considered difficult to exploit should not be treated as harmless. AI-assisted research, public proof-of-concept code, and automated scanning can shorten the time available for defenders to respond.

Organizations should prioritize timely patching, complete asset visibility, continuous monitoring, and incident investigation. For PHP2Shell, updating the runtime, restarting workers, and investigating potential exposure are all essential parts of the response.

Read the Full Technical Analysis

For the complete PHP2Shell timeline, vulnerability details, exploitation research, and patching recommendations, read the original article on Loginsoft.

Original source: PHP2Shell (CVE-2026–109618 and CVE-2026–109619): Critical PHP RCE Vulnerability, Full Timeline, and Patch Guide