PHP Security Flaws: Why European Public Sites Were Taken Offline on Purpose

Government agencies, hospitals and universities in Europe deliberately took their websites offline because of two critical PHP security vulnerabilities. That is not a routine choice. When an organization shuts down its own service with its own hands, it shows just how heavy the risk calculation was. The bigger question is this: why did a patch take so long to arrive for a language that runs much of the web?

What happened?

On Wednesday, sites belonging to public, healthcare and education institutions went dark in several European countries. Operators took the sites offline themselves. They judged a few hours of downtime while the patch was rolled out to be safer than staying live with a vulnerable system. The shutdowns followed an official warning about the flaws.

Why did public bodies choose downtime over exposure?

The general rule in enterprise security is simple: staying online is the default, and shutting down is the last resort. Three conditions have to hold at the same time for that rule to flip. The vulnerability must be remotely and easily exploitable. There must be signs that attackers are moving. And the data being protected must be sensitive.

For hospital and government sites, the third condition is always present. Appointment systems, citizen applications and student records often sit on the same server or the same network. A website being down for a few hours is annoying, but it is reversible. Leaked patient data, or a hospital network locked by ransomware, is not. The institutions' calculation rests on that asymmetry.

There is also the reality of public-sector infrastructure. Many institutional sites run on old PHP versions, on systems set up by outside contractors and then left to fend for themselves. In such environments, "patch immediately" may not be an option. For an IT team that does not know which version is running on which server, the fastest and most reliable safeguard is pulling the plug. The decision to shut down is, in effect, also an admission of a missing inventory.

Why did the patching process drag on?

The fact that the flaw was identified in 2024 and stayed open for months turns this from a single security incident into a governance problem. PHP is not the product of a large company. Its development is carried by the non-profit PHP Foundation and volunteer contributors. The foundation was created in response to PHP resting on the shoulders of a handful of people for many years. But its resources are nowhere near the scale of the economy that depends on the language.

This picture is not new. Heartbleed in OpenSSL, Log4Shell in Log4j and the backdoor planted in the xz tools taught the same lesson: critical infrastructure depends on a small number of maintainers, often underfunded. The difference is that PHP is not a library but a runtime. A fix does not end with a single package. It has to pass through a chain that runs from distribution packagers to hosting companies, to platforms like WordPress, and finally to individual server administrators. Every link in the chain adds delay.

Who is affected, and how?

The most vulnerable group is the one that will never hear about it. Large institutions were at least able to decide to shut down. A small e-commerce site on shared hosting with an old PHP version has no such reflex. It is well known that versions past their end of support are still widely used. For versions outside the official support schedule, a patch often never arrives at all.

The picture is no different for Türkiye. PHP-based systems are widespread among municipalities, universities and SME websites. This incident is less a prompt to ask "could it happen to us?" and more a warning to ask "which version is running on which of our servers?"

What comes next?

The first thing to watch is whether the flaws are being actively exploited. If the shutdowns were precautionary, the disruption will be short. If traces of attacks surface, data-breach notifications and investigations will follow. Second, the debate over liability and funding for open-source maintainers under the EU's Cyber Resilience Act is likely to gain momentum from this incident. Third, whether public bodies will move toward mandatory standards for software inventory and version management.

The decision to shut down was the right reflex in the face of the flaw, if a late one. The real failure did not happen on that Wednesday. It happened in a funding and coordination model that allowed a critical vulnerability to sit unfixed for months. Until that model changes, the most effective tool institutions have at the next vulnerability will once again be pulling the plug.