For an old-school sysadmin like me, it felt almost like the old days: patching servers late into the night. Except nobody patches servers anymore. Nobody patches by hand anymore either. Everything runs automatically. The only manual step left was putting the websites back online.
That only works if systems are maintained and kept at the latest security level. And it takes a strong team that can react quickly.
Was STRG.AT affected too?
STRG.AT deliberately moved away from PHP in 2021. Since then, new projects are built in modern languages such as TypeScript and Python, and frameworks such as Vue.js and Nuxt.
Those projects were not affected by PHP2Shell. Older projects from our PHP era were. There, we had to act fast yesterday as well.
Tempting as it is to bash PHP: PHP2Shell is no proof that PHP as a language is insecure.
What actually happened with PHP2Shell?
PHP, a scripting language widely used on the web, has two severe vulnerabilities that were grouped under the name “PHP2Shell”. Before a single line of application code runs, these flaws allow attackers to execute their own code on web servers.
That code can be used for defacing, spying on user data, outright data theft, or to harness the server's computing power for a botnet. The potential economic damage is enormous. On 21 October 2026, the PHP project shipped emergency patches for the actively supported versions, and later for older versions as well.
Why all the media attention?
For critical vulnerabilities, good practice is to inform vendors and distributors before the flaw becomes public. OpenSSL set the example in 2015: the project announced critical updates a few days in advance, without details, giving distributors time to prepare patched packages. By the time of disclosure, everything is ready to keep the time to fix as short as possible, and with automated processes no site has to go offline.
The PHP team chose the same path: distributors and vendors first. But leaked CVE numbers, an accidentally published exploit video and one vendor's premature patch release threw the schedule off, forcing operators to react under time pressure.
This leads to hard risk decisions in companies and organisations: stay online and hope nothing happens, or take sites offline and accept the economic damage.
Is this purely a PHP problem?
Both vulnerabilities are bugs in PHP's C code, in manual memory management, not in PHP's syntax or design. Bugs like these can hide in any runtime, any library and any framework.
Recent years show this clearly:
Heartbleed (2014): a memory bug in OpenSSL that made server memory readable worldwide.
Log4Shell (2021): a remote code execution flaw in the Java logging library Log4j that hit practically every industry.
Next.js (2025): a middleware flaw allowed authorisation checks to be bypassed (CVE-2025-29927).
React2Shell (2025): a critical remote code execution flaw in React Server Components (CVE-2025-55182).
Modern stacks like the ones we use are no exception. Security does not come from choosing the “right” language. It comes from process: current versions, fast patch management, dependency monitoring, automated update and release pipelines. And a team that can respond quickly when it counts.
The PHP Foundation's blog post supports this point: the real problem was not the language, but a small, underfunded team maintaining infrastructure that a large part of the web runs on. That holds for many open source projects, whatever the language. The openness with which the Foundation names its own mistakes is remarkable. That is exactly how an open source project should handle a situation like this.
Conclusion
If you run PHP, patch today, not tomorrow. Anyone who considers software and system maintenance unnecessary and expensive will be having second thoughts these days, and may wish they had invested in it. And anyone who thinks a different stack keeps them safe from flaws like these should wait for the next headline. The best defence is a team that knows its systems and can act fast.