PHP Patch Day: Who Gets the 14:00 UTC Fix, and Who Doesn't

At 14:00 UTC on Wednesday, Oct. 21, the PHP security team plans to publish a security release. That is 10 a.m. in New York, 4 p.m. in Paris and 11 p.m. in Tokyo. It is scheduled, not out: as of about 09:15 UTC, php.net still listed 8.5.11, 8.4.26, 8.3.35 and 8.2.34, all dated Sept. 24, as the newest versions, so the numbers that will carry the fix do not exist yet.

The fix covers two vulnerabilities that PHP's notice rates 9.2 on CVSS v4.0, the standard severity scale that tops out at 10. The notice names no CVE numbers, versions or technical details, because, it says, Full details, affected versions, and the fixed versions will be published with the release. What it does ask is plain: All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.

Preparing, for most people, means one task: find out who updates the PHP that runs your site. The release is a file on a download page; your site is protected only when that file has travelled down a chain.

Confirmed, reported and rumored

Start with what is established. PHP itself confirms the release, the date and the score. CERT-EU's advisory, released Oct. 20, adds the two CVE identifiers, CVE-2026-109618 and CVE-2026-109619, which appear in CERT-EU's text but not in PHP's notice. It states that no technical details are available beyond the 9.2 scores, "which indicate the potential for unauthenticated remote code execution": in plain terms, a stranger running commands on a server without logging in. CISA's catalogue of known exploited vulnerabilities, in its Oct. 20 version with 1,754 entries, lists neither flaw.

The rest arrived by leak. On Oct. 20 a Hacker News post, since deleted, claimed two PHP remote code execution flaws rated CVSS 10.0, affecting PHP 5 onward, would be disclosed on Oct. 22. The poster's own sourcing, according to The Hacker News, was "source: trust me, bro." The security firm watchTowr then said on X that the leak was real.

"While we are not able to share technical information at this point for obvious reasons, given the sensitivity, we can confirm that these vulnerabilities are indeed real."

Benjamin Harris, CEO of watchTowr, to BleepingComputer

watchTowr says it believes it reproduced CVE-2026-109618 and is holding the detail until patches exist. The leak itself carried a count, a score, a date and two CVE IDs, but no root cause, affected component or attack path. The tip was right on existence and off on particulars: the leak and watchTowr said CVSS 10.0, PHP says 9.2, and they pointed to Thursday, Oct. 22 at 11 a.m. ET, a day after PHP's slot.

On exploitation the reporting splits, so here it stays split. The Australian Cyber Security Centre said ACSC is currently not aware of active exploitation related to these vulnerabilities. watchTowr's FAQ says none had been reported as of Oct. 21, and Huntress said that as of Oct. 20 it had seen none in partner environments. On the other side, Cloudflare's chief technology officer, Dane Knecht, wrote on X, as Reuters quoted him: We are seeing early attacks emerging and are updating mitigations as new vectors show up. This is a STOPGAP only. Patch as soon as PHP releases the update. Patchstack said it had received reports of active exploitation from multiple hosting partners, a claim the other sources quoted here do not echo. Sansec expects mass attacks within 15 minutes of the release, a forecast, not an observation.

For tempo, one comparison, not a prediction: after CVE-2024-4577, a PHP flaw in CGI mode on Windows, became public in June 2024, Akamai saw exploit attempts against its honeypot servers within 24 hours.

One correction: headlines turned CERT-EU's advice into sites that "may go dark." The advisory says that where immediate patching is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is available. That is a fallback for organisations that cannot patch, not an order for every blog and shop to switch off.

Only 8.2 to 8.5 are on PHP's patch list

PHP fixes only supported branches, and on PHP's supported-versions page those are 8.2 through 8.5. Anything older gets nothing unless PHP announces an exception, which it has not; Wordify, a managed WordPress host, calls the position for 8.1 and older "not yet clear."

Version 8.0 reached end of life in November 2023 and 7.4 in November 2022. php.net's own wording for such releases is that they are "no longer supported" and that users "may be exposed to unpatched security vulnerabilities." That matters because the scary scope claim, "PHP 5 onward," has weak footing. It comes from CERT-EU citing a social-media post, not from PHP. A leaked tool's banner reportedly says 5.4.0 onward. watchTowr's FAQ says the scope "has not been confirmed by an official vendor advisory" and that "No specific configuration or feature requirement has been described." The honest reading: old branches may well be affected, and the party that could say so is silent.

Trackers, including Alpine Linux's, and researcher Kevin Beaumont expect the fixed versions to be 8.5.12, 8.4.27, 8.3.36 and 8.2.35, though PHP has not confirmed the numbers. Treat that as a guess and read the real ones off the advisory.

The repair belongs to PHP itself, not to your site's code. Sansec put it bluntly: "You cannot fix it from within your store codebase." Web host Teramont adds that updating WordPress, Laravel or Composer "does not replace" updating the PHP interpreter, the program that runs the code.

Unconfirmed early analysis ties the bugs to PHP's session upload-progress feature, on by default, and some vendors suggest switching off the setting session.upload_progress.enabled as a stopgap. Patchstack calls that "only a partial mitigation," GoDaddy says it "isn't official or confirmed as complete mitigation," and Patchstack says PHP core developers have said the only full fix is to update. Ask your host or read the advisory before changing anything.

Most banner-visible hosts are on older PHP

Mallory's count of internet-facing PHP hosts, drawn from Shodan data on Oct. 20, found about 1.5 million hosts that announce a PHP version in a banner, a line some servers volunteer about their software. Of those, 883,717, or 59%, run PHP 8.1 or earlier. Of every 10 PHP servers that announce their version, about six run something PHP's policy does not patch.

Mallory's own caveats matter. These are hosts, not websites, and "Shared hosting puts many sites on one IP." Another roughly 740,000 PHP hosts hide their version. And "Some distro packages (Debian, Ubuntu, RHEL) may backport fixes to older versions," meaning a Linux vendor can patch an old PHP without changing its number.

Even the supported group has a cliff. Version 8.2 gets this fix, yet leaves security support on Dec. 31, 2026, 71 days from now, and Mallory counts 224,681 hosts on it, 15.0% of all versioned hosts. On that date 8.4 moves from active support to security-only.

If you run 8.1 or older, the options are narrow and none is a promise. Upgrade to a supported branch, ideally one with years left rather than weeks. Ask your host whether it ships its own backports for your version. If neither is possible soon, CERT-EU's isolation advice is the fallback. Wordify, preparing an "emergency maintenance window," urges sites on 7.4, 8.0 or 8.1 to move to 8.2 or newer. Back up first.

Checking your own version, and who has to restart

"Patched" is a journey with five stops. GoDaddy, a hosting company, describes the first two: PHP publishes the fix first. Operating system vendors, control panels, and hosting providers then release their own updates on their own schedules. In practice:

1. php.net publishes the source and version numbers.
2. Distributions, panels, container images and hosts ship their own packages.
3. The running PHP process, or the container, is restarted or replaced.
4. The owner checks the PHP that actually serves the website.
5. On Debian, Ubuntu and similar systems, the package revision is matched to the vendor's advisory, since a backport may not carry the new upstream number.

"An installed package is insufficient if services are still running the previous binary."

Teramont, web host

Who does the work depends on where you live. On most managed and shared hosting, Wordfence researcher Alex Thomas said in a public service announcement reported by The Repository, the host updates PHP; on a VPS or self-managed server, it falls to you or your developer. Wordfence also warned, as Reuters reported, that WordPress automatic updates would not apply the fix. If you cannot say who patches yours, that is the first email to send, asking for a fresh backup and for the date the host will confirm completion.

Panels and containers add traps. Teramont notes that runtimes managed in Plesk or cPanel "can coexist with the system PHP installation," so the system copy can be fixed while the site runs another. With Docker, "Restarting the same container does not incorporate a new image.": rebuild the image and replace the container.

To see your version, open WordPress admin and go to Tools > Site Health > Info > Server, or use the PHP selector in your hosting panel. On a command line, php -v works with a catch: Teramont says it "reports the invoked binary's version" and the command-line version may differ from the one serving your website. Do not leave a public phpinfo() page up for this, since the output "can expose paths, configuration and environment variables." If you run more than one PHP version, GoDaddy says to check each one.

After the advisory lands, compare your version with the fixed number for your branch, mind the backport rule, restart PHP and the web server, and look again. Patchstack's advice: avoid unofficial "fix" plugins and copy-pasted snippets. As with Microsoft's October patch release, a published fix and an applied fix are different events.

At 14:00 UTC the patch becomes a file anyone can download. Your site is safe only once the process serving it has been restarted on the new code and you have looked, from the outside, to see that it did.