PHP2Shell 披露 PHP 核心 CVSS 9.2 漏洞及修复版本

AI uncovers critical vulnerabilities in the backbone of the web

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.

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

• 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.

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.

PHP2Shell in action

Watch PHP2Shell automatically identify each application and demonstrate pre-authentication command execution in controlled test environments.

• 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.

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.

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.

Consider disabling PHP's finite memory limit

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.

Reduce attacker-controlled memory pressure

• Lower post_max_size to a value compatible with your application's upload requirements. This also constrains file uploads, so test legitimate upload flows.
• Lower max_input_nesting_level where the application permits it. Complex forms may require a higher limit.
• Set session.upload_progress.enabled = 0 if 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.

Disable PHP error display

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.

Disable fatal-error backtraces where applicable

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.

Reduce worker reuse

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.

Constrain the impact of exploitation

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_limit together with request-size limits and expected application memory use. Revisit any temporary memory_limit = -1 setting used before the upgrade and follow the final PHP recommendations.
• Keep post_max_size appropriately below the configured memory budget while supporting legitimate uploads.
• Limit max_input_nesting_level to the depth your application requires, and test complex forms.
• Consider expose_php = 0 to 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.

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.

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.