A family of runtime memory safety vulnerabilities, with impacts ranging from worker crashes and data disclosure to pre-authentication remote code execution.
Introduction
Researchers from Wiz, OpenAI, and Calif jointly disclosed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a set of memory safety vulnerabilities involving PHP’s session handling, OPcache class caching, and fatal-error backtrace generation. Successful exploitation can lead to full remote code execution in the affected PHP environment without authentication or user interaction. Other demonstrated effects include worker crashes, arbitrary file reads, and server-memory disclosure.
When we think about memory-corruption vulnerabilities, we often picture bugs buried in complex application code. PHP2Shell is different: the vulnerabilities live in PHP’s own runtime, and several can be reached without the application itself doing anything wrong. In many cases, PHP2Shell exploits the timing of PHP’s response to memory exhaustion. Processing stops, but internal state is not always cleaned up consistently. Pointers or cache entries left behind can become accessible during subsequent processing, turning a failed operation into an opportunity for exploitation. In the session-related attacks the researchers demonstrated, an endpoint that does nothing more than echo “OK” can still be affected. The vulnerable processing happens before a single line of application code runs.
PHP2Shell is believed to affect PHP versions dating back to PHP 5.4.0, although not every release has been individually tested and verified. With PHP used by over 69% of websites whose server-side programming language is known, the potential exposure is substantial. Organizations should consult the relevant security advisories for confirmed affected ranges and apply vendor-provided fixes as soon as possible.
CVE Overview
PHP2Shell encompasses two reported vulnerabilities involving PHP’s handling of abnormal request termination. Both are classified as CWE-824: Access of Uninitialized Pointer, carry a CVSS v4.0 score of 9.2 (Critical), and can lead to remote code execution without authentication or user interaction.
CVE-2026-109618: Remote Code Execution via Memory Exhaustion
PHP uses longjmp() to abort request processing when an out-of-memory (OOM) error occurs. Some execution contexts do not properly account for this interruption, leaving request memory in an uninitialized state. Subsequent request cleanup may read or branch on that memory. Multiple strategies for triggering memory exhaustion can consistently reach this condition and lead to remote code execution.
Reported by: Calif, Wiz, OpenAI, and Quarkslab.
CVE-2026-109619: Remote Code Execution via Fatal Errors
PHP also uses longjmp() to abort request processing following fatal errors. Some execution contexts leave global state pointing to memory that is freed at the end of the request. Subsequent requests may read or branch on this invalid state, potentially leading to remote code execution through multiple triggering strategies.
Reported by: Wiz, Calif, and OpenAI.
It’s worth noting that the attack complexity in both vulnerabilities is high, which means that the attacker must overcome a built-in security protection for the exploit to work. Triggering the bug is much easier than turning it into code execution. Memory exhaustion can leave PHP holding a pointer to freed memory. A later request must reach the same Apache worker and place carefully shaped data into that freed space. If the timing or placement differs, the worker may crash or respond normally instead of executing a command.
The Common Thread: Bailouts Leave Stale State
PHP handles certain fatal conditions, including exceeding its configured memory_limit, through an internal mechanism known as a bailout. Rather than completing the current operation normally, PHP aborts it and transfers control to an error-handling boundary.
The problem arises when that bailout occurs after PHP has published a pointer or allocated a cache slot, but before the corresponding cleanup or completion bookkeeping runs. The result is a partially initialized, or stale, state that remains accessible after the operation has failed.
In worker-based deployments, including Apache prefork environment, a process can serve multiple requests. A subsequent request reaching the same worker may therefore encounter a pointer to memory that an earlier request has already freed.
The OPcache finding involves a related but distinct problem: an abandoned class-cache slot in shared memory. Worker-local state and shared-cache state have different lifetimes, so the conditions required to exploit each finding must be assessed separately.
Reaching the Runtime Before Application Code Runs
Three of the five demonstrated exploitation techniques use PHP’s session upload-progress feature as a remote trigger.
This feature updates session state while PHP parses a multipart request body, before the application begins executing. Crafted multipart requests can therefore influence session processing and memory consumption during this pre-application phase.
In these attacks, memory exhaustion interrupts session processing at a point where cleanup is incomplete. Later processing on the same worker encounters the stale state, resulting in a crash or memory disclosure.
This explains why an application does not necessarily need to implement vulnerable business logic to be exposed. However, it does not mean every finding affects every PHP endpoint: enabled features, application behavior, worker routing, and deployment configuration still matter.
Exploitation Techniques
Session Decoder Use-After-Free
The session decoder finding involves bookkeeping used during session unserialization. PHP makes that bookkeeping accessible through module globals, but memory exhaustion can interrupt processing before it is properly cleared.
The attack first builds a large session through the upload-progress mechanism, then forces memory exhaustion during session decoding. Request cleanup frees the underlying memory while leaving stale bookkeeping accessible.
A subsequent request reaching the same worker uses the dangling context, resulting in invalid memory access and a worker crash.
OPcache Stale Class-Cache Pointer
The OPcache finding affects the persistence of compiled class information into shared memory. A memory bailout at a particular point leaves an allocated but unpublished class-cache slot behind.
The attack manipulates later cache reuse and places crafted structures in request memory. A stale class lookup then interprets attacker-controlled data as PHP internal structures, influencing class constant resolution.
In an application flow, a file operation using the affected constant is redirected to an attacker-selected path. This produces an arbitrary file read within the worker process’s access permissions.
The practical consequences depend on what that process can read. Application configuration files, database credentials, API keys, and other secrets may be exposed, but the finding does not automatically grant access to every file on the host.
Stale Session Module-data Pointer – Use-After-Free
This finding affects the session handler state referenced by PHP’s internal pointer.
Memory exhaustion during session handling leaves the pointer referring to freed memory. A follow-up request on the same worker influences subsequent memory allocation, and PHP later dereferences the stale pointer.
Such an attack can produce a worker crash, demonstrating that invalid session state can remain reachable across requests.
Stale Session-ID Pointer – Memory Disclosure
The session ID finding follows a similar pattern but produces information disclosure rather than a crash.
After memory exhaustion leaves stale session ID state, attacker-influenced memory is interpreted as a string with an oversized length. PHP then returns the resulting value through a Set-Cookie: PHPSESSID response header.
An attack can expose approximately 67 KB of process memory. Its contents depend on the worker’s state at the time of exploitation and may include internal runtime data or sensitive information processed by the application.
Fatal-Error Backtrace – Use-After-Free
With fatal-error backtraces enabled, a fatal error can trigger a use-after-free during backtrace generation. The effect is a worker crash.
This finding should be distinguished from the session upload-progress attacks. It requires the relevant backtrace setting and a fatal-error trigger; it does not share the same remote prerequisites as the three session findings.
From Memory Corruption to Remote Code Execution
The overall impact of PHP2Shell extends beyond service disruption and data disclosure. Successful exploitation can lead to remote code execution in the affected PHP environment.
The individual findings demonstrate different ways that invalid runtime state can be accessed or influenced. Their standalone effects should be distinguished from the complete code-execution outcome.
Code execution occurs within the security context of the compromised process. It does not automatically imply root access, but it can allow an attacker to access application data, modify resources available to that process, and pursue further compromise.
Mitigation and Detection
Applying vendor-confirmed PHP fixes is the primary remediation. Organizations should consult the relevant security advisories for confirmed affected ranges, fixed releases, and vulnerability-specific guidance.
Where patching is delayed, organizations should assess temporary exposure-reduction measures:
- Disable relevant PHP features where practical. After compatibility and performance testing, consider applying the following settings in the active php.ini file. These temporary measures target features used by the demonstrated exploitation techniques and should not be treated as complete workarounds for either CVE.
- opcache.enable = 0
- session.upload_progress.enabled = 0
These settings disable OPcache and session upload-progress tracking, respectively. Disabling session upload-progress tracking removes the described trigger for three of the five reported exploitation techniques. These measures do not replace patching or establish that the environment is fully protected.
- Review fatal-error backtrace configuration. Assess whether the relevant setting is enabled and follow vulnerability-specific guidance.
- Restrict exposure where practical. Limit access to affected services while remediation is evaluated and deployed.
- Apply least privilege. Restrict the PHP process’s access to files, credentials, and connected services to reduce the consequences of compromise.
Security teams should correlate suspicious request activity with PHP memory-exhaustion errors and worker crashes. Investigation leads include unusually large multipart payloads, excessive field counts, anomalous session-related parameters, and unexpectedly large PHPSESSID response values.
If exploitation is suspected, incident response should assess possible code execution as well as data disclosure. Review unexpected child processes, application-file changes, persistence mechanisms, unusual outbound connections, and potential credential exposure.
Imperva’s Response and Customer Protection
The researchers shared vulnerability details confidentially with Imperva ahead of public disclosure, enabling Imperva to verify its protection and begin monitoring customer traffic before the announcement. During this pre-disclosure monitoring period, Imperva observed no traffic matching the monitored PHP2Shell exploit patterns.
Imperva Web Application Firewall provides a compensating control by inspecting request and response patterns associated with the demonstrated exploits, including anomalous multipart payloads, repeated session-related fields, abnormal response headers and suspicious session upload-progress activity.
Imperva WAF solutions provide a virtual patch to organizations – Cloud WAF customers are protected against this vulnerability out of the box. Elastic WAF customers receive the same protection following a software update. WAF Gateway customers are protected following a software update and an ADC security content update.
For more details, refer to the relevant release notes:
WAF GW RN V14.7 LTS: https://docs-cybersec.thalesgroup.com/bundle/v14.7-waf-release-notes/page/83979.htm
WAF GW RN V15.5 LTS: https://docs-cybersec.thalesgroup.com/bundle/v15.5-waf-release-notes/page/87153.htm
Elastic WAF 2.2.1 RN: https://docs-cybersec.thalesgroup.com/bundle/elastic-waf/page/v2-2-1.htm
Imperva provides a testing page where customers can enter their URL to receive an initial assessment. The result is preliminary and may require further analysis to confirm exposure.
Imperva’s Threat Research team continues to monitor traffic to determine whether additional protections are needed.
Conclusion
PHP2Shell highlights how a runtime’s handling of exceptional conditions can become a security boundary failure. When processing stops at the wrong moment, stale pointers and incomplete cache state can remain accessible beyond the operation that created them.
The resulting impacts range from worker crashes and sensitive data disclosure to pre-authentication remote code execution. Organizations should identify affected deployments, apply vendor-confirmed fixes, reduce unnecessary exposure, and investigate suspicious activity for signs of both data access and code execution.
The post PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment appeared first on Blog.
