PHP2Shell: Two Pre-Authentication RCE Vulnerabilities in PHP Core with Confirmed Active Exploitation Attempts

Last reviewed: October 22, 2026.

Note: This article summarizes publicly available information and is not based on independent testing. Please refer to the linked sources to confirm the details and latest guidance.

1. Basic Information

• Article Name: Security advisory: Critical remote code execution vulnerabilities, update now
• Publisher: PHP project
• Publication Date: 2026-10-21
• Original: PHP project
• Related Sources: BleepingComputer, PHP OOM advisory, PHP stale-state advisory, Cloudflare, AWS, Wiz, CrowdStrike, Palo Alto Networks
• Related Malware: None specified
• Related Threat Groups: None specified
• Related CVEs: CVE-2026-109618, CVE-2026-109619
• Related Products: PHP 8.2, PHP 8.3, PHP 8.4, PHP 8.5, mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed, PAN-OS, Panorama
• Severity: Critical
• Update Summary: Based on public information available as of October 22, 2026, added AWS's report of pre-disclosure exploitation attempts, Wiz's demonstration of memory disclosure, CrowdStrike's descriptions of detection and protection capabilities, and the affected scope for PAN-OS and Panorama. Also clarified the conditions for the demonstrated PHP-FPM attack path, PHP's temporary mitigations, and the evidence criteria for assessing RCE and information disclosure.

2. Executive Summary

Two critical vulnerabilities in the PHP core, caused by memory exhaustion (OOM) handling and a use-after-free condition in request states, can lead to pre-authentication remote code execution (RCE) through crafted web requests. The PHP project has urged immediate updates, stating that no complete alternative mitigation exists, and Cloudflare and AWS have reported attack attempts, including activity before disclosure.

Information added in the October 22 review

• Pre-disclosure activity: AWS reports a PHP2Shell exploitation attempt in its MadPot honeypot telemetry on October 17, four days before disclosure, followed by further attempts on October 21. AWS explicitly says it is unclear whether those attempts would have succeeded against real-world systems.
• Inference: Review retained evidence back to at least October 17 where available. This is the date of AWS's observation, not a proven beginning of all activity.
• Embedded PHP: Palo Alto Networks lists PAN-OS and Panorama as affected, specifically their management HTTPS web UI and XML API. GlobalProtect portals/gateways and Captive Portal are not affected. As of the October 22 review, the advisory listed fixed versions and release estimates as pending. Follow the product-specific advisory and restrict management access; the generic PHP RCE impact should not be treated as demonstrated RCE against these appliances.

3. Attack Flow

RCE via Different Paths per CVE

Vulnerability ID	Root Cause	Source-Reported Environment and Prerequisites	Source-Reported Impact and Verification Limits
CVE-2026-109618	Cleanup after early OOM termination processes partially initialized state	RCE verified in mod_php. FPM is assessed to be affected	Achieved before application execution in mod_php. Full RCE verification in FPM is unconfirmed
CVE-2026-109619	Reuse of global state pointing to freed memory (Use-After-Free/stale-state)	RCE verified in mod_php and PHP-FPM (subsequent requests on the same worker)	Session path verified in mod_php and FPM; fatal backtrace path verified in mod_php

According to the PHP stale-state advisory, the validated FPM session path requires a suitable application operation after successful startup and a subsequent request reaching the same worker. It should not be generalized to an application-independent FPM startup exploit.

1. An attacker sends a crafted HTTP request to the target PHP server.
2. CVE-2026-109618 exploits a path where, following early termination due to an OOM condition, the cleanup mechanism treats a partially initialized state as a valid request. While RCE has been verified in a mod_php environment and PHP-FPM is assessed to be affected, a full exploit in an FPM environment remains unconfirmed.
3. Meanwhile, CVE-2026-109619 exploits conditions where state freed in a preceding request is reused by a subsequent request within the same worker before reinitialization. RCE via the session management path has been verified in both mod_php and PHP-FPM environments. For both vulnerabilities, code execution occurs with the privileges of the web worker upon success.
4. The sources reviewed here do not establish the payloads or persistence used after a successful compromise of real-world victims. Public PoCs and honeypot attempts are distinct from confirmed victim outcomes.

4. Attacker Positioning and Execution Location

• Remote attackers on the internet directly target public-facing servers where PHP processes web requests.
• In mod_php environments, the exploit has been demonstrated to succeed before the PHP code of the web application itself is executed.

5. Victim and Administrator Observations

Victims

• Regular website visitors or service users may not observe any direct signs of an attack.

Administrators

• Indications may include abnormal crashes of PHP worker processes, a sudden spike in HTTP 500 error responses, unnatural memory consumption, and the spawning of unauthorized child processes from web processes (php-fpm or httpd).

6. Success and Failure Conditions

RCE Success Conditions

• A vulnerable version of PHP processing external web requests.
• Arrival of a crafted request at the server that exploits memory corruption from OOM or stale state pointing to freed request memory to achieve code execution.

Failure Conditions and Countermeasures

PHP versions 8.1 and earlier are out of standard upstream support. Verify backports from LTS vendors or migration to a supported release series. The minimal source backports for versions 7.4, 8.0, and 8.1 provided by the PHP project do not constitute a resumption of regular support for older series.

• Update to the official patched version or a distribution-provided backported version, and restart all worker processes.
• Temporarily restrict the public attack surface and block or mitigate anomalous requests using a WAF or reverse proxy (though this is not a complete alternative mitigation).

Temporary Measures Documented by PHP

The current PHP guidance describes partial measures for installations that cannot patch immediately. Disabling session upload progress blocks confirmed session paths; disabling fatal error backtraces on PHP 8.5 addresses the confirmed backtrace path. These settings must take effect at the appropriate startup stage, and all workers must be restarted.

For the OOM issue, PHP also describes administratively enforcing memory_limit=-1. This removes a predictable PHP allocation limit, but leaves underlying allocation failures possible and removes a resource guard. It therefore needs independent resource controls and careful availability assessment. PHP warns against substituting RLIMIT_AS or RLIMIT_DATA.

These measures address specific paths only. Use the full official instructions; patching remains the complete remediation.

7. What Happens Upon Success

• Pre-authentication remote code execution (RCE) with web worker privileges (e.g., www-data).
• Wiz reports a separate research demonstration of PHP worker-memory disclosure, including secrets, without achieving RCE. This is demonstrated technical impact, not confirmation of data theft from real-world victims.
• Potential follow-on impact (inference): access to application secrets, database connection strings, or source code, and possible lateral movement, depending on the worker's permissions and reachable resources.

8. Observable Logs

Inference: The following are candidate logs to check within your own organization. They depend on logging configuration, retention periods, and monitoring scope, and are distinct from whether a source has confirmed observing each event.

• Email: None
• Proxy / SWG / DNS: Abnormally long URIs or bodies, continuous suspicious requests, and frequent HTTP 500 errors. If response headers are retained by the web server or reverse proxy, correlate unexpectedly large or malformed PHPSESSID response cookies with unusual requests or worker failures. This is an investigation signal based on Wiz research; an abnormal cookie alone does not confirm memory disclosure.
• Endpoint / EDR: Execution of shells (/bin/sh, /bin/bash) or download tools from php, apache, or php-fpm processes, along with worker crashes and core dump generation
• Identity / IdP: None
• SaaS / Cloud: WAF detection events, unexpected container restarts or scale-out events
• Network: Egress traffic from the web server to unknown external IP addresses (e.g., reverse shells)

9. Attack Success Determination

The following are assessment criteria for your own organization. These are evidence categories, not a required linear sequence. Memory disclosure can be confirmed without RCE; absence of a suspicious child process does not establish absence of impact.

• Attack Attempt Observed (Success Unconfirmed) (contact_only): Criteria: The arrival of exploit-like suspicious requests at a vulnerable server does not constitute confirmed attack success.
• Initial Execution Confirmed (initial_execution): Criteria: Verify differences from normal application behavior, supported by execution results of arbitrary commands or the establishment of an unauthorized reverse shell corresponding to the attack request. Process crashes, file downloads, or temporary file creation alone do not constitute confirmed RCE success.
• Data or Session Compromise Confirmed (data_or_session_compromise; memory disclosure): Criteria: Evidence that an unauthorized response exposed data from PHP worker memory outside the requester's legitimate context. An abnormal response or cookie alone is insufficient; preserve sensitive evidence securely and assess exposure without requiring a shell or child-process event.
• Follow-on Compromise Confirmed (follow_on_compromise): Criteria: Confirm subsequent stages such as the creation of new accounts, unauthorized use of credentials, persistence, lateral movement, or unauthorized database queries.

10. Investigation Playbook

• Trigger: Detection of a vulnerable PHP version, WAF alerts for exploit attempts, or abnormal termination of PHP worker processes
• Initial Review: Verify the running version, SAPI configuration, package source, and process restart time, and preserve the timeline of web access logs and process executions
• Endpoints: Check parent-child process relationships, creation of suspicious files, core dumps, and unauthorized modifications under the webroot
• Identity and Cloud: Check usage history of application secrets stored in environment variables or cloud credentials
• Follow-up Actions: Check for external egress traffic, credential access, lateral movement attempts, and suspicious data queries
• Containment: Apply patches and restart all workers, restrict public access, and rotate potentially compromised secrets
• Classification: Record patch status separately from observed outcomes: Attempt Only / Memory Disclosure Confirmed / RCE Achieved / Follow-on Compromise Confirmed. Multiple outcomes may apply.

11. Defense and Detection Ideas

• Single Event: Shell execution originating from a web server process (php/apache/php-fpm), or abnormal worker crashes in a short time window
• Timeline Correlation: A candidate RCE sequence is an abnormal HTTP request -> HTTP 500 response/crash -> child process execution -> outbound communication. This is not a mandatory sequence; investigate memory-disclosure evidence separately.
• Hunting Perspective: Retroactively search the pre-patch period for suspicious requests, responses, and process activity. Given AWS's October 17 observation, include retained evidence from at least that date where available; do not use public disclosure as the earliest possible attack date.
• Log Gaps: Because some demonstrated paths in mod_php achieve execution before application code runs, web application logs alone may be insufficient for detection (note that not all SAPIs and paths occur before application execution)
• Priority Actions: Prompt patching and process restart, ensuring EDR monitoring coverage, and implementing WAF and egress traffic controls

Vendor-Reported Detection and Protection

CrowdStrike's October 21 blog describes three distinct capabilities:

Capability	What the vendor reports
Falcon behavioral IOAs	Detection and prevention of common post-exploitation behavior, including web shells, suspicious children of PHP/web-server processes, and malicious commands.
Falcon Exposure Management	Identification of vulnerable PHP installations and downstream package fixes. Additional discovery of custom installations has sensor-version requirements described in the blog.
Falcon Next-Gen SIEM	An Emerging Threat Response dashboard and a correlation template for startup-phase PHP memory exhaustion in web-server error logs, including the Unknown on line 0 marker.

Inference: Finding a vulnerable PHP installation, observing an out-of-memory error, and detecting suspicious process or command execution are different findings. A startup OOM alert alone does not establish that RCE succeeded. The descriptions above reflect CrowdStrike's statements and do not show that every attack variant can be detected or blocked.

Before using these capabilities, check:

• Whether the products you have licensed and deployed include the capabilities you plan to use.
• Whether the required detection and protection features are enabled.
• Whether your deployed sensor supports the relevant capability.
• For SIEM-based detection, whether the required web-server logs are being ingested.

PHP patches are still required even when these detection and protection capabilities are in use.

Cloudflare also describes WAF protections that combine request and response signals and may block a matching origin response.

Inference: Blocking a response does not by itself establish that the origin never processed the request or that no earlier compromise occurred.

12. Facts, Inference, and Hypothesis

Facts

• The PHP project published two vulnerabilities with a CVSS v4.0 score of 9.2 (Critical).
• CVE-2026-109618 involves the cleanup mechanism incorrectly recognizing and processing partially initialized data from OOM handling as valid request data.
• CVE-2026-109619 involves the reuse of global state pointing to freed memory in subsequent requests (Use-After-Free).
• The patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and it is stated that no complete alternative mitigation exists.
• Cloudflare reported observing attack traffic targeting PHP2Shell and payload variations attempting to bypass WAFs (this is not a report of successful compromise counts).
• AWS reported a pre-disclosure MadPot exploitation attempt on October 17; whether the observed attempts would succeed against real-world systems remains unconfirmed in that report.

Inference

• Priority asset inventory and prompt updates are required across all PHP environments processing external web requests. However, the paths exploitable for each CVE depend on SAPI configurations, settings, and application behavior, meaning the exact same exploit does not uniformly succeed across all configurations.

Hypothesis

No additional hypotheses. Unconfirmed items are noted under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Pre-authentication exploit targeting a public-facing PHP runtime.

14. Open Questions and Further Investigation

• The reviewed sources do not establish the number of real-world victims with successful RCE or memory disclosure, the responsible threat actors, or the post-compromise payloads. Research demonstrations, honeypot observations, and vendor protection claims should be kept distinct.
• Specific version numbers for backported packages in each Linux distribution require individual verification with the respective vendor.

15. Impact on SOCs and Organizations

Organizations operating public-facing PHP services should not rely solely on detection and protection from WAFs, EDR, or other security products as a permanent fix; the PHP fixes still need to be applied. Check the PHP version in use, how PHP is run (such as PHP-FPM or as an Apache module), and the fix information from your PHP or package provider. After updating, follow the provider's instructions for any required service restarts or other steps, and confirm that the PHP processes handling actual web requests are running the patched code. Investigate possible information disclosure as well as evidence of RCE.

16. Summary by Role

• For SOCs: Correlate PHP worker crashes, anomalous HTTP requests and responses, and suspicious child processes. Include the pre-disclosure period in retrospective review and assess possible memory disclosure even when RCE is unconfirmed.
• For Administrators: Immediately update to 8.5.12, 8.4.27, 8.3.36, 8.2.35, or vendor-provided backports, and ensure PHP-related worker processes are restarted.
• For Users: Follow instructions if notified of updates by the administrators of the services you use, and take action only if prompted to reset credentials.