PHP2Shell (CVE-2026-109618 & CVE-2026-109619): What Site Owners Must Do Now

By Glenn Lyvers · Updated October 24, 2026 · 6 min read

If your website runs on PHP — and that includes every WordPress, Joomla, Drupal, Magento, WooCommerce and Laravel site — you need to act on this one today. PHP2Shell is the name given to two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. They were disclosed and patched on October 21, 2026, and both carry a CVSS v4.0 score of 9.2.

This is not a bad plugin or an outdated theme. The flaw is in the language your site is written in, so it does not matter how carefully you have kept WordPress updated. If the PHP on your server is not patched, your site is exposed.

What PHP2Shell actually does

Both flaws give an attacker remote code execution: the ability to run their own commands on your web server. No login is required. Published research describes a single unauthenticated web request triggering the attack before any of your site’s own code even runs, which means security plugins, login limits and two-factor authentication on your admin page do nothing to stop it.

• CVE-2026-109618 is memory corruption triggered when PHP runs out of memory partway through setting up a request. The cleanup code then treats half-built data as valid.
• CVE-2026-109619 is stale global state: internal data from one request survives after its memory is freed, and the next request handled by the same PHP worker can act on it.

Once code is running as your web server’s user, an attacker can read wp-config.php and your database password, plant backdoors, inject spam or redirects, and use your server to attack others. That is the same end state as a full site hack.

Affected and fixed PHP versions

Every PHP installation that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed and FrankenPHP. Researchers single out Apache mod_php as the highest-risk setup.

One trap: Linux distributions and many hosts ship the fix as a backport, so the version number may not change. A patched Ubuntu or CloudLinux build can still report an older version. My guide on checking whether you are vulnerable shows how to tell the difference.

Is it being exploited?

Yes, attempts are already happening. Amazon’s threat intelligence team recorded a PHP2Shell exploitation attempt on October 17, four days before public disclosure, which means details leaked early. The security firm watchTowr reports exploitation in the wild through its honeypot network, and working exploit code is circulating. Some government advisories had not yet confirmed active exploitation at the time they were written, but attackers move quickly on bugs like this, and automated scanners will try every PHP site they can reach.

Security researchers have called these among the most severe PHP flaws ever found. With tens of millions of PHP sites online, many on old or neglected servers, a wave of compromised sites is likely over the coming weeks.

What you should do today

1. Find out which PHP your site actually runs. Not what your host’s marketing page says, and not what the command line reports: the version serving web requests.
2. Upgrade to a fixed release (or a confirmed vendor-patched build), then restart every PHP worker. A patch that is installed but not loaded protects nothing. The step-by-step is in how to upgrade PHP for PHP2Shell.
3. Check whether you were already hit. Patching closes the door; it does not remove anyone who came through it. See signs your site was compromised through PHP2Shell.
4. If you cannot patch right away, put the site behind Cloudflare (which has deployed WAF rules for the known exploit paths, including on free plans) or take it offline. The UK’s NCSC advises considering taking unpatchable systems offline.

Can a setting fix it instead?

No. PHP’s own advisory says no configuration change fully mitigates these flaws. Firewall rules block the exploit paths researchers know about, which buys time, but they are not a fix. The only real fix is a patched PHP build, loaded and running.

What if I am on shared hosting?

Most shared hosts patch the server for you, but not always on the same day, and many accounts are pinned to an old PHP version that the host will not patch at all. If your control panel offers PHP 7.4 or 8.0 and your site is still set to it, you may be running an unfixed build even though the host has patched newer versions. Check, and if your site is on an old branch, move it to a patched one.

If this is more than you want to handle yourself, I’ll do it for you. My emergency PHP2Shell upgrade is a flat $195. I’m doing a lot of these right now, but same-day service is still likely.

Common questions

What is PHP2Shell?

PHP2Shell is the name for two critical remote code execution flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. They let an attacker run commands on a PHP web server without logging in, and they affect WordPress, Joomla, Drupal, Magento and any other PHP site whose server is not patched.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fix. PHP 7.4, 8.0 and 8.1 have no official release, only vendor backports or source patches, and PHP 7.3 and older have no fix at all.

Does updating WordPress protect me from PHP2Shell?

No. The flaw is in PHP, the language WordPress runs on, not in WordPress, a plugin or a theme. A fully updated WordPress site is still exposed if the server’s PHP is not patched.

Is PHP2Shell being exploited?

Exploitation attempts have been reported. Amazon recorded one on October 17, 2026, before public disclosure, and watchTowr reports exploitation in the wild. Working exploit code is circulating, so assume automated attacks will reach any unpatched PHP site.

Can I mitigate PHP2Shell without upgrading?

Only partly. PHP says no configuration change fully mitigates the flaws. Cloudflare’s WAF rules block the known exploit paths and buy time, but the real fix is running a patched PHP build and restarting every PHP worker.