The PHP2Shell Patch Is Out. About Three in Four Exposed PHP Servers Can't Get It.
Two critical PHP flaws were exploited before the fix arrived, and CISA now lists them as attacked in the wild. The patch only covers PHP 8.2 to 8.5. Of internet-facing PHP servers that reveal their version, roughly 74% to 79% run an older branch that gets no fixes at all.
Sources: Modat and VirusTotal data, via Recorded Future (October 2026); W3Techs, 3 November 2026.
On 21 October 2026, the PHP project released emergency fixes for two critical flaws in the core of the language, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Two days later the FBI issued a public alert, and on 26 October the US Cybersecurity and Infrastructure Security Agency (CISA) confirmed the flaws were being exploited in real attacks.
PHP runs 69.1% of all websites whose server-side language is known (W3Techs, 3 November 2026). That makes any flaw in PHP itself a very large problem. But the bigger story is in the version data: the fix only exists for PHP 8.2 to 8.5, and most exposed PHP servers run something older.
What PHP2Shell is, in plain terms
Both flaws are memory-safety bugs in the PHP engine itself, in how it sets up, handles errors in and cleans up the memory for each web request. In certain conditions, PHP can keep using memory it has already freed or not fully set up. A carefully crafted request can turn that into the ability to run the attacker’s own code on the server (Recorded Future, October 2026).
The name reflects the worst case. A web shell is a small script an attacker plants on a web server so they can send it commands later, like a hidden remote control. Flaws that allow remote code execution are a common way to plant one. That is why the FBI advises administrators to watch for PHP processes that start command shells or download files (FBI IC3, 23 October 2026).
Researchers at Wiz, who found the flaws, showed that attackers could take control of servers running WordPress, Drupal and Joomla without logging in. Those three systems run a large share of the web.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Type of bug | Memory left partly set up after an out-of-memory error | Leftover references to memory that has already been freed |
| Severity (CVSS 4.0) | 9.2 | 9.2 |
| Login needed? | No | No |
| Shown against | WordPress, Drupal, Joomla | WordPress, Drupal |
| Listed by CISA as exploited | 26 October 2026 | 26 October 2026 |
Sources: Recorded Future; CISA Known Exploited Vulnerabilities catalog.
The timeline: attackers moved before the fix
The flaws were reported privately to PHP in August. The fix was scheduled for 21 October, but details leaked first, and attackers were already testing them.
- 19–24 AugFound and reportedWiz finds the first flaw, confirms takeover of Drupal and WordPress, and reports it privately to PHP.
- 17 OctFirst attack attemptsAmazon sees exploitation attempts against its honeypots, four days before the patch.
- 21 OctLeak, then fixLeaked details appear online at 02:29 UTC. Hosting firms report attacks by 07:34. PHP ships the fix at 13:52.
- 23 OctFBI alertThe FBI urges immediate updates. PHP warns of a third, separate flaw that has no patch yet.
- 24–25 OctTakeover confirmedA researcher documents successful code execution on honeypots running PHP 8.4.26.
- 26–29 OctCISA deadlineCISA lists both flaws as exploited and gives US federal agencies three days to fix them.
Sources: Recorded Future; BleepingComputer, 22 October, 24 October and 26 October 2026; FBI IC3; CISA.
Two points stand out. From private report to public fix took about two months, which is normal for a careful fix in a core language. But once details leaked, the gap between disclosure and attack was measured in hours. Early attempts were mostly unsuccessful, and the first confirmed takeover was on a deliberately favourable test setup. Still, that was enough for CISA to treat it as an active threat.
The real gap: who can actually install the fix
The PHP project only fixes branches it still supports. On 21 October, that meant four:
| PHP branch | Fixed version | Security fixes until |
|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 |
| 8.4 | 8.4.27 | 31 Dec 2028 |
| 8.3 | 8.3.36 | 31 Dec 2027 |
| 8.2 | 8.2.35 | 31 Dec 2026 |
| 8.1 and older | No fix | Ended (8.1 on 31 Dec 2025, 7.4 on 28 Nov 2022) |
Sources: PHP supported versions; PHP end-of-life branches; fixed versions from Recorded Future.
Anyone on PHP 8.1, 8.0, 7.x or 5.x has no official patch to install. Recorded Future’s advice is explicit: older branches “should not be assumed safe.”
So how many servers are in that position? Two internet scans give a consistent answer:
Most servers hide their version, so the split between supported and end-of-life is based on the 1.03 million that show it. The newest release is the one from 24 September, the last before the fix. Source: VirusTotal data, via Recorded Future.
A second scan by Modat, covering 4.38 million PHP services on 1.89 million hosts, found that 79% of the services that show their version run an unsupported branch. The single most common old version is PHP 7.4, with about 879,000 services, even though it stopped getting security fixes almost four years ago.
The website-level data points the same way. Among sites that use PHP, W3Techs counts 26.3% on PHP 7 and 7.6% on PHP 5, both completely end-of-life. That is a lower bound, since some of the 66.0% on PHP 8 are on 8.0 or 8.1, which are also end-of-life.
PHP 8 includes 8.0 and 8.1, which are end-of-life, as well as the supported 8.2 to 8.5. Source: W3Techs, 3 November 2026.
These numbers come with an important caveat. A server that shows an old version number is not automatically vulnerable, because some Linux distributions and hosting companies apply security fixes to older versions without changing the number. But it does mean the public fix from PHP does not apply to them directly, and their owners need to confirm with their vendor that they are covered.
Why one web server can expose much more
A compromised web server is often a way into everything around it. VirusTotal’s data shows how many PHP servers also expose other services directly to the internet:
Source: VirusTotal data, via Recorded Future.
An attacker who gets code running on such a server can often read the database passwords stored in the website’s configuration, and use them to reach other systems. That is why the FBI and Recorded Future both advise rotating credentials on any server that shows signs of compromise.
What to do now
The guidance from the FBI, CISA, the UK’s National Cyber Security Centre and the PHP project is consistent:
- Update now to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If that is not possible right away, the FBI advises taking the system offline until it is fixed.
- Move off end-of-life branches. If you run PHP 8.1 or older, there is no official fix. Upgrading to a supported branch is the only complete answer. Note that PHP 8.2 stops getting security fixes on 31 December 2026, so 8.3 or newer is the safer target.
- Find PHP you didn’t know you had. PHP is often bundled inside other products, containers and appliances. The FBI asks organizations to inventory every place PHP runs, starting with internet-facing systems.
- Look for signs of a web shell. Check for new or changed PHP files in website folders and upload directories since 20 October, and for PHP processes starting command shells.
- Watch for the third flaw. PHP disclosed a separate flaw, CVE-2026-115560, on 23 October. It has no patch yet, and only affects an unusual combination of settings. PHP’s interim advice is to set
session.upload_progress.enabled=0.
For website owners on shared hosting, the simplest step is to check which PHP version your site runs in your hosting control panel and switch to a supported one if your host offers it.
Key terms
- PHP: a programming language that runs on web servers and powers most websites, including WordPress.
- Remote code execution (RCE): a flaw that lets an attacker run their own code on someone else’s computer over the network.
- Web shell: a small script an attacker plants on a web server so they can control it later.
- End-of-life (EOL): a software version that no longer receives security fixes from its maker.
- CVSS: a 0-to-10 scale used to rate how severe a vulnerability is. 9.0 and above is “critical.”
- CISA KEV catalog: the US government’s list of vulnerabilities known to be exploited in real attacks.
Notes on the data
- Server counts come from internet scans by VirusTotal (IP addresses, 21 October 2026) and Modat (services seen in the 10 days before 20 October 2026), as reported by Recorded Future. Scans count different things and are not directly comparable, which is why the share on end-of-life branches is given as a range (74% to 79%).
- The 74% figure is our calculation from VirusTotal’s counts: 758,000 end-of-life out of 1.03 million servers on a known branch.
- Most PHP servers hide their version, so the shares describe the servers that reveal it. Servers that hide it may be more or less up to date.
- A visible version number does not prove a server is vulnerable, since some vendors backport security fixes without changing it.
- Website shares come from W3Techs and describe websites, not servers.
- Confirmed exploitation so far has been shown in specific configurations. How many real-world attacks succeeded is not yet known.
Sources
Official: FBI IC3 – Critical Vulnerability Alert: PHP Core (23 Oct 2026) · CISA Known Exploited Vulnerabilities catalog · PHP – Supported versions · PHP – End-of-life branches
Research: Recorded Future – PHP2Shell exploitation explained · W3Techs – Usage statistics of PHP (3 Nov 2026)
Reporting: BleepingComputer – Amazon says exploitation began 4 days before patches (22 Oct 2026) · BleepingComputer – PHP2Shell flaws now successfully exploited (24 Oct 2026) · BleepingComputer – CISA confirms exploitation (26 Oct 2026)
Every figure in this article links to its source and was checked against that source before publishing. How we check figures