PHP2Shell: Why More Security Updates Are Good News

What Happened on October 21

On October 21, 2026, the PHP team released a security update that affects nearly every PHP website. PHP is the programming language that a server uses to generate a website's pages. Drupal is also one of the many systems built on it.

A statistic from W3Techs illustrates just how widespread PHP is: As of October 21, PHP was running on 69.3 percent of all websites whose programming language is known. JavaScript follows in second place with 8.1 percent.

The vulnerabilities are known as PHP2Shell. On the standard scale from 0 to 10, they have a severity rating of 9.2. Attackers could execute arbitrary code on a server without logging in or read passwords and access keys from memory. The website itself did not need to have any flaws for this to happen; the flaw was in PHP itself. A report by news. ORF. at on millions of attack attempts online shows that this was not just a theoretical possibility.

That sounds like bad news. We see it differently.

Why More Security Updates Are a Good Thing

For over a year now, we have observed that significantly more security vulnerabilities are being discovered and patched than in the past. A major reason for this is artificial intelligence. Security experts and development teams are using it to find vulnerabilities more quickly and thoroughly. 
PHP2Shell is a good example. Researchers from Wiz Research, OpenAI, and Calif discovered the vulnerabilities with the help of AI tools. Versions dating back to PHP 5.4 were affected. The flaw had therefore remained undetected in the code for many years.

Once a vulnerability is found and patched, no one can exploit it anymore. With open-source software, the source code is public, and that’s exactly what makes it so strong: more people and more tools review it. As a result, the software behind your website becomes more secure over time.

Everyone who runs a website knows the downside. Updates come more frequently and often on very short notice. You have to expect this, and you can prepare for it.

How well the coordination worked

There is a well-established procedure for critical vulnerabilities. Researchers report the discovery confidentially, the responsible team develops a fix, and only then is the vulnerability made public. In the early morning hours of October 21, the PHP security team announced the update for that same day. Such advance notices are common for highly critical updates. They are rarely given on such short notice.

Things didn't go quite according to plan this time. Information about the vulnerability had already been leaked. Still, the chain held. The PHP team released the fix that very same day.

For those who want the exact details: Two officially registered vulnerabilities, CVE-2026-109618 and CVE-2026-109619, have been patched. The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. There are no longer any official releases for PHP 7.4 through 8.1; only minor fixes in the source code that you must implement yourself. Anyone still running such old versions now has a good reason to upgrade.

In addition, major infrastructure providers stepped in. Google Cloud, Cloudflare, AWS, Microsoft, Upsun, and other partners have prepared guides and temporary protective measures for anyone who was unable to update immediately.

We see this spirit of helpfulness in many open-source communities. On Drupal Slack, the Drupal community’s chat platform, and on Mastodon, the threads were buzzing on October 21. Important information was shared there—openly and visible to everyone. With closed-source software, this kind of open exchange is hardly possible.

What We've Done for Our Customers 

Our team started working on this issue first thing in the morning. Until the new PHP versions were installed, we followed these steps in this order:

1. Preparation. We reviewed the announcement and planned the day's work.
2. Notify hosted customers. Customers whose websites run on our servers received a personal message at noon. The message explained how serious the vulnerability is, that their websites may be temporarily unavailable, and that they do not need to take any action themselves.
3. Prepare managed clients. We have explained to clients whom we manage but do not host what they or their hosting provider need to do.
4. Securing systems. We have temporarily shut down some of the systems. For more critical systems, we implemented protective measures in advance to ensure that the vulnerability could not be exploited until the update was released.
5. Update. After that, we updated the PHP versions. As soon as a website was back online, the issue was resolved for the client.

Why BUZZTION Websites Were Able to Stay Online

For customers who purchase BUZZTION from us, the situation was simpler. BUZZTION delivers the website as static pages. Visitors see pre-rendered pages; no PHP runs when the site is accessed.

The content management system running in the background does indeed require PHP. We were therefore able to shut it down completely until the update was installed. The website itself remained accessible the entire time, and PHP2Shell had nothing to exploit. Content could not be edited during those hours, and that was the only cost.

What We've Done Beyond Serving Our Customers

PHP is used in much more software than just the websites we manage. Many open-source systems run on PHP. The vulnerability itself is patched on the server, but the people who use these systems need to be made aware of it. So, where there hasn't been any discussion about PHP2Shell yet, we've started a thread.
Our goal was to spark an open discussion about the possibilities. That’s more productive than keeping things secret behind closed doors. Above all, it’s important that the projects behind these systems also keep their users and customers informed and guide them through the update. That’s exactly how open source works when it’s done right.

What this means for you

Security updates will continue to be released more frequently, often with only a few hours' notice. That is the price we pay for open-source software becoming more secure, and we consider it fair. What matters most is how quickly a website is protected again afterward.

On October 21, our customers were able to handle this within a single workday: a warning at noon, protective measures prepared and implemented, and updates installed as soon as they became available. Our guiding principle for this can be summed up in one line: “Be smart. Prepare and update fast.”