PHP2Shell: what it is and how to fix it

Information checked on 22 October 2026. PHP2Shell refers to two critical vulnerabilities in the PHP runtime, with security updates released on 21 October. Under certain conditions, an attacker without an application account can execute code with the PHP process’s privileges. The issue concerns the infrastructure running the application, including WordPress sites and custom software.

The primary fix is to install a patched PHP package and restart the affected processes. Updating WordPress, plugins or Composer dependencies does not replace the runtime update. See the official PHP announcement.

What PHP2Shell affects

• CVE-2026-109618: out-of-memory handling can leave internal data only partly initialized. Later processing of that invalid data can enable code execution. See the PHP OOM corruption advisory.

• CVE-2026-109619: a reused worker can retain references to memory freed after a request. A later request can act on that stale state. See the stale global state advisory.

An attack running before application code was demonstrated against Apache with mod_php. PHP-FPM and other deployment modes also require assessment; a login screen or framework is not evidence of protection. Individual variants have different prerequisites.

Which PHP versions contain the fixes?

The first patched releases published by the PHP project for supported branches are:

• PHP 8.2: 8.2.35

• PHP 8.3: 8.3.36

• PHP 8.4: 8.4.27

• PHP 8.5: 8.5.12

Use these releases or a later patched release in the relevant branch. For PHP 8.1 and older, check whether your vendor supplies a backport and plan migration to a supported branch. A targeted backport does not restore support from the PHP project.

The package revision matters. A distribution may backport the fix without changing the base version number. Ubuntu 24.04, for example, lists 8.3.6-0ubuntu0.24.04.13 as patched. Compare the full package version with USN-8948-1.

Check the runtime actually serving your site

php -v
php --ini

These commands identify the command-line interpreter and its configuration. Your website may use a different binary, version or ini file. Check the domain’s PHP-FPM pool, Apache module or container service as well. Do not publish a phpinfo() page to obtain this information.

Include subdomains, staging environments and every instance in the inventory. Record each runtime’s full package version, update source and restarted service.

Apply the fix for your hosting environment

Managed hosting or cPanel

Ask the provider to confirm fixes for both CVEs and the restart of affected processes. Selecting “PHP 8.4” in a control panel does not prove patch installation. cPanel tracks updates for its internal PHP and EasyApache separately; consult the official cPanel bulletin.

A server you administer

Check your backup and application compatibility, then install updates from the appropriate package source. For an Ubuntu server managed through APT, Canonical recommends:

sudo apt update
sudo apt upgrade

Restart the service using PHP: for example, php8.3-fpm for that pool or apache2 with mod_php. Service names depend on the installation. Follow Canonical’s instructions; APT commands are not a universal procedure for cPanel servers.

Docker containers

Update to a patched PHP image, rebuild custom images and redeploy the services. Restarting an old container keeps its old image. Compose pull downloads images; Compose up can recreate services using a changed image. Check every replica.

Temporary measures and verification

WAF rules and request restrictions can reduce particular attack paths. They do not confirm remediation of the PHP runtime. The temporary memory_limit = -1 recommendation has a real trade-off: removing PHP’s limit can affect availability unless resources are controlled separately. Do not apply it automatically; follow the research team’s guidance and prioritise patching.

After updating, confirm the package serving the site and process restarts. Test login, uploads and essential application flows. Review logs and unexpected changes. Patching does not remove files or persistent access left by an earlier compromise.

If you suspect compromise, preserve evidence, contain exposure and arrange an incident investigation. Recovery may require rebuilding from a verified source and replacing exposed credentials after containment.

For help with runtime inventories, updates or post-maintenance checks, see Nikba’s support, security and infrastructure services. For application maintenance, read our WordPress optimisation guide.