PHP2Shell: taking stock

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the core of PHP, registered as CVE-2026-109618 and CVE-2026-109619¹. PHP is the programming language that does the work on the server side of a website: handling logins, processing payments, fetching data from a database. PHP is big, really big: it is the technology underneath WordPress, Wikipedia and Laravel (the framework we work with a lot), among many others. PHP also runs inside network equipment, admin panels and other devices with a web interface¹.

The vulnerability isn't in a single website or plugin, but in the engine underneath. An attack takes at least two steps. First, the attacker sends a specially crafted request that makes PHP run out of memory at exactly the wrong moment. PHP crashes and doesn't clean up its memory properly. Because of that bug, a follow-up request can read parts of the memory and abuse them to run the attacker's own malicious code². That last part is called remote code execution (RCE): running code on someone else's server from a distance. It lets you make the server do (almost) anything you want.

Because the vulnerability sits in that underlying engine, and not in the framework or the application built on top of PHP, every server running PHP with this bug is vulnerable. Every PHP version from the past ten years is affected, going back to PHP 5.4 (we're now at 8.5)³. According to W3Techs, PHP powers 69.2% of all websites whose server-side language can be determined⁴. The Dutch National Cyber Security Centre (NCSC) warned of a very high risk of complete system takeover¹, and Wiz puts PHP2Shell in the same league as Heartbleed (2014) and Log4Shell (2021)³.

Found with AI

PHP2Shell was found with the help of AI. Researchers from Calif, OpenAI and Wiz each reported the problem to PHP independently in August 2026². Wiz used AI models including Gemini 4 Argon and GPT-5.6 Sol³.

The problem wasn't entirely unknown. During an external security audit in 2024, a PHP specialist already spotted the first signs, but nobody found a concrete way to attack it. The security team found several possible fixes, but each came with its own drawbacks. As a result, they couldn't immediately agree on the best patch, so the work stalled and restarted for months. The PHP Foundation itself calls this a structural failure, caused by the way decisions were made and a lack of people and resources².

AI changed that equation. According to Wiz, a single researcher using AI models did in one week what would previously have taken a team of top professionals months³. Complexity is no longer a defense: a vulnerability that used to be essentially too hard to exploit is now a real risk, thanks to AI models.

What happened on October 21?

On October 21, 2026, PHP2Shell became public before everyone was able to install the patch. That turned the day into a race between administrators and attackers.

With a serious vulnerability, things normally go differently. The vulnerability is kept secret, and a small group of trusted parties (such as maintainers of Linux distributions, security companies and hosting providers) receives the patch in advance under embargo. At an agreed moment, everything goes live at once, so everyone can update right away. That moment is crucial: as soon as a patch is public, attackers can see what has changed, and therefore where to look for the vulnerability.

With PHP2Shell, that coordinated release fell apart²:

The video gave attackers extra clues, and Chainguard's early release let them study the fix while the rest of the world was still waiting. The PHP Foundation writes that Chainguard thereby disregarded weeks of work by many parties².

Websites go dark

Large organizations around the world took their websites offline as a precaution, because the vulnerability was known but the patch wasn't available yet. The Dutch NCSC advised making a risk assessment for each system, with switching off systems or specific features as a possible measure¹. System administrators weigh the likelihood of a breach against its consequences; for large, critical systems that many people rely on, such as government services, the impact of a hack is far greater than for small commercial systems. In the Netherlands, MijnOverheid, DigiD, the House of Representatives, the NCSC itself, the Dutch Data Protection Authority, RTL Nieuws and Tweakers all went offline temporarily for that reason, as did Notubiz, which a hundred municipalities use for their meetings⁵. Elsewhere in Europe, in Asia and in North America, websites of governments, schools and hospitals also went offline for a while.

How Dutch Coding Company handled it

On October 21, we closely followed the NCSC's advice and weighed, for each system, the risk of staying online against the cost of going offline:

• Non-critical and internal systems: we took these offline right away. A few hours of downtime doesn't outweigh the risk.
• Client production systems: we kept these online. We assessed the risk for each client and monitored all day for exploitation attempts and for news of successful attacks.

After the release at 16:00, we had most systems updated within ten minutes. Two systems took a little longer because of extra dependencies, such as PHP variants for which the patch only became available later.

What is the danger?

The danger of PHP2Shell lies in three properties combined:

1. No login required: the attacker doesn't need to log in or know any passwords. If the application is connected to the internet, it is already vulnerable.
2. No bug in the application required: an attack doesn't depend on a flaw in the specific application, because PHP itself is vulnerable.
3. Full control: the attacker can take over the entire server.

A simple POST request, the kind your browser sends when you fill in a form or log in, is enough to trigger the memory crash¹. In practice, an attack uses a short series of requests: the first puts PHP in a vulnerable state, the next ones exploit it⁶. All of this can be fully automated, so an attacker can automatically try to break into millions of servers. It's a shotgun approach.

What can an attacker do with RCE?

RCE is one of the most damaging types of hack. An attacker who runs code on a server through RCE can, in principle, do anything the web application itself can do, and often more:

• Steal data: customer data, orders and passwords from the database, as well as API keys and access to other internal services.
• Plant a backdoor: with a so-called webshell, the attacker can keep running code on the server later on, even after it has been patched.
• Move deeper into the network: once inside, the server becomes a stepping stone to internal systems that aren't reachable from the internet.
• Use the server for other attacks: cryptomining, sending spam and phishing, or joining a botnet (a large number of servers carrying out an attack at the same time).
• Sell the access: so-called initial access brokers resell access to hacked servers, for example to ransomware gangs.

In effect, it's every kind of hack rolled into one.

How much has been patched?

A week after the patch, a large share of vulnerable systems still hasn't been updated. A system running PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or newer) is fully protected against PHP2Shell². Patching closes the door, but if a breach has already happened, the attackers may have left backdoors behind. It's wise to check your logs for possible intrusion attempts.

PHP is an extremely widely used programming language. Far from every server is well maintained, so many servers run an outdated version of PHP for which no patch will be released. Security company Wiz found that one week after the patch became available, about 53% of affected organizations were still vulnerable⁶.

A large part of the problem lies in outdated PHP versions. Only PHP 8.2 through 8.5 received an official update. For 7.4, 8.0 and 8.1, the PHP security team only published the patched source code, which some Linux distributions and extended support vendors have rolled out. PHP 7.3 and older get nothing. That affects a lot of websites: according to W3Techs, 34.3% of PHP websites still run on PHP 7 or older⁴. If you're on one of those versions, you really need a full upgrade. That is often far from simple and requires changes to the application itself. Organizations that are behind on maintenance therefore stay vulnerable much longer. On top of that, PHP is sometimes built into equipment and software packages from vendors; for those, you depend on the vendor for an update¹.

Are we seeing hacks yet?

Yes: there are confirmed, successful attacks using PHP2Shell, though not yet at large scale. The number of attempts is huge. Within a day of the disclosure, Cloudflare, one of the largest internet companies in the world, saw millions of attack attempts⁷. The vast majority fail, because the attack is complex and depends on the specific server configuration and the amount of traffic on the server⁶.

Still, attacks are succeeding more often. Researcher Adel Karimi documented how attackers used PHP2Shell to run code on his honeypots (decoy servers that are deliberately easy to hack). A "Steal my Bitcoin" challenge has also been successfully hacked by now⁸. The US cybersecurity agency CISA added PHP2Shell to its list of actively exploited vulnerabilities as early as October 26, 2026⁶. And we may not know the half of it: a skilled attacker makes very little noise.

25 servers taken over through outdated firewalls

The clearest example is a sophisticated attack that research firm Dream uncovered on October 25, 2026⁹. The targets were Palo Alto Networks firewalls. Their management interface runs on PHP 8.0, a version that hasn't received security updates since November 2023. Palo Alto Networks attributes the attack to a Chinese-speaking threat actor, who combined PHP2Shell with a second vulnerability, in Linux, to gain access to the entire server:

1. Reconnaissance: using a specialized search engine, the attacker found around 19,000 of these Palo Alto Networks firewalls.
2. Selection: after filtering by country (United States, Japan, Taiwan and South Korea) and software version, 240 targets remained.
3. Takeover: 24 firewalls were fully compromised. On 22 of them, the attacker only left a backdoor for later use.
4. Infiltration: two firewalls belonged to an organization affiliated with the US government. Through a tunnel, the attacker got into the internal network and took over a third, internal server: number 25.
5. Exploitation: from there, the attacker stole the credentials of a service account and pulled the full list of users and groups in the network. The attacker then tried to guess passwords and create backdoor accounts.

This attack took less than fifteen minutes from start to full control of the server⁹. If you plan to respond in real time, you're guaranteed to be too late. You need to protect yourself in advance.

Dream couldn't determine whether those final steps succeeded. But the case does show how a single management interface running an outdated PHP version can open the door to highly sensitive systems. With an up-to-date PHP version, this attack would have failed. Palo Alto Networks customers, however, couldn't update PHP themselves: they had to wait for a new version from the vendor.

What is yet to come?

We think the biggest wave of PHP2Shell attacks is yet to come. Right now, many attackers are tripping over the technical details, but the attacks keep improving, which makes them easier and easier to roll out at scale. Wiz also expects experienced hacker groups to refine and automate the attack⁶. The large number of organizations that haven't patched yet are attractive targets.

Botnets, spam and phishing

We expect a wave of opportunistic attackers: botnet operators, cryptominers and initial access brokers who plant a backdoor to resell that access. There are already examples. Attackers tried to use PHP2Shell to add servers to Potassium, a variant of the Mirai botnet. By adding large numbers of servers to this botnet, an attacker can launch a coordinated attack from thousands of servers at once (a DDoS), overloading a system until it becomes unreachable. These first attempts have failed so far, but they show where things are heading⁷.

The risk comes from the large number of small, poorly maintained servers running old versions of PHP. Think of an association's old WordPress site, an outdated web shop or a forgotten test environment. On its own, a server like that isn't an interesting target, but hackers can recruit it for use in other attacks:

• Spam and phishing: emails and phishing pages sent from an existing, trustworthy-looking domain get past spam filters more easily than those from a brand-new address.
• Botnets: thousands of compromised servers together can take down large websites and services.
• Camouflage: attacks appear to come from an innocent business instead of the real attacker.
• Background revenue models: cryptomining at the owner's expense, or reselling the access.

It's likely that these small servers will remain vulnerable for months and become a regular target of automated scans. Observers compare PHP2Shell to Log4Shell from 2021, a vulnerability that was still being exploited years later.

What can we learn from this incident?

As AI gets better at finding security issues like PHP2Shell, they will come up more and more often. The time you have to respond is shrinking too. AI makes it easier to find vulnerabilities, for defenders and attackers alike.

You can see this in the numbers: an unprecedented number of vulnerabilities is being found right now. Since July 1, 2026, the PHP security team has published fifteen CVEs (official registrations of a vulnerability)². And although you may not have seen it in the news, a similarly critical vulnerability was found that same week in Brotli, a compression technology used in Node.js, Python and Microsoft's .NET. GitLab rushed out fixes twice within two weeks for vulnerabilities that let attackers take over a server.

Fast updates matter more than ever

If you only patch vulnerabilities like this after days or weeks, you're taking an ever-growing risk. With PHP2Shell, attack attempts started before the patch was even available, and grew to millions of attempts within the first hours after the release. To update quickly, you need to be prepared:

1. Know what you're running: keep an inventory of all your systems, including the versions of PHP and other components. You can't patch what you don't know about.
2. Stay up to date: if you're on an outdated version, you won't get an update during an incident, and you'll be forced into a much larger upgrade under time pressure.
3. Make updating routine, and preferably automated: with an automated update process, a patch goes live within minutes instead of days.

Conclusion: AI will make this happen more and more often

A vulnerability like PHP2Shell is extraordinarily complex. It's precisely the arrival of ever more powerful AI models that makes exploiting complex vulnerabilities like this not only possible, but increasingly easy. The race between defenders and attackers is as old as time, but it is now accelerating at an unprecedented pace.

In the end, being able to update quickly is your best weapon. That means keeping your code under control: run up-to-date versions so you're first in line when a patch comes out, and make sure your code is well maintained. That control gives you speed, not just when building new features, but also when fixing bugs and security issues. An application that hasn't been touched in years often can't be patched quickly without first clearing part of the maintenance backlog.

Maintenance can feel like a cost without visible results – until the moment it matters. When you need to act fast, you want your codebase under control. We help you bring outdated systems up to date and bring speed back into your software project. Curious how your software is holding up? Read more about how we work or get in touch for a no-obligation introduction.