Book a Call
Published on

PHP2Shell: The Safest Software Is the One You Can Verify and Fix

First, a few words about Chainguard1,2. I will not use this article to bash them, even though what they did gave the whole community many reasons to. This article is about something else, but they definitely deserved the pushback from the community.

Instead, let me start with something much older. In 1883, the Dutch cryptographer Auguste Kerckhoffs wrote a list of rules for military codes. One of them describes this whole story better than I can:

A system must not require secrecy, and it must be able to fall into the hands of the enemy without inconvenience.3

Auguste Kerckhoffs1883

In simple words: a good system must not depend on keeping its design secret. More than 140 years later, PHP2Shell is a good reminder why. PHP's code was never a secret, so when the bugs were found, everyone could see them, check them, and fix them.

PHP runs on about 70% of all websites whose server language we know4,5. So this problem is much bigger than one project.

In this article, I look at how the bugs were found and fixed. Then I imagine how the same crisis could look if PHP were a closed, proprietary product.

What happened

On October 21, 2026, the PHP project released fixes for two critical security bugs. In some conditions, both bugs let an attacker run their own code on a server without logging in6. Some of the bad code has been in PHP since version 5.4, released in 20127,8,9.

On some common server setups, the attack works before the website's own code even starts. So it does not matter how well the WordPress, Laravel, or Drupal site is protected6.

I have never seen governments react like this before. The US NSA said that websites should go offline if they cannot be updated right away. The UK NCSC and CERT-EU also sent out warnings. CERT-EU said to cut vulnerable websites off from the public internet until the fix is installed10,4.

The Polish army's cyber unit told everyone who uses PHP to update immediately11.

Finland took all its public government websites offline. France did the same with the websites of its Ministry of the Interior and its regional offices. Organizations in Denmark and the Netherlands did the same, including the Dutch government portal Overheid.nl. Japan's cybersecurity office asked everyone to update immediately, and Ireland's cybersecurity center sent out a warning10,5. Some services of the Wikimedia Foundation and the Internet Archive also went offline.

Even I felt the panic. I wrote to friends who run the website of a local school and told them about the problem. I did not want them to wake up the next day and find out that someone had used the bug to play a joke on the school's website.

This is huge!

An open process: audit, coalition, correction

The first signs of one of the bugs appeared in 2024, during an external security review of PHP paid for by the German Sovereign Tech Agency. At that time, nobody knew how to attack through it, and the team could not agree on how to fix it6.

In 2026, the PHP Foundation created a new security team with a grant from Alpha-Omega12. Several companies also checked PHP on their own, some with the help of AI. In August, the security research company Calif and OpenAI reported the same bug on the same day, and Wiz followed two weeks later6,10.

The way the bugs became public was chaotic. Details leaked early, and attackers started right away6,10. But everything happened in public. When people shared a simple settings change as a fix, independent experts could read the code and show that it was not enough4.

Many websites still run old PHP versions that no longer get updates. The PHP project, Linux systems like Ubuntu, and hosting companies made fixes for many of them too10,13,14. Nobody had to wait for one company to decide if old versions were worth saving.

Old rules that still apply

Kerckhoffs, whom I quoted at the beginning, wrote his rule for military codes, but it works for software too. Later, Claude Shannon said it in a shorter way: "the enemy knows the system". In 1999, Bruce Schneier said the same about security software:

A proprietary algorithm, no matter who designed it and who was paid under NDA to evaluate it, is much riskier than a public algorithm.15

Bruce Schneier1999

In simple words: secret code is more dangerous than public code, even if famous experts wrote it or checked it.

His reason was that "before an algorithm can really be considered secure, it needs to be examined by many experts over the course of years". For him, open source is "smart engineering practice"15.

Still, the bug from 2024 was in public code, and it waited almost two years for a fix.

The PHP Foundation's public post-mortem shows this well. The foundation openly said that the delay was "a structural failure", because a consensus-based process blocked the decision for months. Now they will decide by majority vote6.

A company with closed source rarely says something like this in public. The Microsoft example below shows why.

What if PHP were closed source

This part is my own opinion, but each point is based on data about how companies with closed source behave.

Who would find the bug first

Companies with closed source do pay for security research. Google, Microsoft, and Apple run bug bounty programs and pay people who report security bugs. But these people cannot read the code. They can only test the finished program from the outside and look for ways to break it. Only the company can let experts read the code, and then it decides what the public learns about it.

Someone would still find the bug, but probably not someone who reports it. There is a whole market for unknown security bugs, called zero-days. Some companies buy these bugs from researchers and sell ready-to-use attacks based on them, called exploits, mostly to governments. One of the best known was Zerodium. In 2025, it replaced its website with a single page that shows only an encryption key, so it seems to have gone underground16. Similar companies, like Crowdfense, are still active17,18,19. Their buyers use the bugs in secret and do not report them. A bug like PHP2Shell would be worth a fortune there, and nobody would tell the company that owns the code.

There is a well-known example of this. The US NSA knew about a bug in Windows for more than five years, kept it secret, and used it. In 2017, the NSA's tools leaked, and criminals used the same bug in the WannaCry attack. It hit computers in 150 countries and caused more than $8 billion in damage20.

When code is secret, people with enough money to study the compiled program have the advantage. Everyone who needs to protect their servers is left in the dark.

PHP already saw how open code helps against attackers. In 2021, someone broke into PHP's code server and secretly added harmful code. That code even mentioned Zerodium. Because the code was public, people saw the harmful changes and removed them within hours21.

Silent patching

The security company Rapid7 writes that many companies fix security bugs without telling anyone, because they hope this makes attacks harder. It does the opposite. Attackers can compare the old and the new version of the program and find the change.

Rapid7 says that silent patching is like telling the bug only to a small group of people, and most of them want to hurt you. At the same time, the people who run the servers do not know that they must update right away22.

And there is not much time. According to the security company Mandiant, attackers needed on average 63 days to start using a new bug in 2018–201923. In its 2026 report, Mandiant estimates this number at minus 7 days: attackers often use a bug even before a fix exists24. Anthropic shows that AI makes it even faster to find what changed between two versions25.

With PHP2Shell, the PHP project, the NSA, and CERT-EU all warned clearly, so everyone knew from day one that updating was urgent.

End-of-life versions

When a company stops supporting an old version, it can make money from it. Official support for Windows 10 ended in October 2025. Since then, businesses must pay Microsoft for security updates. The first year costs $61 per computer, and the price doubles every year, so the second year costs $12226.

With open source, nobody can stop you from fixing an old version. You can do it yourself, or pay a company that does it for you. For old PHP versions, for example, companies like TuxCare and Zend sell security fixes after official support ends27,28. And if you do not like one company, you can choose another.

Trust

A US government cybersecurity board looked at how Chinese hackers broke into Microsoft in 2023. It said that the attack "should never have happened" and was the result of "a cascade of security failures"29.

Microsoft also told the public how the hackers got in. Soon after, it turned out that Microsoft could not prove this. Still, Microsoft corrected its public explanation more than six months later, and only after the cybersecurity board pushed it to do so30. Nobody outside Microsoft could check what really happened. With closed systems, you can only trust what the company says.

With PHP2Shell, everything was public, from the fixes in the code to the post-mortem.

Who answers when something breaks

Two weeks before PHP2Shell, I spoke at Open Source Conference Luxembourg together with Florence Njeri. We are both maintainers of the AsyncAPI Generator. We talked about two supply chain attacks that hit AsyncAPI in the last 12 months.

We did not want to show only the technical details. We wanted to share the real story: who actually responds when a security problem hits an open source project, and how fragile that is. In the case of AsyncAPI, these are all volunteers. When an attack happens, they still have their day jobs and their everyday stress, and on top of that, they try to keep the project safe.

PHP2Shell is simply a much bigger version of the same story. It is not the only one, it is not the first one, and it will surely not be the last one.

Takeaways

Open source has bugs like any other software. But when a bug appears, open source gives everyone the tools to find it, understand it, and fix it. With closed source, only the company that owns the code has these tools. Public code takes away the advantage that secret code gives to attackers.

This crisis also showed how little money goes into the software that runs the internet. The PHP Foundation got about $731,000 in 202531. According to The Guardian, it has only 13 full-time and part-time employees and depends on financial contributions32. Now let me remind you what I mentioned at the beginning: PHP runs on about 70% of all websites whose server language we know. Banks and governments depend on this work.

The review paid by the Sovereign Tech Agency and the grants from Alpha-Omega are the first examples of money that helped here.

Turning off servers was the right decision this time. But it should not become a habit. It should be a one-time lesson that makes us all sit together and finally do something about open source funding.

At Open Source Europe, we want to be part of this and help explore different options.

Open code is the first step to security. To be enough, it needs regular money.

Footnotes

  1. Techzine, PHP accuses Chainguard in PHP2shell ↩

  2. ITdaily, PHP Foundation angered by 'clumsy' disclosure of vulnerabilities ↩

  3. Wikipedia, Kerckhoffs's principle ↩

  4. Tenable, php2shell: Frequently asked questions about critical PHP remote code execution vulnerabilities ↩ ↩2 ↩3

  5. The Journal, Number of websites taken down across Europe in response to global cybersecurity alert ↩ ↩2

  6. PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. Sansec, PHP2Shell: Critical PHP RCE ↩

  8. Cloudflare, Cloudflare deploys protections against php2shell vulnerability ↩

  9. CrowdStrike, CrowdStrike Protects Customers from Threats Delivered via PHP2Shell ↩

  10. Wikipedia, PHP2Shell ↩ ↩2 ↩3 ↩4 ↩5

  11. Polish Cyberspace Defense Forces, Warning about CVE-2026-109618 and CVE-2026-109619 (in Polish) ↩

  12. PHP Foundation, Announcing the Ecosystem Security Team ↩

  13. Ubuntu, php2shell (CVE-2026-109618 and CVE-2026-109619) – PHP critical vulnerability fixes available ↩

  14. CloudLinux, PHP CVE-2026-109618 and CVE-2026-109619: CloudLinux Package Status and Imunify360 Protection ↩

  15. Bruce Schneier, Open Source and Security, Crypto-Gram, September 1999 ↩ ↩2

  16. Wikipedia, Zerodium ↩

  17. 9to5Mac, Here's how much zero-day hacks for iPhone, iMessage, and more are worth ↩

  18. TechCrunch, New zero-day startup offers $20 million for tools that can hack any smartphone ↩

  19. Crowdfense, Blog ↩

  20. Wikipedia, EternalBlue ↩

  21. BleepingComputer, PHP's Git server hacked to add backdoors to PHP source code ↩

  22. Rapid7, The Hidden Harm of Silent Patches ↩

  23. Mandiant, How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends ↩

  24. Mandiant, M-Trends 2026: Data, Insights, and Strategies From the Frontlines ↩

  25. Anthropic Red Team, N-days ↩

  26. Microsoft Learn, Extended Security Updates (ESU) program for Windows 10 ↩

  27. TuxCare, Extended Lifecycle Support for PHP ↩

  28. Zend, PHP Long Term Support ↩

  29. TechTarget, Cyber Safety Review Board slams Microsoft security failures ↩

  30. CyberScoop, Cyber review board blames cascading Microsoft failures for Chinese hack ↩

  31. PHP Foundation, The PHP Foundation Impact and Transparency Report 2025 ↩

  32. The Guardian, What is PHP, and how bad is the computer language flaw causing website shutdowns globally? ↩