PHP2Shell Critical PHP RCE Flaws: What to Patch and How to Prepare

PHP is shipping an out-of-cycle security release for two critical remote code execution (RCE) flaws, each rated 9.2 on CVSS v4.0. Researchers are calling the pair "PHP2Shell." According to the PHP security team's notice, the release is scheduled for Wednesday, October 21, 2026 at 14:00 UTC. Fixes will cover only the supported branches (8.2, 8.3, 8.4 and 8.5), so PHP 8.1 and older get nothing. If you run PHP anywhere that faces the internet, your job today is to find every install, get ready to update the moment fixed builds land, and make a separate plan for anything on an end-of-life version.

This guide covers what's confirmed and what's still rumour, which versions to target, how to find PHP you forgot about, and what to do when you can't upgrade.

What we know about PHP2Shell, and what we don't

The story started with a leak. On October 20, 2026, a Hacker News post claimed that two PHP RCE flaws, CVE-2026-109618 and CVE-2026-109619, would be disclosed on Thursday, October 22. The post said they were rated CVSS 10.0 and affected everything from PHP 5 onward. The poster admitted they had "no evidence beyond 'source: trust me, bro'." watchTowr then said publicly that the leak was real and the bugs were under embargo. PHP published its advance notice at 19:33 UTC that day and moved the release up by a day.

Sources disagree on whether exploit code is out there. Sansec reports that a tool called PHP2Shell, credited to Calif.IO, leaked alongside the advisory, and that its banner claims it works on every release from PHP 5.4.0 onward. Huntress said on October 20 that it knew of no public exploit code and hadn't reproduced a proof of concept. Either way, Sansec expects "mass attacks within 15 minutes of the release," because the patch diff itself will show attackers where to look. For comparison, Akamai saw exploit attempts against CVE-2024-4577 within 24 hours of its disclosure in June 2024.

You'll see some blogs naming a specific bug class, such as a use-after-free in session upload-progress handling. That comes from single sources and is uncorroborated. Don't tune defences around it until PHP's advisory confirms it.

Which PHP versions get a fix

PHP only patches branches that still have support. From php.net's supported versions page and the September 24 releases:

*Expected numbers come from trackers cited by The Hacker News and Mallory. Use the versions listed in PHP's actual release announcement.

Two takeaways for planning:

• PHP 8.2 is a short-term fix. It gets this patch but loses security support on December 31, 2026, about ten weeks away. If you're patching 8.2 today, book the upgrade to 8.4 or 8.5 now.
• The end-of-life exposure is large. Mallory counted about 884,000 internet-facing hosts (883,717 exactly) advertising PHP 8.1 or older in Shodan on October 20, 2026. That's 59% of roughly 1.5 million hosts that report a PHP version. Another ~740,000 hide their version. These are banner counts, not confirmed vulnerable systems, and one IP on shared hosting can serve many sites. Still, the scale explains why researchers expect a long tail of compromises.

Step 1: Find every PHP runtime you own

Nobody patches the PHP they've forgotten about. Huntress recommends inventorying everything, including PHP bundled inside vendor appliances, Windows software and control panels like cPanel and Plesk, plus CMS sites (WordPress, Drupal, Joomla, Magento). A practical checklist:

1. Servers and VMs. Run php -v, and also check the web-facing binary. php-fpm -v (or php-fpm8.x -v) can report a different version than the CLI, and the web server is what counts. Hosts with several versions installed are common. List them with your package manager (dpkg -l | grep php or rpm -qa | grep php).
2. Containers. Grep your Dockerfiles and compose files for FROM php: and any base image that installs PHP. Pinned tags like php:8.1-fpm mean an end-of-life runtime. Floating tags like php:8.4-fpm only pick up the fix when you rebuild and redeploy, not on their own.
3. Managed hosting and PaaS. Write down the PHP version each site runs in your host's control panel. If you don't manage the server, Sansec's advice is to ask your provider now to stand by and apply the update as soon as it's out.
4. Third-party products. Wikis, helpdesks, monitoring dashboards, billing panels and network appliances often ship their own PHP. Check vendor advisories rather than assuming the OS package covers them.
5. External view. Look for the X-Powered-By: PHP/x.y.z header on your public hosts. It's the same banner Mallory counted. Missing it doesn't mean you're safe, but finding it on a host you didn't expect is a useful signal.

Put the results in one place, sorted by internet exposure. Patch public-facing systems first.

A note on distro packages

Debian, Ubuntu, RHEL, Alpine and others often backport security fixes into their own builds without changing the upstream version number. On those systems, php -v won't tell you whether you're patched. Check the distro's security tracker for CVE-2026-109618/-109619 and compare against your package version instead. The flip side helps too: if your distro still maintains a PHP 8.1 build, you may get a backported fix even though php.net won't ship one.

Step 2: Patch at release time

This is a runtime bug, so the fix has to happen in the runtime. "You need to fix them at the infrastructure level," Sansec writes. A WordPress plugin or app-level rule isn't enough. Sansec, which sells an app-level firewall, says the attack hits PHP before store code runs and tells customers, "Do not wait for a Shield rule to protect you."

A release-day runbook:

1. Before 14:00 UTC: Confirm who's on call, where builds run, and how you'll roll back. Pre-stage any change approvals now.
2. At release: Read the official announcement on php.net for the confirmed fixed versions, affected versions and any configuration conditions. It may change your priorities. For example, if only certain SAPIs or extensions are affected, patch those first.
3. Update using your normal channel: OS packages (watch for the distro advisory), rebuilt container images, or a version change in your host's panel.
4. Restart the PHP process. Installing a new package doesn't patch a php-fpm pool or Apache module that's still running. Reload or restart, then check the version actually being served.
5. Verify with a temporary, access-restricted version check or your monitoring agent. Don't leave a public phpinfo() page lying around.

Step 3: If you're stuck on PHP 8.1 or older

This is the hard case, and it covers most of the exposed hosts in Mallory's count. Your options, roughly in order of preference:

• Upgrade to a supported branch. Moving from 8.1 to 8.3 or 8.4 is often less painful than teams fear. Still, test deprecations and extension compatibility in staging first instead of rushing it under incident pressure.
• Get a backport. Ask your distro, hosting provider or a commercial extended-support vendor whether they'll ship a fix for your branch. Sansec recommends asking your provider to backport the fix or move you to a supported version.
• Cut the exposure. Per Huntress, the options are to take the system offline or put it behind a VPN or WAF. The Hacker News adds CERT-EU's advice to isolate internet-facing applications from public networks until a fix exists. Internal admin tools almost never need to be public. Put them behind your VPN or an identity-aware proxy today.

Treat a WAF as a way to buy time, not a fix, especially before anyone knows what an exploit request looks like.

Step 4: Watch for compromise

Huntress expects exploitation to look like PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning things they never normally spawn:

• shells: sh, bash, cmd.exe, powershell.exe
• interpreters: python, perl
• download and network tools: curl, wget, nc, certutil.exe
• command lines containing /dev/tcp/, fsockopen or mkfifo, or recon commands like whoami, id, uname -a running as the web user

If you don't have endpoint detection on your Linux boxes, Huntress points to Florian Roth's free process-watcher for logging child processes. Roth himself notes it "prevents nothing," so it's for visibility only.

If you find signs of compromise, isolate the server, preserve web server and PHP logs, and look for webshells, new files in the web root, new cron jobs or scheduled tasks, and new accounts. Patching a server that's already compromised leaves the attacker's webshell in place.

What to watch next

• PHP's release notes and advisories (October 21, 14:00 UTC). These confirm the fixed versions, the affected range and the vulnerable component. Re-check your priorities against them.
• Distro and container updates. Debian, Ubuntu, RHEL, Alpine and the official Docker images usually trail upstream by hours to days. Track each one you depend on.
• CISA KEV and vendor detections. Per The Hacker News, the CVEs weren't in CISA's Known Exploited Vulnerabilities catalog as of October 21. Huntress says it will publish Sigma and YARA rules to its threat-intel GitHub repository once details are public.
• Your 8.2 deadline. Security support ends December 31, 2026. Put the upgrade on the roadmap this week.

If you're building on PHP, this is also a good time to tidy up how you track dependencies. Keep a current list of runtimes per service and container tags pinned to a supported branch, and you can do the "find every PHP install" step in minutes next time. For more security and infrastructure coverage for builders, see the LaunchBoosts blog.