PHP2Shell: critical PHP vulnerabilities and how to patch

Two critical vulnerabilities in PHP can allow remote attackers to execute code without authentication. CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, both carry a CVSS v4.0 score of 9.2.

Patches are available. Update to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or a later release containing the fixes. If you use distribution packages, check that your vendor has patched both CVEs. PHP security announcement.

What happened

On October 21, 2026, Wiz published its PHP2Shell research following coordinated work involving Calif, OpenAI, and the PHP maintainers. The researchers demonstrated unauthenticated code execution against WordPress, Drupal, and Joomla deployments, as well as disclosure of PHP process memory. The vulnerable code is in the PHP engine, rather than those applications. Wiz disclosure.

Wiz's published timeline records the following milestones:

All dates are in 2026. Source: Wiz's disclosure timeline.

Who is affected?

Check every service that runs PHP, including hosted websites, internal applications, and containers. The research identifies affected code dating back to PHP 5.4. Running an updated CMS does not establish that the PHP runtime underneath it is patched. PHP2Shell research overview.

For supported PHP branches, the fixed versions are:

Source: PHP release announcements.

How the vulnerabilities work

CVE-2026-109618: out-of-memory corruption. A failed allocation can interrupt PHP while request data is only partially initialized. Request cleanup can then access invalid state. PHP confirmed remote code execution against Apache's mod_php, including a path that occurs before application code runs. The fix changes out-of-memory handling so shutdown no longer processes that incomplete state. PHP advisory.

CVE-2026-109619: stale global state. A PHP worker can retain references to request-owned memory after that memory has been freed. A later request handled by the same worker can access those references before initialization resets them, causing a use-after-free. Confirmed cases include fatal-error backtraces and session upload-progress handling. The patch corrects state reset across the request lifecycle. PHP advisory.

Successful attacks can run code with the PHP worker's privileges. Process-memory disclosure can also expose passwords, tokens, and API keys without first obtaining code execution. PHP2Shell research overview.

How to patch

1. Install a fixed PHP release or vendor package. Check both CVEs against your distribution's security advisory if it backports fixes.
2. Rebuild and redeploy containers. Updating the image definition does not replace containers already running.
3. Restart PHP workers. Ensure Apache or each PHP-FPM pool loads the updated runtime.
4. Verify every deployment. Include replicas, background infrastructure serving PHP requests, and sites managed by a hosting provider.

Use php -v to inspect the CLI version, but verify the runtime serving HTTP separately. A host can have multiple PHP installations, and the CLI binary may differ from Apache's module or an FPM pool.

For PHP 8.1 and older, move to a supported release or obtain a confirmed backport from your vendor. PHP also supplied minimal source backports for 7.4, 8.0, and 8.1 for users building from source. PHP security announcement.

Can configuration changes replace the patch?

No. PHP's advisories state that configuration mitigations are incomplete. A setting that blocks one confirmed path does not protect against every variant. If you cannot update immediately, apply the temporary controls documented in both upstream advisories while arranging the upgrade. Out-of-memory advisory, stale-state advisory.