PHP2Shell PHP vulnerabilities already have patches: how to prioritize the work

The PHP2Shell PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, led several European government, school and hospital websites to go offline as a precaution on 21 October, according to SecurityWeek [1]. Two days later, the same outlet still had no record of a single successful intrusion [1].

That gap between alarm and facts explains the moment well. PHP2Shell is a serious but bounded threat. It calls for neither panic nor blind confidence, but for a work order: know which PHP you run, patch it, keep the recommended mitigation in place and isolate whatever cannot be updated.

Two critical flaws with patches and no confirmed intrusions

What is confirmed fits in a few lines. According to SecurityWeek, PHP2Shell groups two flaws in the PHP engine that allow unauthenticated PHP remote code execution, each with a CVSS v4.0 score of 9.2 [1]. The same outlet explains that Wiz, OpenAI and Calif found them in August and that PHP fixed them on 21 October 2026 with versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP 8.5.12 patch and its sibling releases arrived a day earlier than planned because the CVE identifiers had leaked online [1].

The leak did not ruin the process. Johannes B. Ullrich, identified in the source as dean of research at SANS.edu, stresses that many vendors published their patches in sync with PHP.net [2]. In his view, this shows that coordinated disclosure worked, even if some actor broke the rules and brought details forward [2]. BleepingComputer adds that, after the leak, several security companies detected failed exploitation attempts even before public disclosure [4]. SecurityWeek places the first of those attempts, observed by Amazon, on 17 October [1].

The other half of the picture is what has not happened yet. SecurityWeek reports that no vendor had communicated a confirmed compromise [1]. It also notes that, on the morning of 23 October, CISA had not yet added either flaw to its Known Exploited Vulnerabilities (KEV) catalog [1].

Exploitation attempts are running ahead of results

There is a long way between noise and signal. An analyst at the SANS ISC reviewed the published proofs of concept and concludes that building a universal, reliable, one-click exploit is quite difficult [3]. The analyst adds that much of that material appears to be AI-generated and of poor quality [3].

According to that analysis, the proof of concept considered most sensible depends on several preconditions [3]:

• a POST request with a very large number of fields to force memory allocation;
• a memory limit far below the usual one in production;
• a single worker process on the server;
• advance knowledge of details of how PHP was compiled on that machine.

This is not an isolated case. According to SecurityWeek, Sansec had anticipated almost immediate mass exploitation after the patch, but revised that view on 22 October [1]. In its new assessment, attackers need to know the server well and specific conditions must be met, and public exploits fail against installations with the default configuration [1]. Sophos, cited by the same outlet, reads the lack of successes as a sign that attackers are also struggling [1].

Even so, it would be a mistake to read all this as a theoretical risk. SecurityWeek reports that Sophos analyzed an attempt to install Potassium that was stopped; the company considers it a Mirai variant able to download more malware and launch DDoS attacks [1]. VulnCheck claims to have built an exploit for CVE-2026-109618 that bypasses address space layout randomization (ASLR) on x86-64 systems with the configuration recommended for production [1]. The exploit is available to customers of VulnCheck's Initial Access Intelligence [1].

Attackers are also working on the same thing. SOCRadar found an attacker server with its working files in plain view [1]. It contained an exploitation chain tested in a lab and scripts to check which real websites met its requirements [1]. None of the sites it reviewed did [1].

The SANS ISC itself adds a further warning. There appears to be a way to bypass even the available fix, which is why it recommends keeping the session.upload_progress.enabled = 0 workaround in place until the next update [3]. Ullrich sums it up: the vulnerability and the risk are real even though mass exploitation has not arrived yet; it is simply being delayed [2].

Inventory comes first because PHP is almost everywhere

You cannot patch what you don't know exists. According to BleepingComputer, PHP runs behind roughly 70% of websites [4]. The outlet also cites VirusTotal estimates: more than 5.1 million PHP hosts exposed on the internet, of which about 3.8 million have at least one open port [4]. These are estimates from those sources, but they give an idea of the scale.

The most uncomfortable figure comes from Qualys. According to SecurityWeek, which cites its analysis, around 71% of PHP instances run versions from 5.4 to 8.1, already out of support [1]. Most will never receive a patch from the vendor [1].

The inventory should let you identify where PHP runs. It is worth reviewing the corporate website, intranets, administration panels, supplier applications and devices with a web interface to check whether they use PHP. The SANS ISC reminds us that embedded devices and appliances are a particular concern, because many have not been updated or are unlikely ever to receive a patch [2].

A work order for the technical team: patch, mitigate and isolate

With that map in hand, the reasonable sequence is this:

1. Inventory PHP applications and versions, including those bundled inside third-party products.
2. Apply the patch where one exists. According to SecurityWeek, the fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, depending on the branch [1].
3. Keep the mitigation session.upload_progress.enabled=0 in place. According to the SANS ISC, PHP.net advised keeping it until the next update [2].
4. Isolate or segment whatever cannot be updated and reduce its exposure to the internet to a minimum.
5. Look for signs of post-exploitation command execution in PHP web processes.

What can be updated

For anything still supported, the SANS ISC is blunt: applying the patch remains the best defense and the only reliable one [2]. Workarounds and web application firewall (WAF) rules can buy time, but none is considered fully effective [2]. That is why a configuration mitigation does not replace the patch. It accompanies the patch while PHP finishes closing the problem.

What cannot be updated

Unsupported versions and embedded devices call for a different logic. If they cannot be updated, the SANS ISC recommends isolating the vulnerable applications [2]. It also reminds us that administration interfaces of routers, network storage devices or cameras should not be exposed to the internet, whether they use PHP or not [2].

This is where it makes sense to isolate industrial equipment that cannot be updated with segmentation designed for that context.

Source [5] offers a hunting query for post-exploitation command execution on PHP servers. It looks for reconnaissance commands, file downloads or reverse shells launched from processes such as Apache or PHP-FPM [5]. The team itself warns that it is not specific to these two CVEs and that it can produce false positives depending on the applications [5]. Every finding has to be validated.

CVE-2026-115560 is a different matter: no patch and an uncommon configuration

It is best not to mix up cases. BleepingComputer reports that the PHP security team shared mitigations for CVE-2026-115560, a separate remote code execution flaw that had no patch at the time of the report [4].

According to the advisory the outlet cites, it is only exploitable with an unusual combination of configuration and code [4]. The application has to set session.serialize_handler to php_binary or php_serialize and change it to php at runtime with ini_set() before calling session_start() [4]. In addition, session upload progress must still be enabled [4].

The mitigation matches that of PHP2Shell: disable session.upload_progress.enabled. PHP states that anyone who has already applied it needs to do nothing more [4]. The PHP team announced that it would address this flaw within the normal release cycle [4]. Since the report predates any patch, it is worth checking the official advisory to see whether an update already exists.

Taking a website offline as a precaution is a risk decision, not a failure

Deciding on the availability of a service before the patch is applied has a visible cost. SecurityWeek reports that the UK government reported 32 services unavailable on 21 October, and others working only partially [1]. The cause was mostly precautionary measures while patches were being applied [1]. SecurityWeek does not report confirmed compromises and attributes most of those interruptions to preventive measures during patching [1].

That choice is legitimate when you don't know what is exposed or how long the patch will take. Preparing the inventory and rehearsing an urgent patching procedure makes such decisions easier. The SANS ISC describes PHP2Shell as a dress rehearsal for what is to come and encourages tabletop exercises and keeping inventories up to date [2].

Patching closes the door; monitoring confirms nobody got in first

There were exploitation attempts before many organizations applied the patch, so updating is not enough to rest easy. It is worth reviewing logs and the behavior of web processes for anomalous execution. The Unit 42 query is a good starting point, with the caution of possible false positives [5].

With PHP2Shell, the useful response is neither to shut everything down nor to wait and see. It is to know which PHP you run, patch it, keep the mitigation in place and isolate whatever cannot be updated.

If you want to review what is exposed, consider a pentesting exercise. Consider complementing patching with continuous monitoring through a managed SOC.