PHP2Shell: critical PHP flaws put WordPress, Drupal and Magento sites at risk

On 21 October 2026 the PHP project shipped emergency security releases for two critical flaws in the PHP interpreter. Researchers have nicknamed the pair "PHP2Shell". Both allow unauthenticated remote code execution: an attacker who can send an HTTP request to your site can potentially run commands on your server. No login is needed, and no plugin or module has to be vulnerable.

This is not a CMS bug. It sits underneath the CMS, so it affects WordPress, Drupal, Magento / Adobe Commerce, and any other PHP application serving web traffic. Updating WordPress core or running composer update on Drupal will not fix it. The PHP runtime on the server has to be upgraded.

Why this one is urgent

• Exploitation attempts were seen in the wild from 17 October, four days before public disclosure
• Broad, untargeted internet scanning started within hours of the patches being published
• CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October
• Every common PHP setup is affected: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed

What the vulnerabilities are

CVE-2026-109618 is a memory-handling flaw. When PHP runs out of memory part-way through inserting an entry into an internal hash table, cleanup code can later treat the half-written entry as valid data, and an attacker can steer that into code execution. CVE-2026-109619 is a use-after-free: after a fatal error, a PHP worker can reuse state left over from the previous request. One confirmed path goes through upload processing, which is reachable on default configurations via session upload progress.

Affected and fixed versions

• PHP 8.5 — fixed in 8.5.12
• PHP 8.4 — fixed in 8.4.27
• PHP 8.3 — fixed in 8.3.36
• PHP 8.2 — fixed in 8.2.35
• PHP 7.4, 8.0 and 8.1 are end-of-life. The PHP project published source backports, but most hosts will not ship them. Treat these versions as unpatched and plan an upgrade
• Linux distributions often backport fixes without changing the version number, so check your vendor's advisory rather than relying on php -v alone

What you should do right now

• Upgrade PHP on every server, container image and build pipeline that serves web traffic, then restart PHP-FPM or the web server so the new binary is actually loaded
• On shared or managed hosting, confirm with your host which PHP build your site is running and when it was patched
• If you cannot patch today, set session.upload_progress.enabled=0 (and fatal_error_backtraces=0 on PHP 8.5) as a stopgap. These reduce exposure but do not fully fix the flaws
• Check logs for "Allowed memory size … exhausted" errors ending in "Unknown on line 0", worker segfaults, and unusual multipart requests containing PHP_SESSION_UPLOAD_PROGRESS fields
• Look for shells or unexpected processes spawned by the web server user. A successful exploit can return a normal 200 response, so a quiet access log is not proof you are safe

A second, unpatched advisory

On 23 October the PHP project published a further advisory, CVE-2026-115560. It only affects applications running a non-standard configuration, and a mitigation is available, but no patch had been released at the time of writing. We are tracking it and will update this post when a fix ships.

What this means for each CMS

WordPress sites on budget shared hosting are the biggest concern. Many run whatever PHP build the host provides, and owners often have no visibility of when it was last updated. Drupal and Magento estates tend to run on dedicated infrastructure or containers. Those are easier to patch, but only if someone rebuilds and redeploys the image. A patched base image sitting unused in a registry protects nothing.

How we handled this for managed clients

Rather than wait for a maintenance window, we set our servers to run a loop that checked continuously for the fixed PHP builds. When the fixed versions were published on 21 October, our servers picked them up and installed them automatically. Managed sites were patched within seconds of the release.

No action is needed if you're on a WebsiteSupport.io managed retainer.