PHP2Shell: Two Critical PHP RCE Flaws Leaked Before Patch

PHP2Shell is the nickname researchers gave two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, that PHP will patch in an emergency release at 14:00 UTC on October 21, 2026. PHP rates each one 9.2 on CVSS v4.0, and watchTowr says both allow remote code execution.

The patch isn't out yet. This post reflects what was public around 12:00 UTC, about two hours before the scheduled release, so the fixed versions are still pending.

Key Takeaways

• PHP's own notice confirms three things: two critical flaws, a 9.2 CVSS v4.0 score for each, and a release at 14:00 UTC on October 21.
• The CVE IDs, the remote code execution label, and the PHP 5-and-up scope come from a leak and from researchers. PHP hasn't confirmed them.
• Only PHP 8.2 through 8.5 can receive a fix. Older branches are end of life and get no vendor patch.
• No workaround has been published, and reports about active exploitation conflict.
• Inventory every PHP install now, and be ready to upgrade internet-facing systems first when the release lands.

What do we actually know about PHP2Shell?

Less than the headlines suggest. PHP's advance notice from October 20 says a security release is coming on Wednesday, October 21 at 14:00 UTC. It fixes two critical vulnerabilities, each scored 9.2 on CVSS v4.0. PHP says the release itself will carry the full details, the affected versions, and the fixed versions, and that it may ship earlier if details leak or attacks begin.

Everything else is secondhand. PHP's notice doesn't name the CVE IDs or call the flaws remote code execution. The IDs appeared in the leaked post, and researchers and vendors such as Huntress and Tenable use them. watchTowr says both flaws allow remote code execution and that it believes it reproduced CVE-2026-109618, but it hasn't released technical details. The PHP2Shell name is the researchers' too, not PHP's.

It matters because reports place the flaws in PHP itself rather than in one app built on top of it. PHP runs underneath WordPress, Drupal, Joomla, Magento, shared hosting, and control panels, and Huntress points out that it also hides inside vendor software that never mentions PHP.

How did PHP2Shell leak before the patch?

A Hacker News post on October 20 claimed two critical PHP remote code execution flaws would be disclosed on Thursday, October 22. The post was deleted, but screenshots spread. watchTowr then said on X that the leak was real and that the flaws had been under embargo until Thursday at 11 am ET. PHP published its advance notice that evening and moved the release up by a day.

What leaked was the existence of the bugs, a score, a date, and the CVE IDs. It didn't explain how the flaws work. The 10.0 CVSS figure circulating online doesn't match PHP's own 9.2 rating on CVSS v4.0. Huntress also notes that a short exploitation video appeared briefly and was taken down.

Which PHP versions are affected?

Nobody has confirmed that yet. The leaked post and watchTowr's CEO pointed to PHP 5 through 8. But watchTowr's own FAQ says no vendor advisory has confirmed that scope, and no configuration or feature requirement has been described.

What's already settled is who can get a fix. PHP only patches its supported branches, so only these four can receive one (current releases and support dates as reported by The Hacker News):

• PHP 8.5: currently 8.5.11, active support until December 31, 2027
• PHP 8.4: currently 8.4.26, active support until December 31, 2026
• PHP 8.3: currently 8.3.35, security fixes only until December 31, 2027
• PHP 8.2: currently 8.2.34, security fixes only until December 31, 2026

PHP 8.1, 8.0, 7.x, and 5.x are end of life. If the flaws reach those branches, those installs have no vendor patch to wait for. Mallory counted about 884,000 internet-facing hosts whose banners reported PHP 8.1 or older on October 20, around 59% of the 1.5 million hosts that reported a version at all. Banners aren't proof of exposure, and another 740,000 hosts reported PHP without a version.

Is anyone exploiting PHP2Shell yet?

Reports conflict, and none comes with evidence you can check. Huntress said it hadn't seen exploitation in its partner environments as of October 20 and knew of no public exploit code. watchTowr's FAQ listed no reported exploitation as of October 21 and noted the flaws weren't in CISA's Known Exploited Vulnerabilities catalog.

Later on October 21 the picture changed. Patchstack posted an update timestamped 07:34 UTC saying it had confirmed multiple active exploitation incidents, without saying how. Sansec's timeline separately lists Cloudflare reporting early attacks and deploying WAF rules at 07:43 UTC. We couldn't verify either claim against a primary source, and with no technical details public there's nothing independent to check them against.

The safe assumption is that attackers will move fast once the patch ships. Huntress expects technical details and proof-of-concept code to follow quickly, and The Hacker News notes that exploit attempts against a 2024 PHP CGI flaw, CVE-2024-4577, showed up on Akamai's honeypots within 24 hours of it going public.

What should you do before the patch lands?

PHP has published no workaround, so preparation is mostly inventory. These steps draw on Huntress's rapid-response post and CERT-EU's advisory.

1. Inventory every PHP install. Include PHP bundled into vendor appliances and Windows software, and control panels like cPanel and Plesk.
2. Plan to upgrade at 14:00 UTC, which is 10:00 AM Eastern. Patch internet-facing systems first, and check whether your Linux distribution or hosting provider ships backported packages.
3. Restart PHP-FPM or the web server after upgrading so running workers load the new build.
4. For end-of-life PHP, upgrade, take the system off the internet, or put it behind a VPN or WAF until you can. CERT-EU's advice when patching isn't possible is to consider isolating internet-facing applications from public networks until a fix is available.
5. Watch what PHP launches. Alert when php-fpm, php-cgi, httpd, or apache2 starts a shell, an interpreter, or a download tool. On Linux servers without endpoint detection, Florian Roth's process-watcher logs every program a PHP process starts. It only observes and blocks nothing.
6. If you find something, isolate the server, preserve the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs or scheduled tasks, and new accounts.

To start the inventory on a Linux server, these list what's installed and running:

php -v
which -a php php-cgi php-fpm
ps -eo comm | grep -E 'php-fpm|php-cgi|apache2|httpd' | sort | uniq -c

The php -v command reports the CLI binary, which can differ from the one your web server runs, and FPM binary and service names vary by distro. These commands only show what's present. They can't tell you whether a build is vulnerable, because PHP hasn't said which ones are.

Wrapping Up

PHP2Shell is a patch-today story with almost no confirmed technical detail, so the useful work today is knowing where your PHP runs. When 14:00 UTC passes, read PHP's news page for the fixed versions and patch internet-facing servers first. Anything on PHP 8.1 or older needs an upgrade or isolation regardless of how the scope question resolves.

Sources

• PHP.net: Upcoming Critical PHP Security Release
• Huntress: Rapid Response, php2shell
• The Hacker News: PHP2Shell, Two Unpatched Critical PHP RCE Flaws
• BleepingComputer: PHP warns admins of two critical flaws
• watchTowr: PHP Remote Code Execution FAQ
• CERT-EU: Security Advisory 2026-018
• Patchstack: Major security alert, PHP vulnerable to critical RCE
• Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619