PHP Emergency Alert: Why the Real Danger Is the 59% on Unsupported

The Leak That Beat the embargo

On October 20, a post on Hacker News claimed two PHP remote code execution flaws — rated CVSS 10.0 — would be disclosed the following Thursday. The poster offered no proof beyond “source: trust me, bro.” By that evening, PHP had published its own notice, accelerating its release by a day and lowering the official score to 9.2 on the CVSS v4.0 scale. watchTowr confirmed the leaked information was real, and the embargo was already broken.

The pattern is familiar and frustrating. Security researchers discover a critical flaw. Vendors prepare a coordinated disclosure. Someone leaks it. The clock runs fast forward. What matters now is not the drama but the landscape the leak exposed: two unpatched PHP RCE vulnerabilities with a CVSS rating above 9.0, no known workaround, and active exploitation not yet reported — but unlikely to stay absent for long.

Who Gets Fixed, Who Does Not

PHP will ship an out-of-cycle security release for its four supported branches: 8.2, 8.3, 8.4, and 8.5. That is where the patch goes. Everything else is on its own.

Versions 8.1, 8.0, 7.x, and 5.x are end of life. They receive no fix from PHP. If the vulnerabilities reach those branches — and watchTowr’s FAQ notes that the scope has not been officially confirmed — installations on them will remain exposed indefinitely.

This is not a hypothetical gap. Security company Mallory counted roughly 884,000 internet-facing hosts whose HTTP banner reported a PHP version of 8.1 or older to Shodan on October 20. That represents 59 percent of the approximately 1.5 million hosts that reported any PHP version. A further 740,000 hosts reported PHP without a version string. These are banners, not confirmed affected systems, but they paint a clear picture: the majority of visible PHP installations are running on branches that will never see a vendor patch.

The WordPress ecosystem is the most obvious exposure surface. Millions of WordPress sites run PHP as their backend, and a significant share of those sites have not upgraded to a supported PHP version. For those operators, the emergency alert is not a call to patch. It is a call to decide whether to isolate, migrate, or accept risk.

Why This Matters Outside the PHP Ecosystem

PHP is often treated as a legacy technology in security circles. That assumption is exactly what makes this alert dangerous. Critical infrastructure, government portals, and small business applications continue to run on old PHP versions because migration is costly, documentation is scarce, and the incentive to upgrade is low until something breaks.

The CVEs in question — CVE-2026-109618 and CVE-2026-109619, identifiers already appearing in the leaked post — are not arbitrary. A CVSS 9.2 RCE flaw in a language that powers a large fraction of the web is a high-impact event. The fact that PHP has not described the technical details yet is both a protection and a liability: it slows attackers, but it also leaves defenders flying blind while they prepare.

The Exploitation Timeline Is the Real Risk

Huntress reported no exploitation of the flaws in its partner environments as of October 20. watchTowr’s FAQ lists exploitation as none reported as of October 21. The flaws are not yet in CISA’s Known Exploited Vulnerabilities catalog.

But history argues against complacency. When CVE-2024-4577, a PHP CGI-mode vulnerability on Windows, became public in June 2024, Akamai saw exploit attempts against its honeypot servers within 24 hours. There is no reason to believe a CVSS 9.2 PHP RCE will be treated more gently by threat actors.

The window between public disclosure and widespread exploitation is the moment that destroys organizations which have not prepared. Patching is slow for complex estates. Dependency checks take time. Rollbacks carry risk. Every hour of delay is an hour where the gap between attacker capability and defender readiness widens.

What Defense Looks Like Right Now

PHP has published no workaround. Until the release lands, the guidance is operational, not technical. Huntress and CERT-EU have converged on a practical set of steps.

First, inventory every PHP installation. This includes PHP bundled in vendor appliances, Windows software, and control panels such as cPanel and Plesk. Many organizations manage PHP without knowing it. The flash update inside a proprietary application or the embedded interpreter in a hardware appliance is easy to miss and hard to patch.

Second, be ready to upgrade at the release time. Prioritize internet-facing systems. Check Linux distribution and hosting provider repositories for backported packages, which may arrive before the official PHP release.

Third, for end-of-life branches, the choices are upgrade, isolate, or restrict. CERT-EU advises isolating internet-facing applications from public networks until a fix is available. A VPN or a web application firewall can buy time. Neither is a permanent solution, but both reduce the attack surface while operators plan migration.

Fourth, monitor PHP process behavior. On Linux servers without endpoint detection, Florian Roth’s process watcher logs every program a PHP process starts, along with its command line. It does not prevent execution. It records it. The signals to watch for are php-fpm, php-cgi, httpd, or apache2 launching shells, interpreters, or download tools.

Fifth, if you find something, isolate the server immediately. Preserve the web server and PHP logs. Look for web shells, new files in the web root, new cron jobs, scheduled tasks, and unexpected accounts. RCE abuse leaves artifacts. The speed of the response determines whether those artifacts support containment or become evidence of loss.

What the Release Will Clarify

The upcoming PHP release should answer the questions the notice withheld: which versions are affected, which component of PHP is involved, whether the flaw requires a particular execution mode, configuration, or login, and how PHP itself describes the vulnerabilities.

Until then, the advisory is directional, not specific. That is standard for embargoed research. It is also the point at which the cost of inaction becomes visible. Organizations on supported branches can prepare for a patch. Organizations on end-of-life branches must prepare for isolation, migration, or risk acceptance. The 59 percent figure is not a statistic. It is a countdown.

The emergency alert is real. The release will close the technical gap for supported versions. The structural gap — the installations that will never be patched — remains after the press release fades. That is the longer problem, and the one this alert should force organizations to confront.