PHP2Shell is a set of critical vulnerabilities in the PHP runtime that can allow unauthenticated attackers to execute arbitrary code on vulnerable servers or disclose sensitive process memory. Tracked as CVE-2026-109618 and CVE-2026-109619, these vulnerabilities expose weaknesses in PHP’s memory management, fatal-error handling, and internal state cleanup.
Unlike conventional web application vulnerabilities, PHP2Shell does not necessarily require a flaw in an application’s own code. The underlying issues exist within the PHP engine itself, potentially affecting websites and services that rely on vulnerable PHP deployments.
The research published by Calif and Wiz Research demonstrates how these long-standing implementation flaws can be combined into practical exploit chains targeting widely used PHP applications.
Overview
The vulnerabilities affect PHP’s handling of memory and internal state when a request encounters a fatal error, particularly an out-of-memory (OOM) condition. Under certain circumstances, PHP may fail to properly clean up internal data structures before releasing request memory.
When a subsequent operation reuses the affected state, stale pointers and corrupted data structures can lead to memory disclosure or memory corruption. Researchers demonstrated that these primitives can be chained into remote code execution (RCE).
According to Wiz Research, the reported issues affect PHP versions dating back to PHP 5.4.0, with nearly every PHP version affected by at least one of the underlying issues.
Key findings include:
- Unauthenticated remote code execution: Exploitation can be possible before application-level authentication.
- Sensitive memory disclosure: Process memory may expose passwords, authentication tokens, API keys, certificates, and other sensitive information.
- Application-independent exposure: The vulnerability resides in PHP itself, so vulnerable deployments are not limited to a particular CMS or framework.
- Long-standing implementation flaws: Some of the underlying weaknesses have existed in the PHP codebase for more than a decade.
- Exploit development accelerated by AI: Researchers used AI-assisted analysis and iterative testing to develop and adapt complex exploit chains.
Wiz Research reported a maximum severity score of CVSS 9.2 for the disclosed vulnerability set.
Understanding CVE-2026-109618 and CVE-2026-109619
The two CVEs group multiple exploitable weaknesses involving PHP’s internal memory management and state handling.
CVE-2026-109618: Upload-Progress Unserializer Use-After-Free
CVE-2026-109618 includes a use-after-free vulnerability involving PHP’s Session upload-progress functionality and unserialization state. The associated research also demonstrates remote process-memory disclosure.
A use-after-free occurs when software continues to access memory after that memory has already been released. The memory may subsequently be reused for unrelated data, causing the program to interpret stale or attacker-influenced contents as valid objects.
In the reported PHP vulnerability, request processing can initialize internal Session or unserializer state before all normal module initialization and cleanup mechanisms are active. If a fatal allocation error interrupts processing, PHP may release the request heap while leaving references to that memory in persistent worker state.
A later request handled by the same worker can then encounter the stale references. Depending on the affected execution path, this can expose process memory or provide primitives for corrupting memory and executing code.
The upload-progress mechanism is particularly relevant because PHP can process multipart form data and initialize related Session state before the application script executes. Consequently, an application does not necessarily need to explicitly call session_start() for the memory-disclosure issue described by Wiz Research to be relevant.
Wiz demonstrated unauthenticated remote code execution chains involving WordPress, Drupal, and Joomla, alongside application-independent disclosure of PHP worker memory.
CVE-2026-109619: Fatal-Error Backtrace Use-After-Free and OPcache Type Confusion
CVE-2026-109619 groups additional weaknesses involving fatal-error backtrace handling and OPcache’s shared runtime state.
The first issue concerns PHP’s handling of fatal-error backtraces. Under affected conditions, PHP can retain a reference to backtrace data allocated in request memory even after a fatal error causes that memory to be released.
If the worker subsequently accesses or updates the stale reference, the resulting use-after-free can lead to memory corruption. Researchers demonstrated that this primitive could be developed into an unauthenticated RCE chain against Drupal.
The second issue involves OPcache, PHP’s bytecode caching mechanism. OPcache can persist compiled PHP structures in shared memory so that workers can reuse cached code.
During this process, PHP maintains runtime-pointer mappings and shared metadata. An allocation failure at a particular point can leave these structures inconsistent: process-local state may advance even though the corresponding shared state has not been fully updated.
When another worker later reuses an affected slot, stale metadata can resolve to an object of an unexpected type. This type confusion can corrupt shared OPcache state and become part of an RCE chain.
Wiz Research demonstrated an unauthenticated RCE chain against WordPress using this primitive.
Together, these findings show that PHP2Shell is not a single isolated coding mistake. It involves multiple failure paths in which incomplete cleanup, stale pointers, and inconsistent internal state can become security-critical.
Why Out-of-Memory Errors Can Become Security Vulnerabilities
Memory exhaustion is commonly associated with denial of service. However, PHP2Shell demonstrates that an out-of-memory condition can have more serious consequences when it interrupts native code at a sensitive point.
PHP uses internal allocation and cleanup mechanisms to manage request data, hash tables, serialized values, and other runtime structures. These structures must remain consistent throughout their lifecycle.
If an allocation fails after a data structure has been partially published but before initialization is complete, subsequent cleanup code may treat incomplete data as valid.
This can create a dangerous sequence:
- PHP begins allocating or initializing an internal data structure.
- A memory allocation fails and triggers a fatal error.
- Normal initialization, rollback, or cleanup is interrupted.
- Request memory is released while some references remain.
- A later operation accesses the stale state.
- The resulting memory disclosure or corruption may be leveraged for further exploitation.
The critical issue is not simply that memory has been exhausted. It is that the interpreter may continue operating with inconsistent internal state after the error.
The exact exploitation path depends on the PHP version, server API (SAPI), configuration, and application behavior. Calif’s research describes several distinct paths, including differences between Apache’s mod_php and PHP-FPM.
Affected Applications and Potential Impact
Because the vulnerable components are part of PHP itself, applications can be exposed even when their own source code does not contain the underlying flaw.
Wiz Research demonstrated remote code execution against the following applications:
- WordPress
- Drupal
- Joomla
Calif additionally reports successful pre-authentication RCE demonstrations involving:
- MediaWiki
- Roundcube
- Magento
- phpMyAdmin
- Nextcloud
- Laravel
- Symfony
- WHMCS
These demonstrations illustrate the breadth of the potential impact. They should not be interpreted as meaning that every installation of these applications is automatically exploitable. Actual exposure depends on the PHP version, server configuration, execution environment, and availability of the relevant exploitation path.
The potential consequences include:
Remote code execution: An attacker may execute code with the privileges available to the vulnerable PHP process, potentially gaining access to application files, environment variables, database credentials, or other server resources.
Sensitive information disclosure: Process memory may contain secrets belonging to the application or other requests handled by the same worker, including authentication tokens and API keys.
Cross-request and cross-worker impact: Some exploitation paths involve state that survives beyond an individual request or shared structures used by multiple workers.
Broader infrastructure exposure: Since PHP is widely deployed across web hosting environments, CMS platforms, frameworks, and custom applications, a vulnerability in the runtime can have a much wider impact than an application-specific bug.
The Role of AI in PHP2Shell
One of the most notable aspects of the PHP2Shell research is the role of artificial intelligence in vulnerability discovery and exploit development.
The underlying weaknesses were difficult to exploit because successful exploitation required more than identifying a vulnerable memory-management operation. Researchers needed to chain multiple primitives, understand PHP’s internal allocation behavior, account for worker lifecycle differences, and repeatedly adapt their approach to different application environments.
Wiz Research describes using AI-assisted source-code analysis, testing, and debugging to identify weaknesses and develop working exploit chains.
AI helped researchers examine complex code paths, generalize patterns across related bugs, and iterate on exploit reliability. This reduced the amount of manual work required to adapt exploitation techniques to different PHP versions and runtime configurations.
The implications extend beyond PHP. Vulnerabilities that were previously considered difficult to exploit because of their complexity may become more practical as AI-assisted research improves.
However, AI does not eliminate the need for technical expertise, validation, or environment-specific testing. The significance of PHP2Shell is that AI-assisted workflows can make sophisticated vulnerability research and exploit development substantially more efficient.
The same capabilities can also help defenders identify related flaws, validate fixes, and develop detection strategies.
Conclusion
PHP2Shell highlights the security risks that can emerge when a programming language’s core runtime fails to recover safely from fatal errors. CVE-2026-109618 and CVE-2026-109619 encompass multiple memory-safety issues that can expose process memory or enable unauthenticated remote code execution under affected conditions.
The impact is particularly significant because the vulnerable logic resides in PHP itself, potentially reaching CMS platforms, frameworks, and custom applications without requiring a separate vulnerability in each application’s code.
The research also demonstrates how AI-assisted security analysis can make complex vulnerability discovery and exploit development more practical, reinforcing the need for timely patching and proactive vulnerability management.
For defenders, the priority is clear: identify affected PHP deployments, apply the official security fixes, investigate suspicious activity, and avoid relying exclusively on application-level protections.
References
About The Author
Leave a Reply