I. rész — Helyzetkép

Az október 21-ről 22-re virradó éjszaka elővigyázatosságból leállították a magyarorszag.hu-t, az állami elektronikus ügyintézés központi portálját, és több más kormányzati weboldalt. Tanács Zoltán tudományos és technológiai miniszter csütörtök reggel a Facebook-oldalán jelentette be a lépést. Közölte, hogy támadásra utaló jelet nem találtak, és a portálon várhatóan 48 órán át szünetel az ügyintézés. A Telex beszámolója szerint a fenyegetést csütörtök délutánra elhárították, és az oldal újraindult. A miniszter arra kért minden vállalkozást, hogy informatikai szakembereivel ellenőriztesse, érintett-e a honlapja. Az ok két hiba a PHP-ban, abban a nyílt forráskódú programozási nyelvben, amelyen a webes technológiák elterjedtségét mérő W3Techs adatai szerint az ismert technológiájú honlapok közel 70 százaléka fut. A hibák hitelesítés nélküli távoli kódfuttatást tesznek lehetővé: a támadó jelszó és felhasználói fiók nélkül futtathat programot a szerveren. A Nemzetbiztonsági Szakszolgálat Nemzeti Kiberbiztonsági Intézete (NBSZ NKI) október 21-én riasztást adott ki. Mindkét hiba 9,2-es pontszámot kapott a CVSS-skálán, a sérülékenységek súlyosságát 0-tól 10-ig mérő nemzetközi pontrendszerben. Az intézet a javítás azonnali telepítését kérte, és ahol ez nem megy, a rendszer ideiglenes leválasztását.

Az előzmény egy nappal korábbi. Szerdán Hollandiában, Finnországban, Dániában és Franciaországban is kormányzati szolgáltatásokat kapcsoltak le, a Wikipédia és a BBC egyes oldalai is elérhetetlenné váltak. A hibákat két biztonsági cég, a Calif és az Alphabethez tartozó Wiz találta meg mesterséges intelligenciával. A Wiz szerint a hibák több mint egy évtizedig rejtve maradtak, mert kihasználásuk emberi elemzőknek túl bonyolult volt. A tervezett összehangolt közzététel szétesett: a részletek fórumokon szivárogtak ki, és egy cég órákkal a hivatalos megjelenés előtt közzétette a javítócsomagot. Ugyanezen a héten a Google Cloud londoni régiójának kiesése órákra megbénította a Revolutot és több brit bankot. A MIAK augusztusban a kincstári kibertámadásról írt (A kincstári kibertámadás valódi tanulsága), akkor a belépésvédelmet, a független utóvizsgálatot és a kifizetési tartaléktervet kérte. A mostani eset más oldalról mutatja ugyanazt a gyengeséget.

A MIAK olvasata szerint a lekapcsolás helyes, arányos döntés volt. A probléma az, hogy egy ilyen hiba esetén az állam nem tudja gyorsan megmondani, hány saját rendszere fut az érintett szoftveren, és ezek közül melyik kap még frissítést. A javítás megjelenése és a mesterséges intelligenciával gyorsított kihasználás között napokban mérhető az idő. Ebben a versenyben az a szervezet marad le, amely a saját leltárát sem ismeri.

II. rész — Szakkönyvi megalapozás

Az eset értelmezéséhez három uniós jogforrás ad keretet. A NIS2 irányelv (a hálózati és információs rendszerek biztonságáról szóló 2022/2555 irányelv, amely az uniós kiberbiztonsági minimumot rögzíti) 21. cikke a kötelező kockázatkezelési intézkedések közé sorolja a sérülékenységek kezelését és az üzletmenet-folytonosságot. A 12. cikk pedig minden tagállamtól megköveteli, hogy kijelöljön egy koordináló számítógépes eseménykezelő csoportot (CSIRT) a sérülékenységek összehangolt közzétételére. A Cyber Resilience Act javaslata (COM(2022) 454, a digitális elemeket tartalmazó termékek kiberbiztonsági követelményeiről) a felelősséget a termékek egész életciklusára kiterjeszti: a gyártónak szoftveranyagjegyzéket kell vezetnie a termék alkotóelemeiről, és éveken át javítania kell a hibákat. A nem kereskedelmi célú nyílt forráskódú szoftver ugyanakkor kívül esik a hatályán, így a PHP-típusú alapkomponensek gondozásának terhe az azokat használó üzemeltetőn marad. Az uniós mesterségesintelligencia-rendelet (2024/1689) preambuluma a nagy AI-modellek rendszerszintű kockázatai között kifejezetten megnevezi a sérülékenységek felfedezésének és kihasználásának felgyorsítását. A mostani eset ennek látványos példája. A részletes szakkönyvi tárgyalás — forrásonként, idézetekkel — a 6.4 Szakkönyvi részletezés szakaszban található.

III. rész — A MIAK konkrét javaslata

A MIAK három mérhető intézkedést javasol. Mindhárom ugyanarra a kérdésre felel: mennyi idő telik el egy kritikus hiba nyilvánosságra kerülése és az állami rendszer biztonságos állapota között, és ki viseli a köztes idő költségét.

3.1 Állami szoftver- és függőségi leltár (kritikus és internetre néző rendszerek 2027. január 31-ig, önkormányzati és oktatási honlapok 2027. június 30-ig)

A MIAK azt javasolja, hogy minden központi államigazgatási szerv 2027. január 31-ig adjon le leltárt az internet felől elérhető rendszereiről. A leltár tartalmazza a futtatókörnyezetet és annak verzióját (PHP, adatbázis, webszerver), az üzemeltetőt, a tárhelyet és az esetleges felhőszolgáltatót, valamint azt, hogy az adott verzió kap-e még biztonsági frissítést. Az önkormányzatok, iskolák és állami fenntartású intézmények honlapjaira ugyanez 2027. június 30-ig készüljön el. A minta a Cyber Resilience Act szoftveranyagjegyzéke (lásd 6.4.2): géppel olvasható lista a termék alkotóelemeiről, legalább a közvetlen függőségekig. A leltárt a Nemzeti Kiberbiztonsági Intézet kezelje, és rendszeresen vesse össze az új riasztásokkal. Az intézet honlapja szerint automatizált sebezhetőség-felderítési szolgáltatást már ma is nyújt, ezt a leltárra lehet építeni. Nyilvánosságra csak összesített adat kerüljön, például hány állami honlap fut támogatáson kívüli verzión. A részletes lista támadási térképként is szolgálhatna. A javaslat a D5 kiberbiztonsági stratégia önkormányzati minimumsztenderdjét és a D17 szuverén állami infrastruktúra programpontját teszi működőképessé.

3.2 Nyilvános javítási határidők és központi javítási ügyelet (kormányrendelet 2027. március 31-ig)

Az NKI riasztása ajánlást fogalmazott meg. A MIAK azt javasolja, hogy a kritikus sérülékenységekre kötelező, előre ismert határidő vonatkozzon. A Kormány a kiberbiztonsági törvény felhatalmazása alapján, annak keretei között rendeletben írja elő az állami szervek internet felől elérhető rendszereire a következőt. Kritikus besorolású (CVSS 9 vagy afölötti), illetve bizonyítottan aktívan kihasznált hiba esetén 72 órán belül vagy a javítást kell telepíteni, vagy a rendszert le kell választani. Magas besorolásúnál 14 nap legyen a határidő. A határidők betartását az intézet negyedévente, szervezettípusonként összesítve tegye közzé. A határidő önmagában nem segít annak a kis településnek, amelynek honlapja osztott tárhelyen, évek óta nem frissített rendszeren fut. A Portfolio és az Index szakértői éppen ezt a kört nevezték a legkitettebbnek. Ezért a rendelettel együtt induljon központi javítási ügyelet: kritikus riasztás után 72 órán át hívható csoport, amely az önkormányzatoknak, iskoláknak és kis állami intézményeknek segít a frissítésben vagy a biztonságos leválasztásban. Hosszabb távon ezek a honlapok a KI4 szerinti központi, gondozott platformra költözzenek. A NIS2 21. cikke (lásd 6.4.1) a sérülékenységkezelést kötelező minimumként írja elő, a határidő ezt teszi mérhetővé. A javaslat a D5 és a HV1 kibervédelmi kapacitásfejlesztés programpontra épül.

3.3 Az ügyfélhatáridők védelme és nyilvános elszámolás a központi portál leállásakor (2026. december 31-ig)

Az elővigyázatossági leállítás akkor is költség, ha nem történt támadás: elmaradt kérelmek, lejáró határidők, telefonon és kormányablakban sorban álló ügyfelek. A MIAK azt javasolja, hogy a magyarorszag.hu üzemeltetője 2026 végéig vezessen be nyilvános állapotoldalt, és minden leállásról adjon ki hiteles igazolást a kezdő és záró időponttal. Az ügyfél határideje, ha egy ilyen igazolt leállás alatt jár le, automatikusan tolódjon ki a helyreállítást követő munkanapokra. Ne kelljen egyenként igazolási kérelmet benyújtania. Ehhez az Országgyűlés módosítsa az elektronikus ügyintézésre és a közigazgatási eljárásra vonatkozó törvényeket. Addig a Kormány kérje a hatóságoktól, hogy az igazolási kérelmeket a leállás miatt méltányosan bírálják el. Minden 12 óránál hosszabb leállás után 30 napon belül jelenjen meg rövid, nyilvános összefoglaló: mennyi ideig tartott, hány ügyindítás maradt el vagy tolódott, és mekkora volt a tartalék csatornák forgalma. Ez nem azonos a súlyos incidensekre augusztusban javasolt független utóvizsgálattal. Annak egyszerűbb, gyors változata az olyan esetekre, amikor az állam a saját döntésével állítja le a szolgáltatást. A NIS2 üzletmenet-folytonossági követelménye (lásd 6.4.1) a tartalékrendszereket a kötelező minimumba sorolja. A KI1 egyablakos ügyintézési programpont maga is kockázatként rögzíti, hogy egyetlen platform kiesése minden ügyintézést megbénít.

A három javaslat közös elve, hogy a mesterséges intelligencia korában a javítás és a kihasználás közötti idő a döntő változó. Az uniós AI-rendelet (lásd 6.4.3) a nagy modellek fejlesztőitől már tesztelést és incidensjelentést vár el. Az államnak a saját oldalán kell ugyanilyen gyorssá válnia: tudnia kell, mit futtat, meddig javít, és mit tesz az ügyfelekért, amíg javít.

IV. rész — Várható hatások és kockázatok

Dimenzió Várható hatás Kockázat
Közigazgatás A leltár után egy riasztásra órák alatt kiderül, mely rendszerek érintettek; a felelősség az üzemeltető és a beszállító között egyértelművé válik Az első leltár hiányos lesz, és a szervezetek eleinte formális adatszolgáltatásként kezelhetik
Ügyfelek A leállás nem okoz jogvesztést; a nyilvános állapotoldal csökkenti a bizonytalanságot és a felesleges ügyfélforgalmat A szigorú határidő miatt gyakoribbá válhatnak a rövid, elővigyázatossági leállások
Önkormányzatok, iskolák A javítási ügyelet és a központi platform levesz a kis szervezetekről egy olyan terhet, amelyet saját erőből nem tudnak viselni Ha az ügyelet kapacitása kicsi, egy nagy riasztásnál épp a legkitettebb szereplők maradnak sorban a végén
Biztonság Csökken a támadási felület, a támogatáson kívüli verziók száma mérhetővé válik Ha a leltár kiszivárog, a támadók célpontlistát kapnak — ezért csak összesített adat lehet nyilvános
Költségvetés Az ügyelet és a migráció egyszeri költsége kicsi egy többnapos országos ügyintézési kieséshez képest A régi rendszerek frissítése többhetes fejlesztői munkát igényelhet, ami előre nem tervezett kiadás

A legfontosabb dilemma a rendelkezésre állás és a biztonság között feszül. A 72 órás határidő a gyakorlatban több leállást hozhat, mert ahol a frissítés nem fér bele, ott a leválasztás a szabályos megoldás. Az Index által megkérdezett üzemeltetési vezető szerint egy nagy verzióváltás után a régi kód nem biztos, hogy hibátlanul fut, az átállás tesztelése pedig napokig vagy hetekig tarthat. Ezért a 3.2 javaslat csak a 3.3-mal együtt működik: a leválasztás csak akkor elfogadható ára a biztonságnak, ha közben az ügyfél nem veszít jogot. A második dilemma a nyilvánosságé. Az összesített mutatók közzététele fegyelmez, a részletes lista viszont kockázat. A MIAK ezért nem tételes, hanem szervezettípusonkénti közzétételt javasol.

V. rész — Mérhetőség és összegzés

5.1 Mit érdemes követni? (javasolt KPI-k)

A MIAK négy teljesítménymutatót (KPI-t, angolul: Key Performance Indicator) javasol követésre:

  • Javítási vagy leválasztási idő kritikus hibánál — az állami, internet felől elérhető rendszereken a riasztástól a biztonságos állapotig eltelt idő mediánja; javasolt cél: 72 óra alatt 2027 végére, negyedéves közzététellel.
  • Leltárlefedettség — a kritikus állami rendszerek hány százalékáról van naprakész szoftver- és függőségi leltár; javasolt cél: 100% 2027. január 31-re, az önkormányzati és oktatási honlapoknál 2027. június 30-ra.
  • Támogatáson kívüli futtatókörnyezetek száma — hány állami és önkormányzati honlap fut olyan verzión, amely már nem kap biztonsági frissítést; javasolt cél: folyamatos csökkenés, 2028 végére nulla.
  • A központi portál tervezetlen leállási órái és az elszámolás határideje — éves összesítés, és annak aránya, hogy a 12 óránál hosszabb leállásokról 30 napon belül megjelent-e a nyilvános összefoglaló; javasolt cél: 100%.

5.2 Összegzés

A MIAK kérése konkrét: a Kormány 2027. március 31-ig rendeletben rögzítse a kritikus hibák javítási határidejét, és indítson központi javítási ügyeletet a kis szervezeteknek. A szoftverleltár 2027 első felében álljon össze. A magyarorszag.hu leállásairól pedig 2026 végétől nyilvános, igazolt adatok szülessenek, és az ügyfél ne veszítsen határidőt az állam döntése miatt. A mostani leállításról a MIAK azt kéri, hogy 30 napon belül jelenjen meg egy rövid összefoglaló: mennyi ideig tartott, és hány ügy maradt el miatta.

Ebben az ügyben a MIAK két alapértéke érintett. Az adatvezéreltség azért, mert a kiberbiztonsági felkészültség ma nem mérhető: nincs adat arról, hány állami rendszer fut elavult szoftveren és mennyi idő alatt javítják. A leltár és a határidő ezt teszi számmá. Az átláthatóság pedig azért, mert az elővigyázatossági leállás terhét az ügyfelek viselik. Nekik joguk van tudni, mennyi ideig tartott, mibe került, és mi garantálja, hogy a következő alkalommal nem ők fizetnek érte.

VI. rész — Indoklások és további források

6.1 A sajtó keretezése spektrumonként

A balliberális sávban a Telex adta a legrészletesebb technikai magyarázatot. A cikk végigvette, hogyan vált egy 2024-ben megerősített, de kihasználhatatlannak hitt memóriakezelési hibából működő támadás, és hogyan omlott össze a közzétételi embargó (a javítás összehangolt, időzített nyilvánosságra hozatala). A lap keretezése — „de már van megoldás" — a megnyugtatás felé hajlott, ugyanakkor kiemelte, hogy a régi PHP-verziókon futó oldalak jelentős része nem kap hivatalos javítást. A 444.hu az MTI-anyagra és a miniszter szó szerint idézett bejelentésére szorítkozott. A HVG egy nappal korábban még európai történetként hozta a hírt, ausztráliai kitekintéssel, és külön cikkben a mesterséges intelligencia biztonsági szabályozásáról szóló vitát mutatta be.

A közéleti sávban a 24.hu a miniszteri bejelentést és a vállalkozásoknak szóló felhívást tette a középpontba, a Revolut kieséséről pedig technikai okfeltáró cikket közölt. Az Index a „valaha észlelt legsúlyosabb hiba" fordulattal élt, de üzemeltetői szemszögből is bemutatta a problémát: a frissítés után a régi alkalmazás nem feltétlenül fut hibátlanul, ezért a javítás nem egy gombnyomás.

A gazdasági sávban a Portfolio kapcsolta össze a két szálat. Egyik cikke a CVSS-pontszámot, az uniós kiberbiztonsági csapat (CERT-EU) lekapcsolásra vonatkozó felhívását és a kis üzemeltetők kitettségét emelte ki. Másik cikke a Google Cloud kiesése miatt fellépő európai és brit pénzügyi felügyeleteket mutatta be, vagyis a felhőszolgáltatóktól való koncentrált függőséget mint pénzügyi stabilitási kérdést.

A konzervatív sávban a Magyar Nemzet a külföldi rovatban, „Mi folyik itt?" kezdetű címmel, európai válságként keretezte az esetet. Azt hangsúlyozta, hogy a mesterséges intelligencia a támadóknak is automatizált, tömeges eszközt adhat. A hazai leállásnál a miniszter bejelentését tárgyszerűen, a 48 órás ügyintézési szünetre fókuszálva idézte. A Mandiner és a Népszava aznapi kínálata nem volt elérhető a monitor számára, így a jobboldali és a baloldali sáv egy-egy szereplője hiányzik a képből.

6.2 Tények és adatok

Adat Érték Forrás
A két sérülékenység súlyossága 9,2 pont a 10-es CVSS v4.0 skálán, mindkettő kritikus (CVE-2026-109618 és CVE-2026-109619) NBSZ NKI riasztás, 2026. október 21.; Portfolio
A hibák jellege hitelesítés nélküli, távoli kódfuttatás webszervereken NBSZ NKI; 444.hu (MTI)
Javított PHP-verziók 8.2.35, 8.3.36, 8.4.27, 8.5.12 (megjelenés: október 21.) NBSZ NKI, 2026. október 22.
Támogatáson kívüli ágak a PHP 8.1 és korábbi verziók hivatalos frissítést nem kapnak; egyes disztribúciók visszamenőleges javítást adhatnak NBSZ NKI
A PHP részesedése az ismert szerveroldali technológiájú honlapok közel 70%-a W3Techs, Telex, 2026. október 22.
7-es vagy régebbi PHP-n futó honlapok az ismert honlapok durván 31%-a W3Techs, Telex
A hibák bejelentése a PHP fejlesztőinek Calif: augusztus 11.; Wiz: augusztus 24. Portfolio, 2026. október 21.
Első észlelt kihasználási kísérlet október 17. (a PHP Alapítvány szerint működő támadókód a hivatalos javításig nem volt elérhető) Amazon, Portfolio és Telex szerint
A magyarorszag.hu leállása az október 21-ről 22-re virradó éjszaka; bejelentett várható időtartam 48 óra; újraindítás csütörtök délután Tanács Zoltán bejelentése (24.hu, Portfolio, 444.hu); Telex
Érintett európai országok Hollandia, Finnország, Dánia, Franciaország; Ausztráliában is volt leállítás MTI (Index, Telex, 444.hu); HVG
Google Cloud kiesés október 20., 8:08 (magyar idő), londoni régió; Revolut, HSBC, Lloyds, Bank of Scotland érintett 24.hu, 2026. október 20.
Uniós felhőfelügyelet az EU tavaly 19 technológiai céget jelölt ki a pénzügyi szektor szempontjából kritikus szolgáltatóként Portfolio, 2026. október 22.

A táblázat két sora a legfontosabb. Az egyik szerint a honlapok közel harmada olyan régi verzión fut, amelyre a hivatalos javítás nem érkezik meg. A másik szerint az első támadási kísérlet négy nappal a nyilvánosságra hozatal előtt megtörtént. Együtt azt mutatják, hogy a „telepítsük a frissítést" tanács a rendszerek egy jelentős részénél nem azonnal végrehajtható. A javítás és a kihasználás közötti idő ezért nem a frissítés megjelenésekor, hanem korábban kezdődik. Ezt az időt csak az tudja kihasználni, aki előre ismeri a saját rendszereit.

6.3 Szakpolitikai vetületek

  • Digitalizáció és AI-szabályozás (programpontok) — a kiberbiztonsági stratégia (programpont ID: D5) önkormányzati minimumsztenderdje és a vészhelyzeti gyakorlatok adják a 3.1 és a 3.2 javaslat alapját; a szuverén állami infrastruktúra (programpont ID: D17) a tárhely- és felhőfüggőség nyilvántartását indokolja; a felelős AI keretrendszer (programpont ID: D1) az AI-alapú sérülékenységkeresés kettős felhasználására ad szabályozási hátteret;
  • Közigazgatás és e-kormányzat (programpontok) — az egyablakos digitális ügyintézés (programpont ID: KI1) maga rögzíti, hogy egyetlen platform kiesése minden ügyintézést megbénít, ez a 3.3 javaslat kiindulópontja; az önkormányzati digitalizáció (programpont ID: KI4) központi platformja hosszabb távon kiváltja a kis szervezetek saját, gondozatlan honlapjait;
  • Honvédelem (programpontok) — a kibervédelmi kapacitásfejlesztés (programpont ID: HV1) a nyilvánosan mért felderítési és válaszidőt kéri, ezt a 3.2 javaslat javítási határideje konkretizálja;
  • Közbiztonság és rendészet (háttéranyag) — a sérülékeny honlapokon keresztüli adatlopás és csalás az online bűnözés egyik fő belépési pontja;
  • Gazdaság (programpontok) — a Google Cloud kiesése a pénzügyi stabilitási monitoring (programpont ID: G22) szempontjából is jelzés: néhány nagy felhőszolgáltató kiesése egyszerre több bankot érint.

6.4 Szakkönyvi részletezés

6.4.1 Az uniós NIS2 irányelv

A 2022/2555 irányelv 21. cikke tíz pontban sorolja fel azokat a kockázatkezelési intézkedéseket, amelyeket az alapvető és fontos szervezeteknek — köztük a közigazgatásnak — legalább meg kell tenniük. A listán szerepel az „üzletmenet-folytonosság, például tartalékrendszerek kezelése, valamint katasztrófa utáni helyreállítás és válságkezelés", továbbá a „biztonság a hálózati és információs rendszerek beszerzésében, fejlesztésében és karbantartásában, beleértve a sérülékenységek kezelését és közzétételét". Az irányelv (58) preambulumbekezdése szerint a sérülékenységek gyors azonosítása és elhárítása fontos tényező a kockázat csökkentésében, és mivel a hibákat gyakran harmadik felek fedezik fel, a szervezeteknek eljárást kell kialakítaniuk ezek fogadására. A 12. cikk minden tagállamban koordináló CSIRT-et ír elő, amely közvetít a hibát bejelentő és a gyártó között, és egyezteti a közzététel ütemtervét.

A PHP-eset mindkét rendelkezést próbára tette. Az összehangolt közzététel a gyártói oldalon kudarcot vallott, mert a részletek a tervezett időpont előtt kiszivárogtak. Ilyenkor az üzemeltetőn múlik, mennyi időt veszít. A 21. cikk a sérülékenységkezelést kötelezővé teszi, de nem mondja meg, mennyi idő alatt kell javítani. A MIAK 3.2 javaslata ezt a hézagot tölti ki hazai határidővel, a 3.3 javaslat pedig az üzletmenet-folytonosság követelményét fordítja le az ügyfelek nyelvére.

📖 Forrás: Az Európai Parlament és a Tanács (EU) 2022/2555 irányelve (NIS2)

6.4.2 A Cyber Resilience Act javaslata

Az Európai Bizottság 2022-es javaslata a digitális elemeket tartalmazó termékekre teljes életciklusra kiterjedő kiberbiztonsági követelményeket ír elő. A rendelet a kategória-index szerint 2024 végén lépett hatályba, a tudásbázisban a javaslat szövege érhető el. A gyártóknak a melléklet szerint „azonosítaniuk és dokumentálniuk kell a termékben található sebezhetőségeket és alkotóelemeket, többek között egy általánosan használt és géppel olvasható formátumú szoftveranyagjegyzék elkészítésével". A javaslat a termék várható élettartama alatt, legfeljebb öt évig kötelezővé teszi a sebezhetőségek kezelését, és 24 órás bejelentést ír elő az aktívan kihasznált hibákra az uniós kiberbiztonsági ügynökség (ENISA) felé. A (10) preambulumbekezdés szerint ugyanakkor a nem kereskedelmi tevékenység keretében fejlesztett szabad és nyílt forráskódú szoftver nem tartozik a rendelet hatálya alá.

Ez a kivétel adja a PHP-eset szabályozási tanulságát. Maga a nyelv, egy alapítvány által gondozott nyílt forráskódú projekt, kívül esik a gyártói kötelezettségeken. A felelősség így azoknál marad, akik termékbe vagy szolgáltatásba építik — köztük az államnál mint üzemeltetőnél. A szoftveranyagjegyzék logikája ezért az állam saját rendszereire is érvényesnek kell lennie. Aki nem tudja, milyen alkotóelemekből áll a rendszere, nem tudja megmondani, érinti-e egy riasztás. Ez a 3.1 javaslat közvetlen indoka.

📖 Forrás: Európai Bizottság: COM(2022) 454 — javaslat a digitális elemeket tartalmazó termékekre vonatkozó horizontális kiberbiztonsági követelményekről szóló rendeletre (Cyber Resilience Act), főszöveg és mellékletek

6.4.3 Az uniós mesterségesintelligencia-rendelet

A 2024/1689 rendelet (110) preambulumbekezdése az általános célú AI-modellek rendszerszintű kockázatai között külön említi a támadó kiberképességeket, „such as the ways in vulnerability discovery, exploitation, or operational use can be enabled" — vagyis azt, ahogyan a modellek megkönnyíthetik a sérülékenységek felfedezését, kihasználását és éles bevetését. Az 55. cikk a rendszerszintű kockázatot jelentő modellek szolgáltatóitól ellenséges tesztelést, a súlyos események dokumentálását és jelentését, valamint megfelelő kiberbiztonsági védelmet követel.

A PHP-eset mindkét oldalt megmutatta. A hibákat AI-val találták meg, és a cégek szerint emberi elemzőkkel ez gyakorlatilag lehetetlen lett volna. A szakértők szerint ugyanezek az eszközök a nyilvános javításokból is gyorsan támadókódot állíthatnak elő. Az AI-rendelet a modellek fejlesztőit szabályozza, nem a hibák által érintett üzemeltetőket. Az államnak ezért a saját oldalán kell felgyorsulnia: a leltár (3.1) és a határidő (3.2) annak a felismerésnek a válasza, hogy a javítás és a kihasználás közötti idő a mesterséges intelligencia miatt tartósan rövidebb lett.

📖 Forrás: Az Európai Parlament és a Tanács (EU) 2024/1689 rendelete (mesterséges intelligencia rendelet)

6.5 Nemzetközi összehasonlítás

Az európai reakciók egyik mintája az volt, hogy a leállítást vállalták, a kockázatot nem. Hollandiában a nemzeti kiberbiztonsági központ a saját honlapját is lekapcsolta, Dániában az iskolák és a szülők közötti országos kapcsolattartó rendszert, Franciaországban a belügyminisztérium a helyi közigazgatási szervek egyes honlapjait. Az uniós intézmények kiberbiztonsági csapata (CERT-EU) kifejezetten arra szólította fel a szervezeteket, hogy amit nem tudnak azonnal frissíteni, azt kapcsolják le. A magyar döntés ebbe a mintába illeszkedik.

A javítási határidőre van működő külföldi minta. Az Egyesült Államok kiberbiztonsági ügynöksége (CISA) nyilvános katalógust vezet a bizonyítottan kihasznált sérülékenységekről, és a szövetségi szerveknek kötelező határidőn belül kell ezeket javítaniuk. A pénzügyi oldalon az EU az ágazat digitális működési ellenálló képességéről szóló rendelet (DORA) alapján jelölte ki a kritikus technológiai szolgáltatókat, köztük a nagy felhőszolgáltatókat, és vonta őket az európai pénzügyi felügyeletek közös felügyelete alá. A Portfolio szerint az Európai Bankhatóság (EBA) a Google Cloud kiesése miatt fel is vette a kapcsolatot a szolgáltatóval. Az Egyesült Királyságban a parlament pénzügyi bizottsága a jegybanktól és a pénzügyi felügyelettől kért tájékoztatást. A brit szabály szerint a bank akkor is felel az ügyfelei felé, ha a hiba a felhőszolgáltatónál keletkezett. Ez a felelősségi elv az állami ügyintézésre is átvihető: a 3.3 javaslat is ezt mondja ki.

6.6 Kapcsolódó MIAK-programpontok

Digitalizáció és AI-szabályozás

  • D1 — Felelős AI keretrendszer
  • D5 — Kiberbiztonsági stratégia
  • D17 — Űr- és szuverén digitális infrastruktúra

Közigazgatás és e-kormányzat

  • KI1 — Egyablakos digitális ügyintézés
  • KI4 — Önkormányzati digitalizáció

Honvédelem

  • HV1 — Kibervédelmi kapacitásfejlesztés

Gazdaság

  • G22 — Pénzügyi stabilitási monitoring és árnyékbank-szabályozás

Javasolt új programpont: Az ügyfélhatáridők védelme a központi e-ügyintézési portál leállásakor — a Közigazgatás és e-kormányzat területre.

6.7 Források jegyzéke

Sajtóforrások (MIAK sajtómonitor, 2026. október 23. — 5. téma, és 2026. október 22. — 6. téma):

Tudásbázis-hivatkozások (szakkönyvek és hivatalos jogforrások):

  • 📖 Az Európai Parlament és a Tanács (EU) 2022/2555 irányelve (NIS2)
  • 📖 Európai Bizottság: COM(2022) 454 — Cyber Resilience Act javaslat (főszöveg és mellékletek)
  • 📖 Az Európai Parlament és a Tanács (EU) 2024/1689 rendelete (mesterséges intelligencia rendelet)

Megjegyzés: a blog látható szövegében nem jelenik meg a források lokális fájlútvonala — csak a szerző és a cím, illetve a jogforrás megjelölése.

MIAK-belső anyagok:

  • MIAK szakpolitikai terület: Digitalizáció és AI-szabályozás (programpontok; programpont ID: D1, D5, D17)
  • MIAK szakpolitikai terület: Közigazgatás és e-kormányzat (programpontok; programpont ID: KI1, KI4)
  • MIAK szakpolitikai terület: Honvédelem (programpontok; programpont ID: HV1)
  • MIAK szakpolitikai terület: Közbiztonság és rendészet (háttéranyag)
  • MIAK szakpolitikai terület: Gazdaság (programpontok; programpont ID: G22)
  • MIAK sajtómonitor, 2026. október 23. — 5. téma, pontszám: 84/100
  • MIAK sajtómonitor, 2026. október 22. — 6. téma, pontszám: 84/100

Kiegészítő nyilvános adatforrások:

Generálási metaadatok

  • Bemeneti sajtómonitor: MIAK sajtómonitor, 2026. október 23. (5. téma), kiegészítve a 2026. október 22-i sajtómonitor 6. témájával
  • Generálás dátuma: 2026. október 23., 08:40 CEST
  • Felhasznált tokenek (összesen): ~210000, becslés (lásd frontmatter tokens_breakdown)

Kapcsolódó korábbi elemzéseink