What happens when a vulnerability is discovered in software that underpins much of the web?

For several European governments this week, the answer was to take websites offline.

On 21 October 2026 the Dutch government said that several of its websites were being taken offline as a precaution after two vulnerabilities were disclosed in PHP, naming Overheid.nl, MijnOverheid and DigiD among them (Rijksoverheid). The National Cyber Security Centre (NCSC) temporarily took its own website offline as well (Rijksoverheid). PHP is the server-side language of about 69 per cent of the websites whose server-side language can be identified (W3Techs, 24 October 2026).

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow an attacker to execute code remotely on a vulnerable server without authenticating. The PHP project rated both critical and released fixed versions the same day: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net).

What makes the incident instructive is how the flaws were found. Artificial intelligence helped uncover them, and one of the two sits in code that dates back more than a decade. That raises a question for every organisation: if AI can accelerate the discovery of security weaknesses, can cybersecurity and compliance programmes adapt quickly enough to respond?

1. The discovery: AI as a security research tool

The vulnerability records credit researchers at three organisations with the reports, and two of the credited teams have published accounts saying that AI models assisted their research (CVE-2026-109618, CVE-2026-109619). According to the National Vulnerability Database, CVE-2026-109619 affects PHP from version 5.4.0, released in 2012 (NVD).

The discoveries illustrate a growing use of AI: analysing complex, long-lived software to find weaknesses that earlier reviews missed.

There is another side. Once a vulnerability is public, attackers can use similar techniques to understand it, develop an exploit and look for exposed systems. That can compress the time between disclosure and attempted exploitation.

For organisations that run important services, that is an operational problem. The faster a vulnerability can be exploited, the less time there is to assess exposure, coordinate with suppliers and put effective safeguards in place. AI is both a tool for improving cybersecurity and a factor that may speed up some threats.

2. Why Dutch government websites went offline

The Dutch decision was precautionary. On the day of disclosure the European Commission (DG CNECT), ENISA, CERT-EU, Europol's EC3 and the CSIRTs network issued a joint statement advising organisations to consider isolating exposed applications from public networks until fixes could be applied (ENISA). The NCSC advised organisations to assess every internet-facing system that uses PHP, to consider measures such as switching a system off, and to install the updates as soon as they were available. Its alert, as updated on 23 October, advises keeping systems that are still vulnerable offline until they have been updated (NCSC).

On 23 October the NCSC said it was aware of one report of possible exploitation abroad, and that it had not been confirmed that the attack had succeeded. It also said that exploitation is complex and that large-scale exploitation is now considered less likely than first thought. Its advice to update as soon as possible stands.

A precautionary shutdown is not, by itself, evidence that a system was compromised. That distinction matters.

A preventive shutdown can show risk awareness and an attempt to contain exposure. But interrupting public-facing services also raises questions of business continuity and dependency management. Government portals are not ordinary websites. People rely on them to reach public services, prove their identity, retrieve information and complete essential administrative tasks. When they are unavailable, even briefly, the effects reach well beyond the organisation that runs the website.

Security decisions can protect the integrity of a system while affecting its availability. Both consequences have to be managed.

3. The hidden risk of shared digital infrastructure

The Netherlands was not alone. The Wikimedia Foundation said it took Wikimedia Cloud Services and other services offline as a precaution on 20 October (Wikimedia), and Reuters reported precautionary shutdowns of public websites in Germany, France and Finland, among others (Reuters factbox, via The Star).

A vulnerability in a widely used component can reach organisations in entirely different sectors and jurisdictions. This is a form of technology concentration risk. A government agency, a hospital, a transport operator, a financial institution and a small online retailer may have little in common commercially, and still depend on overlapping software components, hosting services or development frameworks. When a vulnerability emerges in one of those shared components, the consequences can spread quickly.

Effective cybersecurity governance therefore needs more than an inventory of business applications. Organisations need visibility of their underlying technology, the software versions they run, their internet-facing assets, their critical dependencies and who is responsible for security updates. An organisation cannot manage a vulnerability in technology it does not know it runs. That visibility is harder still where software is maintained by hosting providers, managed service providers or other suppliers.

4. The regulatory implications: NIS2, the GDPR and operational resilience

NIS2 and cybersecurity risk management. Article 21 of the NIS2 Directive (Directive (EU) 2022/2555) obliges Member States to require essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to the security of their network and information systems. The measures include incident handling, business continuity, supply chain security, security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure, and policies and procedures to assess the effectiveness of those measures (Article 21(2), points (b) to (f)). In the Netherlands these duties apply through the Cyberbeveiligingswet, which implements the Directive and has applied since 15 August 2026 (wetten.overheid.nl).

A serious vulnerability in a critical software component therefore belongs in an in-scope entity's cybersecurity risk-management process. But neither a vulnerability disclosure nor a precautionary shutdown is automatically a significant incident that must be reported under Article 23. An incident is significant where it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (Article 23(3)). Whether that test is met depends on the facts, the applicable national implementation and the actual impact.

The GDPR and the security of personal data. Article 32 of the GDPR requires controllers and processors to implement appropriate technical and organisational measures, taking account of the risks, including the ability to keep the confidentiality, integrity, availability and resilience of processing systems and services on an ongoing basis (Article 32(1)(b)). An exploitable vulnerability raises questions about patch management, access protection and system security.

Discovering a vulnerability does not mean that a personal data breach has occurred. The European Data Protection Board states that personal data being unavailable because of planned system maintenance is not a "breach of security" within Article 4(12) (EDPB Guidelines 9/2022, paragraph 21). In our analysis a precautionary shutdown is closest to that case, though the Guidelines do not address it directly. If a system was exploited before it was taken offline, a breach of confidentiality or integrity may still have to be assessed, and notified to the supervisory authority without undue delay and, where feasible, within 72 hours, unless it is unlikely to result in a risk to people's rights and freedoms (Article 33(1)).

Operational resilience and sector rules. For financial entities in its scope, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), which has applied since 17 January 2025, adds requirements on ICT risk management, ICT-related incident management, classification and reporting, digital operational resilience testing and ICT third-party risk (Chapters II to V). Other sectors carry their own security, continuity and service-availability rules.

The same technical vulnerability can therefore engage different legal obligations depending on the organisation, its services and what actually happened. One vulnerability does not create one universal compliance response.

5. Five questions organisations should be asking

  1. Technology visibility: do we know which applications, websites and suppliers depend on vulnerable software components?
  2. Vulnerability management: can we identify affected systems, assess exposure and install security updates within appropriate timeframes?
  3. Business continuity: if a critical service has to be taken offline, do we understand the operational consequences, and do we have workable alternatives?
  4. Third-party accountability: are responsibilities for monitoring, patching, escalation and restoration clear between us and our technology providers?
  5. Regulatory response: can we distinguish a vulnerability, an attempted attack, a confirmed security incident and a reportable personal data breach, and document the basis for each determination?

These are not only technical questions. They involve governance, accountability, risk management, legal interpretation and operational decision-making.

6. Keeping pace with AI-assisted vulnerability discovery

AI-assisted vulnerability research could become an important advantage for defenders. Finding weaknesses before attackers exploit them is valuable.

But discovery is only the beginning. Someone has to determine which systems are exposed, decide what to patch, judge whether services should stay online, coordinate with suppliers, communicate interruptions and document the regulatory decisions that follow. Organisations that cannot turn security intelligence into operational action may stay vulnerable even when the relevant information is public.

This is where cybersecurity and regulatory compliance need to work together. For the governance of AI systems that act on their own, see When an AI Agent Reaches Data It Was Not Meant To.

Conclusion

The PHP incident is not only a story about two vulnerabilities or websites going offline. It shows how dependent public services, businesses and individuals have become on shared digital infrastructure, and how quickly a weakness in it can reach them.

It also shows why AI-assisted security research has to be matched by an organisation's ability to respond. Discovering vulnerabilities faster is progress. Being able to respond to them effectively is resilience.

Cybersecurity, technology governance, business continuity, third-party oversight and regulatory compliance cannot operate in silos. A compliance programme has to connect emerging technical risks to accountable decisions, appropriate controls, reliable evidence and timely action. Knowing that a vulnerability exists is not the same as being prepared to deal with it.

Analysis current as of 24 October 2026. A precautionary shutdown is not evidence of successful exploitation or of regulatory non-compliance.

Primary sources

Priventia Regulatory Insight. Regulatory intelligence you can act on.