PHP2Shell: Two Critical PHP RCE Flaws, CVE-2026-109618 and CVE-2026-109619

On October 20, 2026, the PHP project warned that it will fix two critical remote code execution vulnerabilities in an out-of-cycle security release scheduled for 14:00 UTC on October 21. PHP rates both flaws 9.2 on the CVSS v4.0 scale. Its notice names no CVE IDs, no affected versions and no vulnerable component, and says the details will be published together with the fixes.

Researchers are tracking the pair as CVE-2026-109618 and CVE-2026-109619, and some have started calling them PHP2Shell. No exploitation has been reported, and watchTowr lists neither flaw in CISA's KEV catalog. This post is a preparation brief: what is known, what is still unknown, and what to line up before the fixes land. It reflects sources read on the morning of October 21, before the release time.

What is known and what is not

The warning began as a leak. A post on a public forum on the morning of October 20 claimed two PHP remote code execution flaws, scored 10.0 and reaching back to PHP 5, with disclosure planned for Thursday, October 22. Within hours watchTowr said the information was real and that the flaws had been under embargo. PHP then published its own notice, and the release was moved up to October 21.

What the sources agree on is short. Both flaws are remote code execution, PHP scores them 9.2 under CVSS v4.0 (the leaked 10.0 came from the forum post, and the scorer is not stated), and the leak said the affected range starts at PHP 5. Neither claim about the range is confirmed. PHP has not said which component is involved or whether a particular configuration is required, and watchTowr says no specific configuration or feature requirement has been described.

Exploitation is not reported. Huntress said, as of October 20, that it had not built or reproduced a proof of concept and knew of no public exploit code, though a short exploit video was briefly posted online and then removed. An independent review of the PHP source by Mallory found nothing that confirms either CVE. NVD had no record for either CVE when read, and the CVE IDs themselves come from researchers rather than from PHP's notice, so treat the numbers as provisional until the release notes name them.

Who is affected

PHP has not published an affected range, so the honest answer today is that any PHP installation could be in scope until the release notes say otherwise. The leaked claim of "PHP 5 onward" is repeated by THN, CERT-EU and watchTowr, while Huntress cites reports covering versions 5 through 8. None of this is confirmed.

What is clearer is who can get a fix. Only the four supported branches are expected to receive one, and trackers including Alpine Linux and researcher Kevin Beaumont expect the next release of each branch to carry it.

PHP 8.1, 8.0, 7.x and 5.x are end of life and will not get an official fix, even if the flaws reach them. That matters because of how much of the internet still runs those versions. According to the Mallory count that THN cites, about 884,000 internet-facing hosts reported PHP 8.1 or older in their HTTP banner on October 20, which is 59% of the roughly 1.5 million hosts that reported any version. Another 740,000 hosts reported PHP without a version. Those are banner counts, not confirmed vulnerable systems, but they show how large the group without an official patch could be.

PHP also ships inside other software: vendor appliances, Windows applications, and control panels such as cPanel and Plesk. Those installs follow the vendor's update schedule, not PHP's.

A warning with no map

This case has an unusual order of events: the alarm came before the patch, and the patch will come before the explanation. That leaves defenders with almost nothing to sort by. The score is not settled (10.0 in the leak, 9.2 from PHP, "not yet scored" in watchTowr's table), NVD has no record, the affected range is a claim, and the vulnerable component is unnamed. A queue built on CVSS, EPSS or KEV status has no input for these two CVEs today, which makes the one thing you can do right now an inventory of where PHP runs.

The quiet period is also short. PHP says full details will be published with the release, and once a fix is public, anyone can read it for clues about the bug. There is a recent precedent in PHP itself: when CVE-2024-4577, a flaw in PHP's CGI mode on Windows, became public in June 2024, Akamai saw exploit attempts against its honeypot servers within 24 hours. That does not predict what will happen this time, but it shows how fast the gap between disclosure and attack can close for a language that runs a large share of the web.

The status line "not in KEV, no exploitation reported" is true as of the morning of October 21 and describes the early hours of this event. It is not a reason to wait. The teams that will be in the best position are the ones that know which servers run PHP, which branch each one is on, and who can restart them within the hour.

What to do before and after the release

There is no workaround, so the work is preparation, then fast patching. The steps below come from PHP, Huntress and CERT-EU.

1. Watch the official source. Follow PHP's announcement list and php.net for the release, and act on that notice, not on unverified reports. If the release has already shipped by the time you read this, its notes are the authority on affected and fixed versions.
2. Inventory every PHP install. Include PHP bundled in vendor appliances, Windows software and control panels such as cPanel and Plesk, and record the branch each one runs.
3. Be ready to patch internet-facing systems first. Check that your Linux distribution or hosting provider is packaging backports for the supported branches, since many systems do not take PHP straight from php.net.
4. Deal with end-of-life PHP now. For PHP 8.1 and older, upgrade to a supported branch, take the system off the internet, or put it behind a VPN or a web application firewall. No official fix is expected for these versions.
5. Isolate if you cannot patch in time. CERT-EU suggests considering taking internet-facing PHP applications off public networks until a fix is available.
6. Watch for shells. Alert when php-fpm, php-cgi, httpd or apache2 launches shells, interpreters or download tools. On Linux hosts without endpoint detection, Florian Roth's process-watcher tool can log every program a PHP process starts, along with its command line.
7. If you find something, preserve evidence. Isolate the server, keep the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs, scheduled tasks and new accounts.

Takeaway

PHP2Shell is a case where the useful work happens before the patch exists: know where PHP runs, which branch it is on, and who can deploy a fix quickly. Once PHP publishes the details, the CVE numbers, scores and affected versions will settle, and the picture will change fast. If you want to follow that, you can track PHP on VulnTracker and see the scores, KEV status and affected versions for CVE-2026-109618 and CVE-2026-109619 as they are published.

References

Vendor: PHP announcement of October 20, 2026. NVD: CVE-2026-109618 and CVE-2026-109619. Analysis: watchTowr FAQ, Huntress, CERT-EU advisory 2026-018, Mallory and The Hacker News.