PHP2Shell: affected versions, fixes, and what to do now

PHP2Shell is the name for two remote code execution bugs in PHP core, CVE-2026-109618 and CVE-2026-109619, disclosed by the PHP project on 21 October 2026. An attacker needs no account to use them. The fix is a patched PHP release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or a vendor backport, plus a restart of the PHP workers that serve your site.

Who is affected

Any website served by PHP. That is most of the web: WordPress, WooCommerce, Magento and Adobe Commerce, Shopware, Drupal, Joomla, MediaWiki, Laravel, Symfony and Craft all run on PHP. The bug sits in the engine underneath them, so the application being up to date does not help.

The PHP project is explicit that all installations serving web requests are in scope. The way the PHP is served changes how exposed you are, not whether you are:

• mod_php (Apache with PHP built in) is the highest-risk setup, because the PHP engine runs inside the web server process.
• PHP-FPM, CGI, LiteSpeed and FrankenPHP are in scope. A patched package only helps once those worker processes have been restarted or replaced.
• Sites that do not run PHP at all (static sites, Node.js, Ruby, Python, Shopify-hosted stores) are not affected by this bug. Their third-party scripts and apps are a separate question.

If you do not know whether your site runs PHP: WordPress and WooCommerce always do. For anything else, ask whoever built or hosts it, or run the free scan at the end of this page, which lists the technologies the site serves from outside.

The version trap: why "we are on 8.3" is not an answer

This is the part that catches most owners. Three things make the version number misleading:

1. Backports keep the old number. Debian, Ubuntu, Red Hat, AlmaLinux and cPanel's EasyApache ship security fixes as a new package build, not a new PHP version. Ubuntu 22.04's fixed PHP 8.1 package still reports 8.1. The only reliable check is the package changelog, which names the CVE ids.
2. php -v is the command-line PHP, not the web PHP. Many servers have several PHP builds installed. The one answering web requests can be a different binary with a different version.
3. Panels show the branch, not the build. cPanel's selector shows "8.3". It does not show whether the 8.3 package on that server includes the fix, or whether the workers restarted after it was installed.

So the question to ask, of your host or of yourself, is not "which version are we on" but: is the PHP runtime that serves web requests for this domain patched for CVE-2026-109618 and CVE-2026-109619, and have all its workers been restarted or replaced since?

How to fix it

If a host manages PHP for you (shared, managed WordPress, most VPS panels)

Send support this exact question and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP-FPM, CGI or Apache workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.

Several hosts published dated status pages. Our host-by-host pages carry what each one said and when; the short version on 22 October was that SiteGround, Hostinger's status page, Namecheap (most servers) and DreamHost's notice (most servers) reported fixes applied, Bluehost and OVHcloud's rollout reported partial or product-specific rollouts, and many others had published nothing specific. "Nothing published" means confirm with support, not "patched" and not "unpatched".

If you manage the server yourself

• Update the PHP packages from your distribution or vendor, not from a random tarball. The package changelog must list both CVE ids.
• Restart the PHP workers: php-fpm (or php8.x-fpm), or Apache if you use mod_php. On cPanel servers, use the documented service restarts for Apache and PHP-FPM rather than killing processes.
• Confirm the running web PHP, not the CLI. A phpinfo() page served through the web, or the server's own X-Powered-By header if it is on, shows the build the workers are using. Remove the phpinfo() page again afterwards.
• Rebuild and redeploy any container images that bundle PHP. A patched base image does nothing until your image is rebuilt from it and deployed.
• Check every virtual host separately if the server runs more than one PHP version.

Distribution status at our 22 October check (Debian re-checked 23 October), so you know what "update" will give you:

These rows move fast. Open the linked page before you act on a row.

Am I affected? A three-state self-test

Was anything exploited before you patched?

Attempts started before disclosure. AWS saw exploit attempts against its honeypots on 17 October, four days before the advisory, and broad attempts across its sensors once public proof-of-concept code appeared on 21 October. AWS itself says it is unclear whether the early attempts would have worked on real systems, and at our 22 October check no primary source had published a confirmed, named compromise. Neither CVE was in CISA's Known Exploited Vulnerabilities catalog on that date.

The difference between attempts and compromise is covered on its own page. That is not reassurance. It means the public record lags what attackers are doing. If your PHP was unpatched and reachable between 17 and 22 October, look for unexpected PHP files in upload directories, cron entries and scheduled tasks you did not create, new administrator accounts, and outbound connections from the web server. Patching does not remove anything that was planted before the patch.

What this bug is, without the exploit

Both CVEs are memory-safety problems in the PHP engine itself, reachable by an unauthenticated web request. CVE-2026-109618 is remote code execution via memory corruption during an out-of-memory condition. CVE-2026-109619 is remote code execution via stale global state carried between requests. The PHP project's advisories describe the conditions; we do not reproduce payloads or proof-of-concept code here, and you do not need them to fix your site. Each host and channel has its own page among the PHP2Shell guides.

Social posts about a "patch bypass" or an "8.5.13 hotfix" were not backed by any new PHP release or advisory at our last check. If that changes, the PHP changelog and advisory list linked below will show it first.

Separately, php.net's 2026 archive carries a 23 October follow-up notice naming CVE-2026-115560, with details promised for the next release. It is a different issue from the two PHP2Shell CVEs; we will add it here once the advisory is published.