Part I — Situation overview

During the night of 21 to 22 October, magyarorszag.hu, the central portal for electronic dealings with the state, and several other government websites were shut down as a precaution. Zoltán Tanács, Minister for Science and Technology, announced the step on his Facebook page on Thursday morning. He said that no sign of an attack had been found, and that administration on the portal would be suspended for an expected 48 hours. According to Telex’s report, the threat was averted by Thursday afternoon and the site was restarted. The minister asked every business to have its IT specialists check whether its website was affected. The cause is two flaws in PHP, the open-source programming language on which, according to W3Techs, which measures the spread of web technologies, nearly 70 per cent of websites with known technology run. The flaws allow unauthenticated remote code execution: an attacker can run programs on the server without a password or user account. The National Cyber Security Center of the Special Service for National Security (NBSZ NKI) issued an alert on 21 October. Both flaws received a score of 9.2 on the CVSS scale, the international scoring system that measures the severity of vulnerabilities from 0 to 10. The institute asked for the patch to be installed immediately and, where this is not possible, for the system to be temporarily disconnected.

The background goes back one day. On Wednesday, government services were also taken offline in the Netherlands, Finland, Denmark and France, and some pages of Wikipedia and the BBC became unavailable. The flaws were found with artificial intelligence by two security companies, Calif and Wiz, which belongs to Alphabet. According to Wiz, the flaws remained hidden for more than a decade because exploiting them was too complicated for human analysts. The planned coordinated disclosure fell apart: the details leaked on forums, and one company published the patch hours before the official release. In the same week, an outage of Google Cloud’s London region paralysed Revolut and several British banks for hours. In August, MIAK wrote about the Treasury cyberattack (The real lesson of the Treasury cyberattack), and at the time called for login protection, an independent post-incident review and a payments contingency plan. The present case shows the same weakness from a different angle.

MIAK’s reading: taking the sites offline was a correct, proportionate decision. The problem is that, in the event of such a flaw, the state cannot quickly say how many of its own systems run on the affected software, and which of them still receive updates. The time between the release of a patch and exploitation accelerated by artificial intelligence is measured in days. In this race, the organisation that does not even know its own inventory falls behind.

Part II — Grounding in the literature

Three EU legal sources provide the framework for interpreting the case. Article 21 of the NIS2 Directive (Directive 2022/2555 on the security of network and information systems, which sets the EU cybersecurity minimum) lists vulnerability handling and business continuity among the mandatory risk-management measures. Article 12 requires every Member State to designate a coordinating computer security incident response team (CSIRT) for the coordinated disclosure of vulnerabilities. The Cyber Resilience Act proposal (COM(2022) 454, on cybersecurity requirements for products with digital elements) extends responsibility to the entire life cycle of products: the manufacturer must keep a software bill of materials of the product’s components and must fix flaws for years. Free and open-source software developed outside a commercial activity, however, falls outside its scope, so the burden of maintaining PHP-type basic components remains with the operators who use them. The preamble of the EU Artificial Intelligence Act (2024/1689) expressly names the acceleration of the discovery and exploitation of vulnerabilities among the systemic risks of large AI models. The present case is a spectacular example of this. The detailed treatment of the literature — source by source, with quotations — is in section 6.4 Literature in detail.

Part III — MIAK’s concrete proposal

MIAK proposes three measurable measures. All three answer the same question: how much time passes between the disclosure of a critical flaw and the state system reaching a secure state, and who bears the cost of the time in between.

3.1 A state software and dependency inventory (critical and internet-facing systems by 31 January 2027, local-government and education websites by 30 June 2027)

MIAK proposes that every central state administration body submit, by 31 January 2027, an inventory of its systems reachable from the internet. The inventory should contain the runtime environment and its version (PHP, database, web server), the operator, the hosting and any cloud provider, and whether the given version still receives security updates. The same should be completed by 30 June 2027 for the websites of local governments, schools and state-maintained institutions. The model is the Cyber Resilience Act’s software bill of materials (see 6.4.2): a machine-readable list of the product’s components, at least down to the direct dependencies. The inventory should be managed by the National Cyber Security Center, which should regularly match it against new alerts. According to the institute’s website, it already provides an automated vulnerability-scanning service, on which the inventory can be built. Only aggregated data should be made public, for example how many state websites run on an unsupported version. The detailed list could also serve as an attack map. The proposal makes operational the local-government minimum standard of the cybersecurity strategy in D5 and the sovereign state infrastructure programme point D17.

3.2 Public patching deadlines and a central patching on-call service (government decree by 31 March 2027)

The NKI alert formulated a recommendation. MIAK proposes that a mandatory, known-in-advance deadline apply to critical vulnerabilities. On the basis of the authorisation in the cybersecurity Act, and within its limits, the Government should prescribe by decree the following for the internet-facing systems of state bodies. In the case of a flaw rated critical (CVSS 9 or above), or one proven to be actively exploited, either the patch must be installed or the system disconnected within 72 hours. For a high rating, the deadline should be 14 days. The institute should publish compliance with the deadlines every quarter, aggregated by type of organisation. A deadline in itself does not help a small municipality whose website runs on shared hosting, on a system not updated for years. Experts quoted by Portfolio and Index named precisely this group as the most exposed. A central patching on-call service should therefore be launched together with the decree: a team reachable for 72 hours after a critical alert, which helps local governments, schools and small state institutions with updating or with safe disconnection. In the longer term, these websites should move to the central, maintained platform under KI4. Article 21 of NIS2 (see 6.4.1) prescribes vulnerability handling as a mandatory minimum; the deadline makes it measurable. The proposal builds on programme points D5 and HV1 (cyber-defence capacity building).

3.3 Protecting citizens’ deadlines and public accounting when the central portal goes down (by 31 December 2026)

A precautionary shutdown is a cost even if no attack took place: missed applications, expiring deadlines, citizens queuing on the phone and at government windows. MIAK proposes that the operator of magyarorszag.hu introduce a public status page by the end of 2026 and issue an authenticated certificate for every outage, with its start and end times. If a citizen’s deadline expires during such a certified outage, it should automatically be extended to the working days following restoration. The citizen should not have to submit an individual request for excuse. For this, the National Assembly should amend the Acts on electronic administration and on general administrative procedure. Until then, the Government should ask the authorities to assess requests for excuse equitably on account of the outage. After every outage longer than 12 hours, a short public summary should appear within 30 days: how long it lasted, how many case initiations were missed or delayed, and how much traffic the backup channels carried. This is not the same as the independent post-incident review proposed in August for serious incidents. It is a simpler, quicker version of that for cases where the state shuts down the service by its own decision. The business-continuity requirement of NIS2 (see 6.4.1) counts backup systems as part of the mandatory minimum. The one-stop administration programme point KI1 itself records as a risk that the failure of a single platform paralyses all administration.

The common principle of the three proposals is that, in the age of artificial intelligence, the time between patching and exploitation is the decisive variable. The EU AI Act (see 6.4.3) already expects testing and incident reporting from developers of large models. The state must become just as fast on its own side: it must know what it runs, how long it takes to patch, and what it does for citizens while it patches.

Part IV — Expected effects and risks

Dimension Expected effect Risk
Public administration Once the inventory exists, it becomes clear within hours of an alert which systems are affected; responsibility between operator and supplier becomes unambiguous The first inventory will be incomplete, and organisations may initially treat it as a formal data-reporting exercise
Citizens An outage does not cause loss of rights; the public status page reduces uncertainty and unnecessary customer traffic Because of the strict deadline, short precautionary shutdowns may become more frequent
Local governments, schools The patching on-call service and the central platform lift from small organisations a burden they cannot carry on their own If the on-call service’s capacity is small, in a major alert it is precisely the most exposed actors who end up at the back of the queue
Security The attack surface shrinks, and the number of unsupported versions becomes measurable If the inventory leaks, attackers get a target list — which is why only aggregated data can be public
Budget The one-off cost of the on-call service and the migration is small compared with a nationwide administrative outage lasting several days Updating old systems may require weeks of developer work, an expense not planned in advance

The most important dilemma lies between availability and security. In practice, the 72-hour deadline may bring more shutdowns, because where an update does not fit in, disconnection is the compliant solution. According to an operations manager interviewed by Index, after a major version change the old code may not run flawlessly, and testing the transition may take days or weeks. Proposal 3.2 therefore works only together with 3.3: disconnection is an acceptable price for security only if the citizen does not lose rights in the meantime. The second dilemma is that of publicity. Publishing aggregated indicators instils discipline, whereas a detailed list is a risk. MIAK therefore proposes publication by type of organisation, not item by item.

Part V — Measurability and summary

5.1 What is worth following? (suggested KPIs)

MIAK proposes four key performance indicators (KPIs) for monitoring:

  • Patching or disconnection time for critical flaws — the median time from the alert to a secure state on state systems reachable from the internet; suggested target: under 72 hours by the end of 2027, with quarterly publication.
  • Inventory coverage — for what percentage of critical state systems an up-to-date software and dependency inventory exists; suggested target: 100% by 31 January 2027, and by 30 June 2027 for local-government and education websites.
  • Number of unsupported runtime environments — how many state and local-government websites run on a version that no longer receives security updates; suggested target: continuous decrease, zero by the end of 2028.
  • Unplanned outage hours of the central portal and the accounting deadline — an annual total, and the share of outages longer than 12 hours for which the public summary appeared within 30 days; suggested target: 100%.

5.2 Summary

MIAK’s request is concrete: by 31 March 2027 the Government should lay down by decree the patching deadline for critical flaws and launch a central patching on-call service for small organisations. The software inventory should be compiled in the first half of 2027. From the end of 2026, public, certified data should be produced on outages of magyarorszag.hu, and citizens should not lose a deadline because of a decision by the state. Regarding the present shutdown, MIAK asks that a short summary appear within 30 days: how long it lasted, and how many cases were missed because of it.

Two of MIAK’s foundational values are at stake in this case. Data-drivenness, because cybersecurity preparedness cannot be measured today: there is no data on how many state systems run on outdated software and how long it takes to patch them. The inventory and the deadline turn this into a number. And transparency, because the burden of a precautionary shutdown is borne by citizens. They have a right to know how long it lasted, what it cost, and what guarantees that next time it is not they who pay for it.

Part VI — Reasoning and further sources

6.1 Press framing by spectrum

In the left-liberal band, Telex gave the most detailed technical explanation. The article went through how a memory-management flaw confirmed in 2024 but believed to be unexploitable became a working attack, and how the disclosure embargo (the coordinated, timed publication of the patch) collapsed. The paper’s framing — “but there is already a solution” — leaned towards reassurance, while it also highlighted that a significant share of sites running on old PHP versions will not receive an official patch. 444.hu confined itself to the MTI material and the minister’s announcement, quoted verbatim. A day earlier, HVG still carried the news as a European story, with a look at Australia, and in a separate article presented the debate on the safety regulation of artificial intelligence.

In the general-interest band, 24.hu put the ministerial announcement and the appeal to businesses at the centre, and published a technical root-cause article on the Revolut outage. Index used the phrase “the most serious flaw ever detected”, but also presented the problem from an operator’s perspective: after the update the old application will not necessarily run flawlessly, so patching is not a push of a button.

In the business band, Portfolio connected the two threads. One of its articles highlighted the CVSS score, the call by the EU cybersecurity team (CERT-EU) to take systems offline, and the exposure of small operators. Another of its articles presented the European and British financial supervisors taking action over the Google Cloud outage, that is, concentrated dependence on cloud providers as a financial-stability issue.

In the conservative band, Magyar Nemzet framed the case as a European crisis in its foreign-news section, with a headline beginning “What is going on here?”. It stressed that artificial intelligence can also give attackers an automated, mass-scale tool. On the domestic shutdown, it quoted the minister’s announcement factually, focusing on the 48-hour suspension of administration. The day’s output of Mandiner and Népszava was not available to the monitor, so one actor each from the right-wing and the left-wing band is missing from the picture.

6.2 Facts and data

Data Value Source
Severity of the two vulnerabilities 9.2 points on the 10-point CVSS v4.0 scale, both critical (CVE-2026-109618 and CVE-2026-109619) NBSZ NKI alert, 21 October 2026; Portfolio
Nature of the flaws unauthenticated remote code execution on web servers NBSZ NKI; 444.hu (MTI)
Patched PHP versions 8.2.35, 8.3.36, 8.4.27, 8.5.12 (released: 21 October) NBSZ NKI, 22 October 2026
Unsupported branches PHP 8.1 and earlier versions receive no official update; some distributions may provide backported patches NBSZ NKI
PHP’s share nearly 70% of websites with known server-side technology W3Techs, Telex, 22 October 2026
Websites running on PHP 7 or older roughly 31% of known websites W3Techs, Telex
Reporting of the flaws to the PHP developers Calif: 11 August; Wiz: 24 August Portfolio, 21 October 2026
First detected exploitation attempt 17 October (according to the PHP Foundation, working attack code was not available until the official patch) According to Amazon, Portfolio and Telex
Shutdown of magyarorszag.hu the night of 21 to 22 October; announced expected duration 48 hours; restarted Thursday afternoon Announcement by Zoltán Tanács (24.hu, Portfolio, 444.hu); Telex
European countries affected the Netherlands, Finland, Denmark, France; there was also a shutdown in Australia MTI (Index, Telex, 444.hu); HVG
Google Cloud outage 20 October, 8:08 (Hungarian time), London region; Revolut, HSBC, Lloyds, Bank of Scotland affected 24.hu, 20 October 2026
EU cloud oversight last year the EU designated 19 technology companies as critical providers for the financial sector Portfolio, 22 October 2026

Two rows of the table are the most important. According to one, nearly a third of websites run on an old version for which the official patch will not arrive. According to the other, the first attack attempt took place four days before public disclosure. Together they show that the advice “let’s install the update” cannot be carried out immediately for a significant share of systems. The time between patching and exploitation therefore begins not when the update is released, but earlier. Only those who know their own systems in advance can make use of this time.

6.3 Policy dimensions

  • Digitalisation and AI regulation (programme points) — the local-government minimum standard and the emergency exercises of the cybersecurity strategy (programme point ID: D5) provide the basis for proposals 3.1 and 3.2; sovereign state infrastructure (programme point ID: D17) justifies keeping a register of hosting and cloud dependence; the responsible AI framework (programme point ID: D1) provides the regulatory background for the dual use of AI-based vulnerability discovery;
  • Public administration and e-government (programme points) — one-stop digital administration (programme point ID: KI1) itself records that the failure of a single platform paralyses all administration, which is the starting point of proposal 3.3; the central platform of local-government digitalisation (programme point ID: KI4) will in the longer term replace the small organisations’ own, unmaintained websites;
  • Defence (programme points) — cyber-defence capacity building (programme point ID: HV1) calls for publicly measured detection and response times, which the patching deadline of proposal 3.2 makes concrete;
  • Public security and law enforcement (background material) — data theft and fraud via vulnerable websites are one of the main entry points of online crime;
  • Economy (programme points) — the Google Cloud outage is also a signal from the perspective of financial-stability monitoring (programme point ID: G22): the failure of a few large cloud providers affects several banks at once.

6.4 Literature in detail

6.4.1 The EU NIS2 Directive

Article 21 of Directive 2022/2555 lists in ten points the risk-management measures that essential and important entities — including public administration — must at least take. The list includes “business continuity, such as backup management and disaster recovery, and crisis management”, as well as “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. According to recital (58) of the Directive, the rapid identification and remediation of vulnerabilities is an important factor in reducing risk, and since flaws are often discovered by third parties, entities must establish procedures for receiving them. Article 12 requires a coordinating CSIRT in every Member State, which acts as an intermediary between the person reporting the flaw and the manufacturer, and coordinates the disclosure timeline.

The PHP case put both provisions to the test. Coordinated disclosure failed on the vendor side, because the details leaked before the planned date. In such cases it is up to the operator how much time it loses. Article 21 makes vulnerability handling mandatory, but does not say how quickly patching must happen. MIAK’s proposal 3.2 fills this gap with a domestic deadline, and proposal 3.3 translates the business-continuity requirement into the language of citizens.

📖 Source: Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2)

6.4.2 The Cyber Resilience Act proposal

The European Commission’s 2022 proposal sets out cybersecurity requirements covering the full life cycle of products with digital elements. According to the category index, the regulation entered into force at the end of 2024; the knowledge base contains the text of the proposal. Under the annex, manufacturers shall “identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format”. The proposal makes vulnerability handling mandatory for the expected lifetime of the product, for up to five years, and requires notification within 24 hours of actively exploited flaws to the EU cybersecurity agency (ENISA). According to recital (10), however, free and open-source software developed outside the course of a commercial activity does not fall within the scope of the regulation.

This exemption provides the regulatory lesson of the PHP case. The language itself, an open-source project maintained by a foundation, falls outside the manufacturer obligations. Responsibility thus remains with those who build it into a product or service — including the state as an operator. The logic of the software bill of materials must therefore also apply to the state’s own systems. Anyone who does not know what components their system consists of cannot say whether an alert affects them. This is the direct reason for proposal 3.1.

📖 Source: European Commission: COM(2022) 454 — Proposal for a Regulation on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), main text and annexes

6.4.3 The EU Artificial Intelligence Act

Recital (110) of Regulation 2024/1689 specifically mentions offensive cyber capabilities among the systemic risks of general-purpose AI models, “such as the ways in vulnerability discovery, exploitation, or operational use can be enabled” — that is, the ways in which models can facilitate the discovery, exploitation and operational deployment of vulnerabilities. Article 55 requires providers of models with systemic risk to carry out adversarial testing, to document and report serious incidents, and to ensure adequate cybersecurity protection.

The PHP case showed both sides. The flaws were found with AI, and according to the companies this would have been practically impossible with human analysts. According to experts, the same tools can also quickly produce attack code from public patches. The AI Act regulates the developers of models, not the operators affected by the flaws. The state must therefore speed up on its own side: the inventory (3.1) and the deadline (3.2) are the response to the recognition that the time between patching and exploitation has become permanently shorter because of artificial intelligence.

📖 Source: Regulation (EU) 2024/1689 of the European Parliament and of the Council (Artificial Intelligence Act)

6.5 International comparison

One pattern of the European reactions was that they accepted the shutdown, not the risk. In the Netherlands, the national cybersecurity centre also took its own website offline; in Denmark, the national communication system between schools and parents; in France, the Ministry of the Interior took down some websites of local administrative bodies. The cybersecurity team of the EU institutions (CERT-EU) expressly called on organisations to take offline whatever they cannot update immediately. The Hungarian decision fits into this pattern.

There is a working foreign model for a patching deadline. The United States cybersecurity agency (CISA) keeps a public catalogue of proven exploited vulnerabilities, and federal agencies must patch these within a mandatory deadline. On the financial side, under the regulation on the digital operational resilience of the sector (DORA), the EU designated the critical technology providers, including the large cloud providers, and placed them under the joint oversight of the European financial supervisors. According to Portfolio, the European Banking Authority (EBA) has indeed contacted the provider over the Google Cloud outage. In the United Kingdom, Parliament’s Treasury Committee requested information from the central bank and the financial regulator. Under the British rule, the bank remains liable to its customers even if the fault arose at the cloud provider. This principle of responsibility can be transferred to state administration: proposal 3.3 states the same.

Digitalisation and AI regulation

  • D1 — Responsible AI framework
  • D5 — Cybersecurity strategy
  • D17 — Space and sovereign digital infrastructure

Public administration and e-government

  • KI1 — One-stop digital administration
  • KI4 — Local-government digitalisation

Defence

  • HV1 — Cyber-defence capacity building

Economy

  • G22 — Financial-stability monitoring and shadow-banking regulation

Proposed new programme point: Protecting citizens’ deadlines when the central e-administration portal goes down — for the Public administration and e-government area.

6.7 List of sources

Press sources (MIAK press monitor, 23 October 2026 — topic 5, and 22 October 2026 — topic 6):

Knowledge-base references (reference books and official legal sources):

  • 📖 Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2)
  • 📖 European Commission: COM(2022) 454 — Cyber Resilience Act proposal (main text and annexes)
  • 📖 Regulation (EU) 2024/1689 of the European Parliament and of the Council (Artificial Intelligence Act)

Note: the visible text of the blog post does not show the local file paths of the sources — only the author and title, or the designation of the legal source.

MIAK internal materials:

  • MIAK policy area: Digitalisation and AI regulation (programme points; programme point IDs: D1, D5, D17)
  • MIAK policy area: Public administration and e-government (programme points; programme point IDs: KI1, KI4)
  • MIAK policy area: Defence (programme points; programme point ID: HV1)
  • MIAK policy area: Public security and law enforcement (background material)
  • MIAK policy area: Economy (programme points; programme point ID: G22)
  • MIAK press monitor, 23 October 2026 — topic 5, score: 84/100
  • MIAK press monitor, 22 October 2026 — topic 6, score: 84/100

Supplementary public data sources:

Generation metadata