PHP Rushes Out Emergency Fix for Two Undisclosed Critical Remote Code Execution Bugs After Leak

The PHP project scheduled an emergency security release for 14:00 UTC on Wednesday, October 21, to fix two critical vulnerabilities. Its security team has rated both flaws 9.2 out of 10 but has not explained how they work. PHP announced the release on the evening of October 20, after an anonymous online post revealed the bugs ahead of their planned disclosure. Researchers at security firm watchTowr say both flaws allow remote code execution, meaning an attacker could run their own commands on an affected server. The Hacker News reported the story in detail, and LWN.net told its readers that anyone running a PHP site should probably get ready to update.

What happened

The sequence of events moved quickly over about a day:

• October 20, the leak: A post on Hacker News claimed that two PHP remote code execution flaws would be disclosed on Thursday, October 22. The post said the flaws had the maximum severity score of 10.0, affected every version from PHP 5 onward, and carried two CVE identifiers. CVEs are standard catalogue numbers for publicly known security flaws. The poster openly said they had no evidence to back up the claims.
• watchTowr confirms: watchTowr then said on X that the leaked information was genuine. It explained that the flaws were under embargo, meaning the parties involved had agreed to keep the details private until an agreed date, in this case Thursday. The firm said it could not share anything further.
• PHP brings the date forward: At 19:33 UTC that evening, PHP published an advance notice. It set the fix for Wednesday, one day earlier than the date watchTowr had given. The notice also said PHP might release the fix even sooner if details of either flaw became public or if attacks appeared in the wild.
• The community reacts: LWN.net passed on the PHP security team's advice that all users should prepare now so they can upgrade as soon as the release is available. Researchers have started calling the pair "php2shell." That nickname comes from the research community, not from PHP.

The leak exposed only that the flaws exist, a severity score, a date and two identifiers. It did not reveal the technical mechanics.

Who is affected

The honest answer is that nobody outside the embargo knows yet. PHP has said that full details, the affected versions and the fixed versions will come out with the release itself.

The claim that everything since PHP 5 is vulnerable came from the leak, and it has not been confirmed. watchTowr's own FAQ about the flaws says this scope has not been confirmed by an official vendor advisory. The FAQ also says no configuration or feature requirement has been described, so it is not known whether a particular setup is needed for a server to be at risk.

Whatever the affected range turns out to be, PHP issues fixes only for its four supported branches:

• PHP 8.4 and 8.5: in active support.
• PHP 8.2 and 8.3: receive security fixes only.

Several trackers, including Alpine Linux and security researcher Kevin Beaumont, expect the patched releases to be PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These would be the next point release on each branch. PHP has not confirmed those numbers.

Older branches, including 8.1, 8.0, 7.x and 5.x, are end of life, which means PHP no longer maintains them. If the flaws do reach those versions, PHP will not ship a fix for them. Security company Mallory counted roughly 884,000 internet-facing hosts on October 20 whose web server banner reported PHP 8.1 or older to the Shodan search engine. That is about 59% of the approximately 1.5 million hosts that reported any PHP version. A further 740,000 hosts reported PHP without giving a version. Mallory's count is based on self-reported banners, so it does not confirm that any of those systems are actually vulnerable.

The sources do not single out any particular industry or region. Because PHP powers a very large share of websites and is bundled inside many other products, the potential reach is broad.

How it works

Technical details have not been published, so it is not possible to explain the exact mechanism. Here is what the available labels mean.

Remote code execution (RCE) is one of the most serious types of software flaw. It means an attacker who can reach a vulnerable system over a network may be able to make it run instructions of their choosing. On a web server, that could let an intruder read data, change the website, or use the machine as a foothold for further attacks. The nickname "php2shell" suggests this kind of outcome, where an attacker goes from PHP to a command shell on the server. However, the name is informal and is not a technical description from PHP.

PHP is a programming language that runs on web servers to build pages on the fly. It typically runs through components such as php-fpm or php-cgi, which work alongside web servers like Apache. That is why defenders are being told to watch for those processes behaving unusually.

How serious is it?

PHP rates both flaws 9.2 on version 4.0 of the CVSS scale. CVSS is the Common Vulnerability Scoring System, the industry-standard 0 to 10 severity measure. The 10.0 figure that circulated online came from the leaked post, not from PHP. Where the two differ, PHP's own 9.2 rating is the authoritative one available. Researchers are using the identifiers CVE-2026-109618 and CVE-2026-109619, which also appeared in the leak, but PHP's notice does not name either one.

On exploitation, the sources agree that there are no signs of active attacks yet:

• Huntress said that, as of October 20, it had seen no exploitation in its partner environments. It also said it had not built or reproduced a proof of concept and knew of no public exploit code.
• watchTowr's FAQ listed exploitation as none reported as of October 21. It also noted that the flaws were not in CISA's Known Exploited Vulnerabilities catalogue, the US government list of bugs known to be under attack.

That calm may not last. When CVE-2024-4577, a flaw affecting PHP in CGI mode on Windows, became public in June 2024, Akamai recorded exploit attempts against its honeypot servers within 24 hours. Honeypots are decoy systems set up to attract attackers.

What to do now

PHP has not published any workaround, so preparation is the main defence before the patch arrives. The steps below draw largely on guidance from Huntress and CERT-EU, the EU institutions' cybersecurity team.

For administrators

• Find every copy of PHP. Include PHP hidden inside vendor appliances, Windows software and hosting control panels such as cPanel and Plesk.
• Be ready at 14:00 UTC on October 21. Patch internet-facing systems first.
• Check for backports. Your Linux distribution or hosting provider may ship the fix in its own packages, a practice called backporting.
• Deal with unsupported versions. If you are on an end-of-life branch, upgrade. If you cannot do that yet, take the system off the internet or place it behind a VPN or web application firewall until you can.
• Consider isolation. Where immediate patching is impossible, CERT-EU advises considering cutting internet-facing applications off from public networks until a fix exists.
• Monitor PHP processes. Set alerts for php-fpm, php-cgi, httpd or apache2 starting shells, script interpreters or download tools. On Linux servers without endpoint detection software, Florian Roth's process-watcher tool logs every program a PHP process launches, along with its command line. It only records activity after a program starts, and Roth himself says it "prevents nothing."
• Respond to anything suspicious. Isolate the server, preserve web server and PHP logs, and look for web shells, unexpected files in the web root, new cron jobs, scheduled tasks or user accounts.

For everyday users and small site owners

• If a hosting company runs your website, ask it whether it will apply the PHP update and when.
• If you manage a site through a control panel, check for and install updates once they appear.
• If your site runs on an old PHP version, ask your host about moving to a supported release.

What we still don't know

• How the two flaws actually work, and whether particular settings or features are required for a server to be at risk.
• Exactly which PHP versions are affected, and whether the leak's claim about PHP 5 onward holds up.
• Whether the predicted version numbers for the fixes are correct.
• Whether the CVE identifiers in circulation will be formally tied to these flaws.
• How quickly attackers will move once technical details are public.

ITVedas analysis: The leak shortened the window between public awareness and a patch, and PHP's choice to move first was sensible. The bigger risk is the huge number of servers still running unsupported PHP versions, which may never receive a fix from PHP at all.