PHP will ship an out-of-cycle security release at 14:00 UTC today, October 21, for two critical vulnerabilities that its security team has rated 9.2 on the CVSS v4.0 scale but has not described.
Security researchers at watchTowr say the two flaws allow remote code execution. Only the four supported PHP branches, 8.2 through 8.5, can receive the fix, and no exploitation has been reported so far.
The advance notice followed a leak. On October 20, a post on HN said two PHP remote code execution flaws, rated CVSS 10.0 and affecting versions from PHP 5 onward, would be disclosed on Thursday, October 22. The poster said they had “no evidence beyond ‘source: trust me, bro'”.
watchTowr then posted on X that the leaked information was real, that the two flaws were under embargo, that everyone had been supposed to wait until Thursday, and that it could not share more for now.
PHP published its notice that evening, at 19:33 UTC, with the release set for Wednesday, a day before the date watchTowr gave. The notice says PHP may release earlier “should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”
The leak carried the flaws’ existence, a score, a date, and two CVE identifiers, not how the flaws work. The CVSS 10.0 figure is the leak’s. PHP’s rating is 9.2 on version 4.0 of the scale.
The identifiers researchers are using, CVE-2026-109618 and CVE-2026-109619, were also listed in the leaked post. PHP’s notice names neither. The claim that every version since PHP 5 is affected is unconfirmed too: watchTowr’s own FAQ on the flaws says that scope “has not been confirmed by an official vendor advisory” and that no configuration or feature requirement has been described.
PHP says “Full details, affected versions, and the fixed versions will be published with the release.” Researchers have started calling the pair php2shell. The name is theirs, not PHP’s.
Whatever the affected range turns out to be, PHP issues fixes only for its four supported branches, and records each branch’s changes in its changelog. Versions 8.2 and 8.3 receive only security fixes, and 8.4 and 8.5 are in active support.
Anything older, including 8.1, 8.0, 7.x, and 5.x, is end of life and gets no PHP fix. If the flaws reach those branches, installations on them will have no vendor patch.
| Branch | Current release (September 24) | PHP support status |
|---|---|---|
| 8.5 | 8.5.11 | Active support until December 31, 2027 |
| 8.4 | 8.4.26 | Active support until December 31, 2026 |
| 8.3 | 8.3.35 | Security fixes only until December 31, 2027 |
| 8.2 | 8.2.34 | Security fixes only until December 31, 2026 |
Security company Mallory counted about 884,000 internet-facing hosts whose HTTP banner reported a PHP version of 8.1 or older to the Shodan search engine on October 20, 59% of the roughly 1.5 million hosts that reported any version. The count covers banners, not confirmed affected systems, and a further 740,000 hosts reported PHP without a version.
PHP has published no workaround. Until the release lands, the preparation comes down to six steps, most of them drawn from a rapid-response post from Huntress, with CERT-EU’s isolation advice added.
- Inventory every PHP install, including PHP bundled in vendor appliances, Windows software, and control panels such as cPanel and Plesk.
- Be ready to upgrade at 14:00 UTC. Patch internet-facing systems first, and check your Linux distribution and hosting provider for backported packages.
- On an end-of-life branch, upgrade, take the system off the internet, or put it behind a VPN or a web application firewall until you can.
- Where patching cannot be done at once, CERT-EU advises that you “consider isolating internet-facing applications from public networks until a fix is available.”
- Watch what PHP starts. Alert on php-fpm, php-cgi, httpd, or apache2 launching shells, interpreters, or download tools. On Linux servers without endpoint detection, Florian Roth’s process-watcher logs every program a PHP process starts, with its command line. It sees a program only after it has started and, in Roth’s words, “prevents nothing.”
- If you find something, isolate the server, preserve the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs, scheduled tasks, and accounts.
Huntress said it had not seen exploitation of the flaws in its partner environments as of October 20, had not built or reproduced a proof of concept, and was not aware of public exploit code. watchTowr’s FAQ lists exploitation as none reported as of October 21 and the flaws as not in CISA’s Known Exploited Vulnerabilities catalog.
For comparison, when 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.
The release should clarify what the notice withheld: which versions are affected, which part of PHP is involved, whether an attack requires a particular way of running PHP, a configuration, or a login, and how PHP itself describes the flaws. At the time of writing, PHP had not released the fixes.
