Testing a PHP2Shell exploit in the era of AI-hallucinated PoCs

Intel 471 tested a public exploit for the AI-discovered PHP flaws. We found exploitation is hard, but you should still patch now.

Few vulnerabilities reach as far as PHP2Shell. CVE-2026-109618 and CVE-2026-109619 are critical memory-safety flaws in the core PHP interpreter, uncovered by researchers working with frontier AI models. PHP runs approximately 70% of websites, including platforms such as WordPress, Drupal and Joomla. PHP is also embedded in network appliances and network-attached storage (NAS) devices.

Ever since public disclosure on Oct. 21, admins have raced to patch systems before threat actors could reverse-engineer and weaponize the fixes. Several governments appeared to fear this scenario. Dutch Prime Minister Rob Jetten warned organizations to keep vulnerable systems offline until administrators deploy patches.

PHP2Shell ticks almost all our boxes (see below) for priority patching. Both flaws carry a CVSS v4.0 score of 9.2. Exploitation attempts began several days before disclosure. CISA has warned the vulnerabilities are being actively exploited in the wild. And a prolific ransomware affiliate has claimed to have a working exploit. The only risk indicator not yet met is it being productized: when it’s added to Metasploit or other tools, it can be used by unskilled actors, increasing the likelihood of mass exploitation.

AI-hallucinated POCs

The risk was that threat actors reverse-engineer PHP’s new code commit to develop an exploit for old versions and launch campaigns before admins patched. That researchers used frontier AI models to discover the bugs heightened anxieties over low-skilled actors using AI to weaponize newly disclosed vulnerabilities.

Confusion and noise ensued after disclosure. Alleged PoC PHP2Shell exploits flooded GitHub. As it turned out, many of these PoCs required a targeted web application to already contain a local file inclusion (LFI) vulnerability for exploitation. Experts dismissed the PoCs as the product of AI hallucinations.

A group of highly skilled researchers eventually produced a functioning exploit, which they also made clear only worked in specific environments.

Limited exploitation is now happening. On Oct. 26, Dream Research reported that a suspected China-linked actor chained PHP2Shell with a Linux kernel privilege escalation flaw (CVE-2026-46300) to drop a PHP root webshell on 24 firewalls in the US, Japan, Taiwan and South Korea. On Oct. 28, GreyNoise also reported the first successful exploitation in the wild in its purview.

But at the time of writing, widespread exploitation of production systems has not been confirmed. Below we provide our analysis of PHP2Shell, the results of our tests for a functional exploit, as well as mitigations and detections.

Testing a functional PHP2Shell RCE

To find out what the real risk is, Intel 471’s Vulnerability Intelligence team tested a functional open source remote code execution (RCE) PHP2Shell exploit published on GitHub. Its author, a security researcher with handle 9bie, claimed a perfect 10 out of 10 success rate. Unlike the LFI-based PoCs, this exploit incorporated a memory disclosure, a bypass of the exploit mitigation method address space layout randomization (ASLR), and memory corruption to achieve RCE.

Despite achieving RCE with this exploit, we found reliability remains an obstacle, succeeding only once in two dozen lab tests. We assess this limits its potential for mass exploitation compared with vulnerabilities such as Log4Shell. However those barriers are eroding. Here’s what we found.

PHP2Shell under the microscope

CVE-2026-109618 and CVE-2026-109619 are two critical memory-safety vulnerabilities affecting the PHP interpreter. Both arise from weaknesses in how PHP manages memory and internal state during request initialization, execution, and shutdown. Although the vulnerabilities have different root causes, successful exploitation can enable unauthenticated attackers to execute arbitrary code with the privileges of the PHP worker process or disclose sensitive process memory.

CVE-2026-109618

CVE-2026-109618 originates from PHP's handling of OOM conditions. PHP historically used “longjmp()” to abruptly terminate the current execution context when a memory allocation exceeded the configured “memory_limit”. However, this mechanism can bypass cleanup or initialization operations, leaving internal data structures in an inconsistent state, which is the root cause of this vulnerability.

The function increments “nNumUsed” and “nNumOfElements” before allocating the new entry's key. If “zend_string_init()” triggers an out-of-memory (OOM) bailout, the entry remains counted as active despite not being fully initialized. During subsequent cleanup, PHP can process this incomplete entry as valid, potentially resulting in memory corruption.

Attackers can trigger OOM conditions through specially crafted HTTP requests, including multipart requests containing excessive headers, empty upload fields with deeply nested names, or request bodies that consume significantly more memory than their transmitted size suggests. In vulnerable Apache “mod_php” environments, these operations can occur during request initialization, before application-specific PHP code executes.

CVE-2026-109619

CVE-2026-109619 is a use-after-free (UAF) vulnerability caused by PHP retaining references to request-specific memory after that memory has been released. PHP workers maintain global state for components such as sessions, error handling, and serialization. These references must be reset before the associated request memory is freed.

One demonstrated exploitation path involves PHP's session.upload_progress feature, which can initialize session-related structures during multipart request parsing, before ordinary module initialization. Calif Research identified the following operations in “php_session_rfc1867_callback()”:

These operations initialize session state and store the session identifier in worker-global state. If an OOM condition or another fatal interruption occurs before the corresponding cleanup routines execute, references to request-owned memory can remain in those globals.

PHP's request shutdown includes the following condition:

If the interruption occurs before normal module activation, the condition prevents module shutdown routines from executing. However, the request memory manager can still release the request heap, leaving worker-global session pointers referencing freed memory.

A subsequent request processed by the same worker may access the stale state before it is reset, triggering a use after free condition. By manipulating memory allocations and reclaiming the freed memory, an attacker may be able to influence the resulting operations and achieve remote code execution.

The vulnerability also affects other worker-global state. Calif demonstrated an additional exploitation path involving PHP's generic unserializer, which stores state in BG(unserialize).data which is PHP's internal way of accessing the global state used by its deserialization engine, and tracks nested operations through BG(unserialize).level. An interrupted deserialization operation can leave these variables referencing released memory, which may subsequently be reused during another request.

Although both vulnerabilities can lead to unauthenticated RCE, successful exploitation can require considerably more than triggering a PHP error. Our analysis showed several challenges, including bypassing ASLR, obtaining memory disclosures, achieving precise heap layouts, identifying PHP build-specific offsets, and managing request execution across multiple workers.

These challenges are particularly relevant to production environments where PHP configuration, loaded extensions, memory allocators, and web-server behavior vary considerably. A working exploit developed against one PHP build may not reliably function against another build running the same PHP version. Consequently, while the vulnerabilities present a critical potential impact, their real-world exploitation reliability depends heavily on the specific PHP deployment and available exploitation primitives.

Exploitability Differences Between Apache mod_php and PHP-FPM

The PHP execution environment significantly influences exploitability. In Apache deployments using mod_php, request shutdown can execute even after request initialization fails. This allows incomplete or stale internal state to be processed while the Apache worker remains available to handle subsequent requests.

PHP-FPM handles failed request initialization differently. Calif Research highlighted the following worker-exit condition in fpm_main.c:

When request initialization fails, PHP-FPM terminates the affected worker, preventing the same failed-startup state from being consumed by a subsequent request. This blocks the demonstrated application-independent startup exploitation paths.

However, PHP-FPM is not immune. Researchers demonstrated an application-dependent CVE-2026-109619 attack path where a fatal error occurs after successful initialization, allowing the worker to survive with a stale unserialization state. A subsequent request can then access that state through early session upload-progress processing.

Consequently, exploitation against PHP-FPM can require a suitable application operation, a controlled interruption, and multiple requests handled by the same worker. By comparison, demonstrated mod_php exploitation paths can operate without requiring an additional application-level vulnerability.

Putting the PHP2Shell exploit to the test

9bie’s functional PHP2Shell exploit that we tested is capable of achieving unauthenticated RCE through memory corruption, memory disclosure, and an ASLR bypass. The exploit leverages PHP's OOM handling and stale session-state behavior to disclose memory addresses and manipulate internal PHP structures, ultimately redirecting execution to PHP's system() function.

We tested this publicly available exploit in our laboratory environment and successfully reproduced unauthenticated RCE against the official “php:8.4.26-apache” Docker image running PHP 8.4.26 and Apache 2.4.69 with mod_php. Testing was performed using production PHP settings, including memory_limit=128M, display_errors=Off, post_max_size=8M, and Apache's prefork configuration supporting 150 workers. The target consisted of a basic PHP page without additional application-level vulnerabilities. We also confirmed that the Docker image and PHP library matched the exploit author's lab environment.

The exploit follows a multistage execution process. First, crafted HTTP requests trigger memory exhaustion and leave stale PHP session pointers. A subsequent memory disclosure operation leaks approximately 800 KB of process memory through an HTTP Set-Cookie header, allowing the exploit to identify heap and PHP library addresses. The exploit then manipulates internal PHP structures and redirects execution to PHP's system() function.

Successful exploitation was confirmed through the following output:

However, our testing revealed significant reliability limitations. Across approximately two dozen freshly restarted Docker containers, the complete exploitation chain succeeded only once, substantially below the exploit author's reported success rate of ten successful executions across ten tests. Most unsuccessful attempts failed during the ASLR-bypass memory disclosure stage, while several triggered Apache worker crashes.

The following Apache log entry was observed during an unsuccessful exploitation attempt:

Despite using identical PHP binaries and Docker images, exploitation reliability appeared sensitive to variations in runtime heap layouts and memory allocation behavior. Differences in the underlying host kernel, transparent huge-page configuration, and container runtime were identified as potential contributing factors, although their individual effects were not conclusively established.

These findings confirm that the public exploit can achieve unauthenticated RCE under production-like PHP configurations without requiring an additional application-level vulnerability. However, the low success rate observed during our testing demonstrates that reliable exploitation remains challenging, even against identical PHP builds. The results highlight the importance of target-specific memory conditions and support the assessment that widespread automated exploitation may remain difficult without further exploit refinement.

Threat actor activity

Intel 471 observed several actors in underground forums and messaging channels discussing the newly disclosed vulnerabilities. Several actors announced that they were looking for exploits, recruiting partners and preparing exploitation campaigns. A prolific initial access broker that works with known ransomware groups claimed to have a working exploit and invited others join their infection campaign. Others offered large payments for a working exploit and claimed to be building target lists, showing readiness to strike once exploits become widely available.

Assessment

PHP2Shell presents a significant risk, but practical exploitability varies considerably across deployments. Apache mod_php installations face the greatest demonstrated risk, while PHP-FPM exploitation can require additional application-specific conditions. The number of exposed PHP installations therefore does not reflect the number of practically exploitable systems.

We assess that the exploitation barriers described above will likely limit mass exploitation compared with vulnerabilities such as Log4Shell. Those barriers are eroding, however. The 9bie exploit already packages memory disclosure and an ASLR bypass, and although its author reported ten successes in ten tests, our single success in roughly two dozen attempts shows its reliability across environments remains unproven.

Frontier AI models add a further dimension. Wiz Research showed that AI-assisted research can accelerate the development and adaptation of complex exploits, and threat actors could use similar capabilities to troubleshoot failed attempts and adapt to target-specific memory layouts. Reliable AI-driven exploitation across diverse production environments has not yet been established, but organizations should remediate urgently rather than rely on today's exploit unreliability.

Detections and threat hunting packages

Customers can use Retroactive Threat Detection (RTD) to generate queries for indicators of compromise (IoCs) contained in the full report on Verity471. RTD queries help search historical logs for recent campaign activity associated with PHP2Shell activity. The Intel 471 Threat Hunting team has also released six hypothesis-based hunts in a new HUNTER Emerging Threats Collection for PHP2Shell RCE, which target post-exploitation activity and other behaviors observed in recent campaigns leveraging PHP2Shell for compromise.

Mitigations

Organizations are advised to prioritize the following mitigations to address CVE-2026-109618 and CVE-2026-109619:

• Apply official security updates: Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, then restart Apache, PHP-FPM and other long-running PHP worker processes.
• Upgrade unsupported PHP installations: Migrate end-of-life PHP versions to supported releases or obtain verified vendor backports, and isolate systems that cannot be updated from the public internet.
• Disable session upload progress: If immediate patching is not feasible, set session.upload_progress.enabled = Off in php.ini or server-level configuration, not through ini_set() or .user.ini, and restart worker processes.
• Adjust PHP memory limits: Consider setting memory_limit = -1 through administrator-enforced configuration, paired with operating-system or cgroup memory limits, accepting the added availability risk.
• Restrict HTTP request sizes: Reduce post_max_size to an application-appropriate value, such as 8 MB or 32 MB, with upload_max_filesize below that threshold.
• Disable fatal error backtraces: On affected PHP 8.5 installations, set fatal_error_backtraces = 0 and restart worker processes.
• Remove problematic configuration settings: Remove invalid or deprecated PHP directives that produce warnings during request initialization.
• Inventory PHP deployments: Identify PHP installations across web servers, containers, CMS platforms, control panels and third-party appliances that bundle PHP.
• Implement network-level protections: Deploy relevant web application firewall (WAF) rules and restrict unnecessary multipart POST requests as a temporary measure, not a substitute for patching.

Detections

Organizations are advised to monitor the following indicators and behaviors for potential PHP2Shell exploitation:

• Monitor suspicious child processes: Identify PHP worker processes, including “php-fpm,” “php-cgi,” “apache2” and “httpd,” spawning unexpected command shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl) or network utilities (curl, wget, nc). Investigate unexpected command execution, file downloads and outbound network connections originating from PHP processes.
• Inspect HTTP request patterns: Monitor unusually large or malformed multipart POST requests, repeated upload progress parameters such as PHP_SESSION_UPLOAD_PROGRESS, excessive form fields and requests containing abnormal multipart headers or serialized data structures. Correlate suspicious requests with subsequent server errors or worker restarts.
• Monitor PHP errors and worker behavior: Investigate abnormal increases in HTTP 500 responses, PHP OOM errors, repeated fatal errors, unexpected worker crashes and unexplained PHP-FPM or Apache process restarts. Review unusually large or malformed PHPSESSID response cookies that could indicate memory disclosure attempts.
• Analyze PHP and web server logs: Review Apache, Nginx, PHP-FPM and application logs for unusual request patterns, PHP configuration warnings, deprecated directive errors, execution timeouts and unexpected failures during initialization or shutdown. Correlate these events with suspicious source IP addresses and repeated requests targeting the same application.
• Deploy network detection signatures: Deploy Zeek and Suricata detection rules for PHP2Shell designed to identify suspicious HTTP request patterns and potentially affected PHP versions. Review corresponding WAF detections from Cloudflare and other GitHub repositories (see: https://github.com/corelight/php2shell-detect, https://blog.cloudflare.com/php-vulnerabilities-waf-protection and https://github.com/Neo23x0/process-watcher).
• Investigate known exploitation indicators: Monitor the published IP addresses, domains, malware hashes, user-agents and network fingerprints associated with PHP2Shell exploitation attempts. Correlate matches with process execution, HTTP activity and other host-level evidence before determining whether a compromise occurred.
• Monitor Apache worker crashes: During our lab testing, unsuccessful PHP2Shell exploitation attempts caused Apache workers to crash, generating the following log entry. Similar events and repeated crash logs may indicate exploitation attempts.