Governments took sites offline over a PHP flaw. Is PHP safe, and what actually changed

On Wednesday 21 October 2026, government websites across Europe started going dark. The Dutch National Cyber Security Centre took down its own site. France's Interior Ministry placed all of its websites into preventive maintenance. In Germany the state IT provider ITZBund pulled several sites, in Denmark a nationwide school communication platform went down, and in Finland the public services of the state network followed. The reason was two flaws in PHP, the programming language most of the internet rests on. This article is about what happened, whether PHP is safe, and why the most interesting part of the story is something else entirely.

What actually happened

These are two vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619, which together picked up the nickname PHP2Shell. Both are rated 9.2 out of 10 on the CVSS 4.0 scale, which puts them in the „critical" band. They allow unauthenticated remote code execution: an attacker does not have to log in anywhere, does not need to know any password, and can still run their own program on the server.

Put simply, it comes down to what happens when PHP hits a serious error, typically running out of memory. The request is then cut off mid-work and leaves a mess behind in memory: half-finished data that looks complete, or a pointer to memory that has already been released. A later request finds that mess and uses it as if it were sound. An attacker who can create the mess in the right place can put their own content into it.

There are two consequences and both are serious. The first is reading the memory of the process, meaning whatever the server has in hand at that moment: passwords, tokens, keys to interfaces, certificates. The second is the code execution already mentioned. Researchers demonstrated it on WordPress, Drupal and Joomla, but it matters to understand that the flaw is not in them. It is in PHP itself, so it also reaches a perfectly plain page with no content management system at all.

The fixed releases came out the same day: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP developers added a sentence worth quoting exactly: updating is the only complete remediation. Various workarounds through configuration do narrow the room for attack, but they do not make an installation safe.

Why institutions switched sites off rather than wait

At first glance it seems odd for a state institution to switch its website off instead of fixing it. The order of events, though, was awkward. First it became known that the flaws existed and how serious they were. The patch arrived only afterwards, shortly after half past two in the afternoon Central European time. Between those two moments every operator had a choice: leave something running on the internet that is publicly known to be exploitable without a password, or take it down for a few hours.

Authorities inside and outside Europe recommended the second option. Cyber agencies in Europe, Australia, Japan and Britain urged operators either to update immediately or to take sites offline until the patch was in place. CERT-EU added that anyone unable to fix things at once should consider isolating internet-facing applications from the public network.

A website that is switched off is an inconvenience. A website someone walks away from with a database of citizens or patients is several orders of magnitude worse. Seen that way, going dark was the right call, not panic.

So is PHP safe?

The answer is yes, and not out of politeness towards the language we work in. It does deserve an explanation, though.

According to W3Techs, PHP powers roughly 75 % of websites whose programming language can be identified at all. When something holds that share, two things are true of it at once. First, any flaw in it has enormous reach, because it hits hundreds of thousands of unrelated sites at the same time. Second, and this matters more, such software sits under a level of scrutiny smaller projects cannot afford.

Notice how the whole thing played out. Researchers found the flaw, not attackers. They reported it to the PHP developers. Those prepared a fix for all four supported branches and shipped it for all of them on a single day. Agencies warned the public. That is not the picture of a broken ecosystem, it is the picture of one that works.

And one more thing. These flaws were not fresh. They had been in the code for more than ten years and they reach back to releases as early as PHP 5.4. All that time they lay there quietly, because nobody could find them. Which brings us to the heart of the matter.

What really changed: artificial intelligence found the flaw

PHP2Shell was not uncovered by a person digging through code. It was found by the research team at Wiz on 19. augusta 2026 using language models. They name their own Wiz Atlas tool and the Gemini 4 Argon and GPT-5.6 Sol models, and say the first of those contributed substantially not only to finding the flaw but also to building a working exploit and later to validating the patch.

In their write-up they summed it up in a sentence worth reading twice:

A single researcher completed in a week what would previously have taken a world-class team months of work.

And they added a point that matters more for this site than the flaw itself: the economics of both discovery and exploitation are changing. Until now, finding a flaw of this kind in an interpreter's memory took years of specialisation, a great deal of time and a team of people. That barrier kept flaws like this hidden for a whole decade. It no longer holds.

Why that shifts the balance

Finding the flaw is only the first half of the work. The second is writing an attack that actually works, and that has traditionally been harder still. Memory behaves differently in every PHP version, with every server setting, with every combination of extensions. An attack that works on one server merely crashes another. This is what held attackers back the most: they had to tune every target separately, and every round of tuning needed a specialist.

Language models are good at exactly this. They can read why an attack failed and propose a change. They can repeat that until it works. The amount of expert effort per target drops sharply, and that is precisely the shift we are talking about. It is not that an attacker has gained some new superpower. They have gained something more practical: they can now cover incomparably more targets at once than before.

The same tool serves both sides. Defenders found this flaw, and they found it before attackers did, which is exactly the point of such research. On the defending side, though, it rolls out more slowly, because defence is scattered across hundreds of thousands of operators while an attack only has to be tuned once.

The real problem is not PHP. It is the services everyone forgot about

Now we come to what we consider the most important sentence in this article.

The fix came out for four PHP branches: 8.2, 8.3, 8.4 and 8.5. For PHP 8.1 and older the project no longer issues a fix. Anyone running on those has to rely on whether their Linux distribution or hosting prepares one. And anyone on PHP 7, or even PHP 5, has no way to solve it at all. The flaw reaches those versions too.

At the same time, PHP 8.2 reaches end of support on 31 December 2026. Anyone breathing a sigh of relief today because their hosting offers 8.2 has until the end of the year to sort out the next step.

And this is exactly where institutions, and not only institutions, run into trouble. A new website gets built, launched with some ceremony, and looked after for a while. Then the supplier changes, the contract ends, or the person who understood it leaves. The site keeps running, because it works, doesn't it. Nobody watches the version underneath growing old. Next to the main site there is often still a login portal from 2019, an old survey form and a campaign microsite nobody remembers exists. Each of them is a separate server with its own PHP.

Then a day like this one arrives, and the main site is fixed or switched off within the hour. The forgotten services are not fixed, because nobody thinks of them. And it is those that stay on the internet like an open door the attacker knows better than the owner does.

It is the same pattern we described in this series for phone numbers and for fake websites: the problem is not the technology, it is what stops being done around it.

What to do if you have a website

The steps are short and fit into a single afternoon.

1. Find out which PHP version your site runs on. It is usually in the hosting control panel. If you cannot find it, send your hosting support one sentence: which PHP version does my site run on.
2. Compare it against the fixed releases. Safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything newer. A lower number in the same branch means the update has not happened yet.
3. Do not rely on automatic updates. This is the point that catches most people out. Automatic updates for WordPress and its plugins do not update PHP. PHP sits beneath them and is changed by the hosting or the server administrator, not by the content management system.
4. Do not treat configuration as a substitute for the fix. Advice along the lines of turn off a particular configuration option is circulating online. The PHP developers and its release managers say plainly that settings will not protect you. They only narrow the opening, they do not close it.
5. Write down everything you have running. Not just the main site. The old shop as well, the test copy, the campaign microsite, the partner portal. If nobody needs one of them, switching it off entirely is the safest thing you can do.

How to check the version when your hosting does not show it

Try the hosting control panel first, or one question to support. That is the fastest route and you do not have to upload anything to your site. If that is not an option, a small file will do: upload it, read it and delete it straight away.

The advice you will find online usually points to phpinfo(). We are deliberately not recommending it here, and it is worth saying why. phpinfo() prints absolutely everything: the exact version, the build date, the operating system kernel version, the paths to the configuration, the list of modules and which functions the server has disabled. You hand an attacker a complete view of the machine, and on a day when the internet is being scanned wholesale, you tell them outright that you are a worthwhile target. All you actually need is one number.

So this is enough. It prints the version and tells you straight away whether it is patched:

<?php
$patched = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch   = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
$needed   = $patched[$branch] ?? null;

echo 'PHP ' . PHP_VERSION . ': ';
if ($needed === null) {
    echo 'this branch no longer gets fixes, move to a newer one.';
} elseif (version_compare(PHP_VERSION, $needed, '>=')) {
    echo 'patched, all good.';
} else {
    echo 'BELOW THE PATCH, you need at least ' . $needed . '.';
}

Three rules go with it, and all three matter:

• Give it a random name. Nie info.php ani test.php, those are on the lists bots try first. Add your own random characters, for example version-k7m2xq.php.
• Delete it the moment you have read the result. Not tomorrow. It is exactly the kind of file everyone forgets about within a month, and files like that are what this whole article is about.
• Do not link to it from anywhere. It should exist for a few minutes and nobody but you should know about it.

If your site is from us, you do not have to deal with this, it is part of what you pay us for. If it is from someone else and you do not know who looks after it today, that is exactly the question worth asking before the day is out.

In closing

A simple headline about PHP being full of holes can be taken from all this. It would be inaccurate. A truer one reads like this: in the software that powers most of the internet, a flaw nobody could find lay there for over a decade. Defenders found it using language models, and they found it before attackers did. The fix was out the same day.

Only one thing has changed, but it has changed substantially. Finding and exploiting a flaw of this kind is no longer months of work for a top-tier team. Attacks that used to be expensive, and therefore rare, will get cheaper and therefore more frequent. That will not apply only to PHP. It will apply to every piece of software running something for you.

From that follows the conclusion this series keeps reaching, worded differently for each topic: what decides it is whether somebody is looking after your things today. Not which language you picked years ago.

Related reading

On what you hand over from your own address book: An unknown number is calling: how caller ID services work and what you hand over for them.

On what happens when the terms are missing instead: A clone instead of the original: how a fake site outranks the real one in Google.

And on what you agreed to with the social networks: What you agreed to with TikTok and the social networks.

Want to know where your own site stands? Our Free audit goes through the page and shows what runs on it and where its weak spots are.