Critical PHP flaws took Dutch websites offline. Here is what matters.

A serious warning, with real disruption

On 21 October 2026, the Netherlands saw precautionary website shutdowns during a critical PHP security emergency. The Dutch government notice carrying NCSC guidance said NCSC had taken its own website offline and advised organizations to assess exposed PHP systems. That notice said NCSC had not observed active exploitation at the time it was written.

This article was checked against official notices at 16:20 CEST on 21 October 2026. It is a dated incident analysis, not a live service-status tracker. Availability and advisories can change.

What went offline—and what that tells us

The Dutch judiciary's own notice named Werkenbijderechtspraak.nl, SSR.nl/MijnSSR and its journalist information mailbox as precautionary shutdowns. It said Rechtspraak.nl and Mijn Rechtspraak remained available because they did not use PHP.

Those are specific, documented examples. These notices document individual service decisions, not a measured national outage rate. Nor does an unavailable website establish that attackers breached it. A defensive shutdown and a successful intrusion are different events, and customers deserve that distinction.

The vulnerabilities and the fixes

The PHP project's security advisory and releases identify CVE-2026-109618 and CVE-2026-109619 as critical vulnerabilities that can permit unauthenticated remote code execution. Web-serving PHP installations are at risk; PHP highlights mod_php as the highest-risk configuration. This is a runtime issue, not simply a mistake in a website's own application code.

Fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution packages may carry backported fixes: verify your vendor's advisory rather than judging only by a version string. PHP says updating is the complete solution; temporary mitigations do not make an installation safe. Older branches need vendor-supported fixes or an upgrade plan.

Earlier, CERT-EU's preparation advisory recommended identifying affected assets, preparing urgent patching and considering isolation where immediate remediation was not feasible. Its pre-release wording should be read alongside the newer PHP release announcement.

The operational lesson: know what you run

Our view at VEYRSEC is straightforward: security work includes the software beneath your application. A polished frontend gives an owner very little information about which runtime is deployed, who maintains it or how quickly an emergency update can reach every instance.

Build an inventory that connects each public service to its actual runtime, hosting provider and responsible person. Include forgotten subdomains, administration tools, staging deployments and bundled components. Ask who can approve an emergency change and who can confirm that it reached every serving worker. A list that nobody owns will not help much during an incident.

Use the current upstream and hosting-vendor instructions for the actual environment. Preserve relevant logs, record the packages deployed, restart or redeploy affected services as directed, and verify the running instances. A successful package installation on one machine is only one part of that job. If compromise is suspected, preserve evidence and involve incident response; installing a fix alone does not establish that an earlier intrusion has been removed.

A pentest needs honest limits

A penetration test can examine an agreed application scope and produce useful evidence. It cannot promise that a new runtime vulnerability will never appear after the report is delivered. Patching, monitoring and response ownership need to continue between assessments.

This is why VEYRSEC works across PHP, AI-built applications and other web stacks. The useful question is which security boundaries hold under the agreed checks, and what needs remediation. We did not discover these PHP flaws, test the affected Dutch organizations or verify their current exposure. This article reports public notices and our operational interpretation, not a VEYRSEC client case study.

Read our PHP website security approach, testing methodology and delivery expectations. If you need an assessment, request a scoped initial check. An active security incident needs immediate containment and patch coordination; do not wait for a routine assessment slot.