Nederlands
Deutsch
Svenska
Dansk
On Wednesday 21 October, much of digital Netherlands went dark. DigiD, the government's digital ID, the citizen portal MijnOverheid, the website of the Dutch House of Representatives and even that of the National Cyber Security Centre (NCSC) went offline. NotuBiz, the council information system used by more than a hundred municipalities, provinces and water boards, was taken down. Bookkeepers could not log in to Exact, and webshops such as EasyToys and MyJewellery temporarily closed their doors.
At that moment there was no confirmed hack. These organisations switched their services off as a precaution, because there was no patch yet.
In short. PHP2Shell consists of two critical vulnerabilities in PHP itself, the programming language behind WordPress, Drupal and Magento, among others. An attacker can use them to take over a server without logging in. The patch has been available since 21 October. But the time between a vulnerability and its first exploitation has almost disappeared, so patching alone is not enough. Also check whether anyone was already inside, replace sensitive credentials, and make sure you can buy time next time.
What happened, in plain language
On 21 October, the NCSC warned of two critical vulnerabilities in PHP: CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell. The flaw is not in a plug-in or a theme, but in the engine itself. So even a simple 'Hello World' page can be vulnerable. According to the NCSC, a single request without a login can be enough to run code on the server. All versions from PHP 5 onwards are affected.
The patch arrived that afternoon at around 16:00 Dutch time, a day earlier than planned. The updated versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older will not receive a regular update (there, moving to a supported version is the only real solution).
The real story: the time to patch has gone
The severity is one thing. The real story is the speed.
- Exploitation before disclosure. Amazon saw an attack attempt on one of its honeypots as early as 17 October. That was four days before the patch existed.
- Thousands, then millions. Cloudflare counted thousands of attempts in the ten hours before disclosure, tens of thousands in the 45 minutes after it, and millions by now.
- A patch as a treasure map. Patched PHP versions appeared online several hours before the agreed time. For an attacker, that is a treasure map: the patch shows exactly where the flaw was.
- 81 minutes. Researchers at ELLIO saw one attacker go from first reconnaissance to an installed web shell, a backdoor on the server, in 81 minutes. Try getting a change approved in that time.
On 22 October, the NCSC reported the first signs that the flaw had also been exploited successfully.
And AI speeds up both sides. Researchers at Wiz found the vulnerabilities with the help of AI models. Dutch cybersecurity experts Inge Bryan and Bert Hubert expect AI to bring flaws like these to light more often, and in waves. It also means attackers who are not super hackers can exploit them.
What made the difference: being able to buy time
On 21 October, there were roughly three situations.
Many organisations could only switch off. That was the sensible choice, and the NCSC recommended it too. But it cost hours of service and revenue. EasyToys was offline for around eight hours.
A second group had a protective layer that bought time. WordPress host Heijsen kept its roughly 1,000 customers online with extra firewall rules and an upload limit until the patch was available.
The third group had no choice. Customers of NotuBiz and Exact depended on what their supplier did. Some of the security appliances on the market also turned out to use PHP themselves. There, customers had to wait for an update to the very device that was supposed to protect them.
Buying time until you have patched
A patch that exists is not yet a patch that is running. For many organisations, testing, a change and a maintenance window still sit in between. And it was precisely during that period that the NCSC reported the first signs of successful exploitation.
That is when a protective layer in the network counts. Using AI-assisted threat research, Cato developed new IPS signatures against the known attack scenarios. On 21 October, they first went live in silent mode, for validation. From 22 October they were rolled out in blocking mode, and on 23 October, according to Cato, this was confirmed across the entire network.
To be fair: on 21 October itself, this did not help yet. The blocking protection came a day after the patch. But while the patch was available, it often had not been installed yet.
For customers with IPS enabled, the signatures work automatically. Nothing needs to be configured, and nothing needs updating per server or device. The Cato platform itself was not affected; according to Cato, its core components, including the Sockets, do not use PHP.
This is a bridge, not a solution. It buys time until you have patched, for the traffic that goes through Cato.
That caveat matters. The IPS protection only works for traffic that Cato inspects, and only when IPS is enabled. Inbound traffic is covered too, but Cato does not perform TLS inspection on incoming connections. A public website reachable over HTTPS therefore falls outside these signatures. That requires a web application firewall (WAF). And patching remains necessary either way.
Patching is not the finish line
Even if you have patched by now, you are not done yet:
- Look back. Investigate whether attackers were already inside before the patch, going back to at least 17 October.
- Replace secrets. One of the vulnerabilities can expose memory from other requests. So replace passwords, tokens and API keys on servers that were vulnerable.
- Watch for unusual behaviour. A web server that suddenly starts a shell or a network tool, or connects outwards unexpectedly, is a strong signal. Block outbound traffic from servers by default and only allow what is needed.
- Keep limits in place. Limits on the size of requests and uploads remain useful, even after the patch.
The long tail
According to research by Dutch public broadcaster NOS, around 145,000 Dutch websites may still be vulnerable, although this cannot be established with certainty from the outside. Bert Hubert estimates that 47 percent of websites running PHP use a version that no longer receives support.
And PHP 8.2 will no longer receive security updates after 31 December 2026. In just over two months, another version will be left without patches.
The next PHP2Shell is only a matter of time. The question is how much time you will be able to buy.
Five questions for your organisation
The NIST Cybersecurity Framework is a good mirror here. Five of its six functions, applied to 21 October:
- Identify. Do you know where PHP is running, including at your SaaS suppliers and in appliances?
- Protect. What protects you between the moment a vulnerability leaks and the moment you patch?
- Detect. Would you notice if a server suddenly started calling out?
- Respond. Who decides to switch off, and on what basis?
- Recover. How do you know it is safe to switch back on?
Where Momentum stands
Momentum is a specialised implementation partner of Cato Networks in EMEA. If you use Cato through Momentum, we are happy to check with you whether IPS is enabled, which traffic Cato inspects and where your public applications also need a WAF. If you are just getting started, we will map out together where PHP runs in your environment and where a bridge can buy you time next time.
A conversation is free of obligation. Better now, calmly, than during the next one.
Sources: NCSC, NOS, Binnenlands Bestuur, DutchBrief, Quote, The Register, The Next Web, CSO Online, ELLIO, Wiz, Qualys, EenVandaag, Help Net Security, PHP, Cato Networks.
