PHP2Shell

PHP2Shell is a family of critical vulnerabilities recently fixed in core PHP, with severity reaching CVSS 9.2, that can allow unauthenticated attackers to execute code or expose sensitive process memory. PHP powers approximately 70% of websites, including platforms such as WordPress, Drupal and Wikipedia's MediaWiki.

Research and responsible disclosure: Wiz Research — Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz; OpenAI Codex Security — Amy Burnett; Calif — Ryan A.

Help me respond

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.

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.

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.

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.

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.

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.

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.

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.

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.

These steps support application resilience after the security update. They do not replace patching.

For technical analysis and coordinated disclosure details, read the official blog posts from the research and response teams.

OpenAIRead official post

CalifRead official post

PHP FoundationRead official post

AkamaiRead official post

ImpervaRead official post

CloudflareRead official post

CorelightRead official post

CrowdStrikeRead official post

Unit 42Read official post

Cisco TalosRead official post

Questions and answers

Am I affected?

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.

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.

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.

Need help identifying affected PHP environments or planning your next steps? Connect with Wiz for guidance on exposure and remediation.