PHP’s 9.2 RCE Patches Skip Every Unsupported Branch

PHP scheduled an out-of-cycle security release for 14:00 UTC on October 21, 2026, covering two remote code execution flaws it rated 9.2 on CVSS v4.0. The project has not named the bugs, the affected versions, or a workaround. Researchers call the pair php2shell. PHP does not.

The packages are coming only for 8.2 through 8.5. Every older branch, including PHP 8.1, which reached end of life on December 31, 2025, will get no vendor patch from the project, leak or no leak.

PHP Set a Wednesday Drop and Left the Bugs Unnamed

The PHP security team posted its notice on October 20, 2026, under the heading Upcoming Critical PHP Security Release. It said the drop is scheduled for 14:00 UTC on October 21, and it told every PHP user to get ready to upgrade the moment the files appear. Full details, affected versions, and the fixed versions, the notice said, will be published with the release.

We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.

PHP security team, php.net notice, 20 October 2026

That is the entire official description. The notice does not list CVE identifiers, does not name a function or SAPI, and does not say whether an attack needs a login, a special config, or a plain request. By the morning of October 21 the php.net news page still listed the release as upcoming, so the tarballs had not been posted when operators were already treating the bugs as real.

Researchers are tracking the pair as CVE-2026-109618 and CVE-2026-109619. PHP’s notice names neither. A leaked post on October 20 scored the flaws 10.0; PHP’s own figure is 9.2 on version 4.0 of the scale, and that is the rating that governs the release.

Thursday’s Embargo, Burned on Tuesday

The calendar moved because the embargo did not hold. On the morning of October 20 a Hacker News post said two PHP remote code execution flaws, rated CVSS 10.0 and reaching back to PHP 5, would be disclosed on Thursday, October 22. The poster wrote they had no evidence beyond an unnamed source. The post came down. Screenshots did not.

watchTowr then confirmed the leak on X, said the two flaws were under embargo, and said everyone had been supposed to wait until Thursday at 11 a.m. ET. It also said it had reproduced CVE-2026-109618. A few hours later PHP pulled the release forward by a day, to Wednesday.

We were all supposed to wait until Thursday at 11am ET. Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they’re real.

watchTowr, on X, 20 October 2026

We were all supposed to wait until Thursday at 11am ET.

Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they're real. CVE-2926-109618/619

We cannot share further information right now. Take this seriously and apply patches when available. pic.twitter.com/kguM8fpq13

— watchTowr (@watchtowrcyber) October 20, 2026

A National Cyber Office warning in Japan pointed site operators at the same PHP notice and told them to get ready to apply the packages as soon as they landed. That is the official track. The unofficial track moved faster.

HOW THE EMBARGO BROKE

1. October 20, 2026: A Hacker News post claims two PHP RCE flaws, scored 10.0, will be disclosed on October 22, then the post is taken down.
2. October 20, 2026: watchTowr confirms the embargoed bugs are real, names CVE-2026-109618 and CVE-2026-109619, and says the wait was until Thursday at 11 a.m. ET.
3. October 20, 2026: PHP posts an advance notice for an out-of-cycle release at 14:00 UTC on October 21 and says it may ship sooner if details leak or exploitation appears.
4. October 21, 2026: Independent testers say they have recreated the bugs; operators start turning off session upload progress; PHP’s news page still lists the tarball as upcoming.

The remaining embargo, once watchTowr spoke, was measured in hours. Publishing working tests burned those hours. That is the objection that landed on the recreation posts, and it is the reason Wednesday’s drop is already racing a leak that named the CVEs a day early.

About 884,000 Hosts Cannot Use the Tarball

Whatever the affected range turns out to be, PHP issues fixes only for the four currently supported PHP branches. Versions 8.2 and 8.3 already receive security fixes only. Versions 8.4 and 8.5 are still in active support. Anything older, including 8.1, 8.0, 7.x, and 5.x, is end of life and gets no PHP patch.

Which PHP Branches Get a Vendor Fix?

Only 8.2, 8.3, 8.4, and 8.5 can receive Wednesday’s packages. PHP 8.1’s last release was 8.1.34, and that branch went end of life on December 31, 2025, so an 8.1 host that is vulnerable will not find a vendor file waiting on php.net.

BRANCHES THAT CAN RECEIVE A FIX

Security support for 8.2 itself ends on December 31, 2026. PHP 8.0 already ended on November 26, 2023. The floor of “supported” is a short list, and even 8.2 is near the edge of it.

Mallory counted internet-facing hosts by the PHP version sitting in HTTP banners on Shodan on October 20. Those banners are not confirmed vulnerable systems. They are the public roll call of what servers still admit to running.

BANNER COUNTS ON OCTOBER 20

• Older than 8.2: About 884,000 hosts advertised PHP 8.1 or older.
• Share of versioned banners: That was 59 percent of the roughly 1.5 million hosts that reported any PHP version.
• No version at all: A further 740,000 hosts reported PHP without a version string.
• What the count is not: A tally of proven vulnerable boxes, or of PHP hidden inside appliances that never send a banner.

If the flaws reach those older branches, the 884,000 figure is the population that will still be exposed after PHP’s own files go live. The 740,000 with no version are a second, darker pile: operators cannot even tell from the banner which side of the support line they are on.

The Copies of PHP That php -v Never Lists

The other hidden party is PHP that does not look like a PHP server. Huntress told operators to inventory web servers first, then go looking for vendor appliances and Windows software that bundle php.exe or php-cgi.exe, and for control panels such as cPanel and Plesk. WordPress, Drupal, Joomla, and Magento sit on a lot of those stacks, and shared hosts often pin a branch and leave it there for years.

Linux distributions and hosting providers may ship backported packages for the supported branches. They will not invent a PHP 8.1 or 7.4 patch that the project itself refuses to write. On an end-of-life branch the choices Huntress listed are upgrade, take the system off the internet, or put it behind a VPN or a web application firewall until you can. CERT-EU’s line is colder still: consider isolating internet-facing applications from public networks until a fix is available.

That isolation advice is the actual patch for a large share of the public PHP internet. The tarball is not.

A One-Line php.ini Change PHP Did Not Publish

PHP has published no workaround. Overnight on October 20 and into October 21, operators started turning off session.upload_progress, a setting some independent testers have tied to two heap use-after-free bugs in upload-progress handling. PHP has not confirmed the root cause, and it has not blessed the switch.

John Hammond’s Huntress note, posted against the October 20 leak, said Huntress had not seen exploitation in partner environments, had not built or reproduced a proof of concept, and was not aware of public exploit code at that time. A short exploitation video was posted and then pulled. watchTowr’s FAQ, updated through October 21, still listed exploitation as none reported and the flaws as not in CISA’s Known Exploited Vulnerabilities catalog. The testers posting recreations after that Huntress note do not change PHP’s silence. They do change the amount of time left in which silence helps.

WHAT WE KNOW

• The rating: PHP scored both flaws 9.2 on CVSS v4.0 and called them critical.
• The patch window: Supported branches are due a release at 14:00 UTC on October 21, 2026, unless PHP ships sooner.
• The support line: Only 8.2, 8.3, 8.4, and 8.5 can get a vendor fix.
• Exploitation: None reported as of October 21, per watchTowr, and none seen by Huntress as of October 20.

WHAT IS UNCONFIRMED

• Affected versions: The leak’s “PHP 5 onward” claim has not been confirmed by a vendor advisory, and watchTowr says no configuration or feature requirement has been described.
• The mechanism: PHP has not named a component. Independent testers point at session upload progress; that remains their claim.
• The ini switch: Setting session.upload_progress.enabled to Off is a reversible cut to one suspected path, not a published workaround, and it may not cover a second path in multipart form handling.

Treat the php.ini change as an unconfirmed, low-cost reduction of exposure, then still take the tarball the minute it exists. Do not treat it as a reason to stay on 8.1.

A Windows CGI Bug From 2024 Still Instructs

PHP has shipped a public RCE in living memory. CVE-2024-4577, disclosed in June 2024, was an argument-injection bug in PHP-CGI on Windows when Apache was in front of it. It hit 8.1 before 8.1.29, 8.2 before 8.2.20, and 8.3 before 8.3.8. That bug needed a particular way of running PHP. This week’s pair may not.

watchTowr’s FAQ says no feature requirement has been described. Huntress wrote that a core PHP bug, rather than a bug in one app built on PHP, makes the search for copies of PHP very large, very fast. The 2024 CGI case is the reminder that once a PHP RCE is public, the people writing scanners do not wait for a tidy advisory. The people running 8.1 already cannot wait for a tidy patch, because there will not be one.

Detection, until the packages land, is about what PHP starts. Huntress told operators to alert on php-fpm, php-cgi, httpd, or apache2 launching shells, interpreters, or download tools. Florian Roth’s process-watcher is a Linux logger built for that job, and its README is blunt about the limit: it sees a program after it started. “It prevents nothing,” Roth wrote. Code that runs inside the PHP worker and starts no process is invisible to it.

What the Tarball Still Has to Spell Out

The release has to answer the questions the October 20 notice withheld: which versions are affected, which part of PHP is involved, whether an attack needs a particular way of running PHP, a configuration, or a login, and how PHP itself describes the flaws. Until those lines exist, every internet-facing install is in the prepare column, and every 8.1-or-older install is in the isolate-or-upgrade column.

PREP BEFORE THE TARBALL

• Inventory: List every PHP install, including copies bundled in vendor appliances, Windows software, and panels such as cPanel and Plesk.
• Patch order: Be ready at 14:00 UTC on October 21, hit internet-facing systems first, and check your Linux distribution and host for backported packages on 8.2 through 8.5.
• End-of-life hosts: Upgrade, pull them off the internet, or put them behind a VPN or a web application firewall; there will be no php.net file for 8.1 and older.
• Watch children: Alert on PHP workers starting shells, interpreters, or download tools, and if you find that, isolate the server, keep the web and PHP logs, and look for web shells, new files in the web root, new cron jobs, scheduled tasks, and accounts.

The Wednesday tarball will close the supported branches, or it will not, once PHP names the range. It will not close the banners that still say 8.1, and it will not close the PHP that never sends a version at all. Those copies are the ones the leak actually stranded.