PHP2Shell
What is PHP2Shell?
PHP2Shell is a family of memory-safety vulnerabilities in core PHP. It comprises two related vulnerability classes, tracked as two CVEs: corruption caused by out-of-memory handling, and stale global state that survives across requests.
The vulnerable code is in PHP itself. Websites can be affected even when their application code is secure, including a simple "Hello World" application running on an affected PHP version.
Sites running the latest patched PHP releases are protected. The PHP team responded to these reports with exceptional speed and professionalism, working closely with researchers to deliver comprehensive fixes.
WordPress, Drupal and Joomla were representative targets used to demonstrate unauthenticated remote code execution. Exploitation does not require one of those applications.
~70% of websites use PHP
PHP powers approximately 70% of websites
PHP is the programming language behind WordPress, Drupal and MediaWiki, the software that runs Wikipedia. Vulnerabilities in its core engine can affect websites across this ecosystem.
What attackers can do
We demonstrated remote code execution against WordPress, Drupal and Joomla using their latest container images at the time of testing. We also demonstrated application-agnostic memory disclosure.
Execute code on affected servers without authentication, potentially taking control of the server, accessing sensitive data, moving laterally, or defacing its websites.
Read sensitive PHP process memory, including passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.
Steal sensitive data through memory disclosure without first achieving remote code execution. This can make the activity harder to detect with tools focused on malicious code execution.
Common PHP software
WordPress
Moodle
Nextcloud
Laravel
Symfony
Drupal
Joomla
MediaWiki
PHP2Shell in action
- WordPressPre-authentication RCE demonstration
- DrupalPre-authentication RCE demonstration
- JoomlaPre-authentication RCE demonstration
The vulnerabilities
The research identified two related vulnerability classes in core PHP: out-of-memory corruption and stale global state across requests. They are tracked as CVE-2026-109618 and CVE-2026-109619, with severity of CVSS 9.2.
| CVE | Vulnerability | What an attacker can achieve | What we demonstrated |
|---|---|---|---|
| CVE-2026-109618 | CVE-2026-109618 Out-of-memory (OOM) corruption | Execute code without authentication as the PHP web worker | Pre-authentication RCE on WordPress, Drupal and Joomla |
| CVE-2026-109619 | CVE-2026-109619 Stale global state across requests | Trigger a use-after-free to disclose worker memory or execute code | Pre-authentication RCE on WordPress and Drupal; application-agnostic remote memory disclosure |
These vulnerability classes include multiple attack paths with different exploitation requirements and impacts. PHP-FPM RCE was confirmed through application-level code paths. The PHP team's fixes address the underlying failure patterns rather than only the demonstrated paths.
Upgrade PHP
Install a fixed PHP release on every runtime, then restart Apache, PHP-FPM and any long-running PHP workers. This is the only complete fix. Updating an application does not update the PHP runtime beneath it.
Official PHP releases are available from php.net. Downstream distributions will make corresponding package updates available through their normal update channels.
| PHP branch | Vulnerable releases | First fixed release |
|---|---|---|
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.5 | < 8.5.12 | 8.5.12 |
If you cannot upgrade immediately
Upgrading PHP is the only complete remediation. The measures below may reduce exposure to specific exploitation paths while you prepare to upgrade, but they do not address every variant.
Some measures can affect application functionality, performance or availability. Test configuration changes against your application's requirements and apply the PHP security update as soon as possible.
Setting memory_limit = -1 can prevent some attack paths that rely on PHP's memory-limit handling, but it transfers memory-exhaustion handling to the operating system. With this configuration, memory-exhausted workers may be terminated, interrupting requests and affecting stability and availability of the server. If you decide to enable this, use Linux cgroup v2 memory.max, or an equivalent operating-system mechanism, to help contain resource consumption and limit the availability impact to PHP processes. Apply configuration changes administratively and restart the affected workers.
Do not use RLIMIT_AS or RLIMIT_DATA as replacement memory limits. The PHP advisory warns that these can trigger the same vulnerable failure paths.
This measure does not cover application-specific large-allocation paths or non-memory-related triggers. In threaded deployments, terminating a process can also interrupt requests running on other threads.
- Lower
post_max_sizeto a value compatible with your application's upload requirements. This also constrains file uploads, so test legitimate upload flows. - Lower
max_input_nesting_levelwhere the application permits it. Complex forms may require a higher limit. - Set
session.upload_progress.enabled = 0if the application does not depend on upload-progress tracking.
These settings limit particular sources of memory pressure. Other attacker-controlled paths to memory exhaustion remain.
Set display_errors = 0 in production and restart the affected workers to prevent PHP error output from being exposed to remote users. This reduces an additional information-disclosure path but does not remediate the underlying vulnerabilities.
Set fatal_error_backtraces = 0 where supported and restart the affected workers. This addresses the demonstrated fatal-backtrace mechanism, but other mechanisms can still trigger the vulnerability family.
Lower PHP-FPM pm.max_requests to recycle workers more frequently. This can reduce persistence of corrupted state across requests, but it has a performance cost and does not address mechanisms that do not rely on multiple requests.
Use SELinux or AppArmor policies, where compatible with the application, to restrict worker capabilities and execution of other programs. These controls can constrain impact but should not be treated as preventing all exploitation or memory disclosure.
Hardening after upgrading
The PHP advisory describes a new hard memory limit in the fix. Reaching that limit terminates the process and prevents shutdown handlers from running. Review the operational effect on your application as part of the upgrade.
After patching:
- Review
memory_limittogether with request-size limits and expected application memory use. Revisit any temporarymemory_limit = -1setting used before the upgrade and follow the final PHP recommendations. - Keep
post_max_sizeappropriately below the configured memory budget while supporting legitimate uploads. - Limit
max_input_nesting_levelto the depth your application requires, and test complex forms. - Consider
expose_php = 0to reduce PHP version disclosure. This is optional hardening and does not remediate PHP2Shell.
These steps support application resilience after the security update. They do not replace patching.
Technical details
For technical analysis and coordinated disclosure details, read the official blog posts from the research and response teams.
Questions and answers
The research identified affected releases dating back to PHP 5.4, with nearly every PHP version affected by at least one issue before the fix. Exposure depends on the version, configuration and individual vulnerability. Check every PHP runtime against the official affected-version guidance, including runtimes serving custom applications. See Upgrade PHP for remediation.
No. These applications were representative targets used to demonstrate remote code execution. The vulnerable code is in PHP itself and can affect other applications, including a simple "Hello World" application on an affected PHP runtime.
The demonstrated remote code execution and memory-disclosure attacks did not require authentication or an application account. The requirements for individual variants differ.
PHP process memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself. Sensitive data can be disclosed without first achieving remote code execution.
Apply the PHP security update to every affected runtime and restart the relevant services and workers. The fix addresses the underlying failure pattern and its variants. Application updates alone and temporary configuration changes do not replace the PHP update.
Industry partners prepared guidance, detections and temporary mitigations for customers who cannot update immediately. Coverage depends on the provider and the exploitation path. Follow your provider's PHP2Shell guidance, but do not treat a protective rule as a substitute for updating PHP.
A single detection rule is unlikely to cover every exploitation path. Investigation signals include unexpectedly large or malformed PHPSESSID response cookies, unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and unexplained PHP worker crashes or restarts.
These signals can help guide an investigation, but they do not establish exploitation on their own. Their absence does not establish that a system is unaffected. Some attacks can disclose sensitive memory without executing malicious code on the server, and application logs may contain little context because the vulnerable paths run below the application layer.
Apply the PHP security update regardless of whether suspicious activity has been observed.
php2shell is the name we gave the combined exploit script used to demonstrate unauthenticated remote code execution on WordPress, Drupal and Joomla. PHP2Shell also names the broader research into these core PHP vulnerabilities.
Wiz Research used Wiz Atlas, Gemini 4 Argon and GPT-5.6-Sol during discovery, exploit development and patch validation. Frontier models helped work through complex exploit chains and adapt them across different deployments. Gemini 4 made a particularly significant contribution to exploit development and patch validation. See The AI inflection point.
How Wiz can help
Wiz customers can refer to the Wiz Threat Intel Center advisory for PHP2Shell for agentless and runtime vulnerability detection, exploitation detection through Wiz Defend and Sensor, automatic response policies, remediation guidance and threat hunting guidance.
Coordination and acknowledgements
Researchers from Wiz Research, OpenAI Codex Security and Calif worked with the PHP security team and the Gemini team at Google on discovery, coordination and patch verification.
Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva, Vercel and other industry partners helped prepare customer guidance, detections and temporary mitigations for organizations that could not update immediately.
Research and industry collaborators:
Wiz
PHP
Gemini team at Google
OpenAI
Calif
Google Cloud
AWS
Microsoft
Automattic
Fastly
Akamai
Imperva
Cloudflare
Vercel
Corelight
CrowdStrike
Unit 42
Cisco Talos
Get ahead of PHP2Shell
Need help identifying affected PHP environments or planning your next steps? Connect with Wiz for guidance on exposure and remediation.