What happened

The PHP security team is shipping an out-of-band security release today, Wednesday 21 October, at 14:00 UTC (10:00 AM ET). It fixes two critical flaws in PHP core, reported as remote code execution bugs and tracked as CVE-2026-109618 and CVE-2026-109619. The release was not supposed to land until Thursday. It moved up a day after details leaked ahead of the coordinated disclosure.

The advance notice on php.net, posted on 20 October, is short. It says the release "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2", asks all PHP users to "prepare now so they can upgrade as soon as the release is available", and reserves the right to ship even earlier "should details of either vulnerability become public, or should evidence of active exploitation appear in the wild." Affected and fixed versions, the team says, will be published with the release itself.

How the date moved

According to BleepingComputer, coordinated disclosure was set for Thursday 22 October at 11:00 AM ET. A Hacker News post by the user "petecooper", since deleted, appeared before PHP's own announcement. Security researcher Florian Roth then wrote on X: "an RCE vulnerability in PHP core, CVSS 10.0" and "Only PHP 8 will receive patches." Within hours the release had been pulled forward to Wednesday morning.

The CVE numbers did not come from php.net. They came from the research firm watchTowr, through BleepingComputer. watchTowr confirmed the bugs are real but is holding back technical details until patches exist. Its CEO, Benjamin Harris, told Decipher that "patches are currently unavailable, but we anticipate that the patch release will now be significantly faster."

What is confirmed and what is not

Two versions of this story are circulating, and they disagree on numbers that matter. This is where each claim stands as of October 21, 2026, checked on the morning of release day before the patches went out.

File tickets against the 9.2. The point-release numbers floating around for each branch are unconfirmed too, so wait for the php.net changelog before pinning a version in a Dockerfile.

Who gets no fix

The supported branches are PHP 8.2, 8.3, 8.4 and 8.5. Their last regular security releases were 8.5.11, 8.4.26, 8.3.35 and 8.2.34, all on 24 September according to php.net, and they are where today's fixes are expected. PHP 8.6.0 is still in release candidates, with RC4 planned for 22 October.

Everything older is the real problem. If watchTowr is right that the bugs reach back to PHP 5, every server still on PHP 5.x, 7.x, 8.0 or 8.1 is exposed with no upstream patch coming. Phoenix Security ran a Shodan-based estimate: about 2.23 million internet-facing hosts show a PHP banner and about 1.5 million of them reveal a version. Roughly 883,717 of those, 59% of the versioned hosts, run a branch that will not be patched, and 697,928 are on PHP 5.x or 7.x. Another 740,000 or so hide their version entirely.

Those are banner counts, not confirmed vulnerable servers. A banner says nothing about whether the flawed code path can be reached. Still, the United States leads the count at 228,770 hosts, and Amazon, Hostinger and Alibaba Cloud are the largest providers in it - which points at cheap shared hosting, old WordPress installs and forgotten internal tools. With PHP behind more than 60% of websites by Decipher's figure, that long tail is where this lands hardest. Its owners have three choices: upgrade to 8.2 or later, buy an extended-support build from a distribution or vendor, or take the box off the internet.

What to do today

Huntress said on 20 October it had not seen in-the-wild exploitation, and its advice is plain. Inventory every PHP installation, including the ones inside containers and appliances. Plan to patch at 10:00 AM ET today. Isolate end-of-life PHP from the internet. For detection, it expects exploitation to show up as suspicious child processes: php-fpm, apache2 or httpd launching shells, interpreters or download tools. You can alert on that now, before anyone knows what the exploit looks like.

Phoenix Security adds general hardening for the wait. Set cgi.fix_pathinfo=0 if you still run php-cgi, add try_files $fastcgi_script_name =404; to nginx PHP locations, prefer PHP-FPM over php-cgi, put admin endpoints behind an IP allowlist or VPN, and stage WAF rules to deploy once details are public. None of this is confirmed to stop these two CVEs. It narrows the usual PHP attack paths while the specifics stay private.

The release ships as upstream source first. Distribution packages, official container images and managed hosts rebuild on their own schedules, so "PHP released a fix at 14:00" does not mean your apt upgrade has one at 14:05. Check the version string after you update rather than assuming.

What's next

With the release, php.net publishes the affected and fixed versions, and the two CVE records should leave "reserved" status. That is when the race starts. Once a fix is public, attackers can diff it, and watchTowr has already reproduced one of the two flaws without a public proof-of-concept. Teams on supported 8.x branches should finish today. Anyone on PHP 7 or older has a harder week: an upgrade postponed for years now has a deadline.

For other recent patch windows of the same shape, see our coverage of the Cisco ISE authentication bypass, the exploited VMware vCenter flaw and October's Patch Tuesday zero-day.