The PHP project ships an unscheduled emergency security release today, 21 October 2026, at 14:00 UTC. Two vulnerabilities are involved, and PHP's own security team rates both as critical with a CVSS v4.0 score of 9.2.

This article was written before the release landed. Some of the items marked below as unconfirmed will be settled once it does. For the definitive list of affected versions, always use the official announcement on php.net.

What is actually published

The CVE identifiers in circulation are CVE-2026-109618 and CVE-2026-109619. They come from the security firm watchTowr; reporting notes that PHP's own announcement did not cite them. watchTowr says it reproduced one of the two and chose not to publish technical detail ahead of the fix.

GMO Flatt Security links the risk to a memory corruption issue in PHP's session extension, which is enabled by default. That distinction matters: this is analysis of a suspected area, not a confirmed root cause. The PHP project has published neither the root cause nor the affected versions.

The only certainties are the release itself and the score the maintainers attached to it. PHP does not make a habit of shipping out of band, which makes the existence of the release a stronger signal than any number attached to it.

Why the date moved

On the morning of 20 October, a post appeared on Hacker News claiming remote code execution in PHP. It was removed, but screenshots circulated. watchTowr then confirmed the flaws are real, writing: "we were all supposed to wait until Thursday at 11am ET."

PHP had already reserved the right to release early if technical details became public or if evidence of exploitation appeared. The details became public. The date moved.

That distinction is operationally useful. The urgency you are reading today was created by a coordination failure, not by an attack. Preserving that difference when you brief your own management or your customers avoids both unnecessary panic and unearned complacency.

One number has already drifted. The removed Hacker News post reportedly claimed a CVSS of 10. The PHP security team's own figure is 9.2. The inflated number travelled first, as it usually does.

What nobody has confirmed

As of today, the unconfirmed list is longer than the confirmed one:

• No technical root cause has been published. Huntress states plainly that it does not yet know whether the flaw is "reachable over a plain web request" — the single fact that separates an internet-wide emergency from a more contained problem.
• Affected versions are not confirmed. PHP has published no list. watchTowr's CEO says PHP 5, 6, 7 and 8 are affected; other reporting expects fixes only for the supported 8.x branches. Until the release lands you cannot scope your own exposure.
• No exploitation has been observed. Huntress reports no in-the-wild exploitation across its partner environments as of 20 October, and no public exploit code is known. A short exploitation video was posted briefly and then taken down.

Two statements need to be held at once here. A 9.2 from the maintainers is a serious signal and should be treated as one. It is also, today, the only published fact about severity.

The patch will not reach everything

Only the 8.2 to 8.5 branches are currently supported by the PHP project. PHP 8.1 and earlier are unlikely to receive an official fix unless the project makes an exception. Given how much production PHP is older than 8.2, that is not a narrow footnote.

Most organisations do not run PHP deliberately — they inherit it. It arrives inside vendor appliances, hosting control panels, CMS platforms and line-of-business applications nobody has touched in years. In those environments, ownership of the version number is usually unclear.

An interim measure is circulating: setting session.upload_progress.enabled to Off. It comes from the researcher who named this "php2shell", supported by analysis from GMO Flatt Security. The side effect is that upload progress bars stop working.

However, GMO Flatt Security cannot guarantee the measure is sufficient until the fixes ship. Treat it as a hedge that costs you a progress bar, not as a substitute for the patch.

What to do before the release lands

• Inventory first, patch second. Find every PHP installation you are responsible for, including the ones bundled inside vendor software, hosting control panels and CMS platforms. With no affected-version list published, the inventory is necessarily the first step.
• When the release lands, patch internet-facing systems first, then track backported fixes from your distribution and hosting provider on their own timetable.
• Identify end-of-life PHP now. Anything on 8.1 or earlier is unlikely to receive an official fix — plan to upgrade it, take it offline, or place it behind a VPN or WAF.
• Consider the interim mitigation (session.upload_progress.enabled = Off) on exposed hosts, understanding that its sufficiency cannot be confirmed until the fixes ship.
• Prepare the detection side. Alert on PHP worker processes spawning shells, interpreters or download tools. If you suspect compromise, isolate the host, preserve logs, and look for webshells, new files in the web root, new cron jobs and new accounts.

The lesson outlasts the day

There is no attack today. That is the best case available: a readiness exercise with a deadline. But what the exercise measures is not your patching speed. It is your visibility.

When the affected-version list lands at 14:00 UTC, some teams will be able to say within minutes how much PHP they run, on which versions, and where. Others will start looking. The difference between those two groups was not decided today — it was decided months ago, by whoever built the inventory.

CyberDistro's exposure management portfolio exists for exactly that question: knowing where the software is running on the days when there is no time to go and find out.

Sources and verification note

Corroborated by two independent sources: the CVSS v4.0 score of 9.2 from the PHP security team, the out-of-band release on 21 October at 14:00 UTC, the Hacker News post published and removed on 20 October, the absence of a published affected-version list, and the absence of observed exploitation.

Single-sourced, and marked as such in this article: watchTowr's "Thursday at 11am ET" statement, the removed post's reported claim of CVSS 10, and the detail that PHP's own announcement did not cite the CVE identifiers.

Sources: PHP project announcement, Huntress ("php2shell" rapid response, John Hammond), watchTowr, GMO Flatt Security, IT-Connect.