Az AI feltöri és megvédi a rendszereidet: AI kiberbiztonság, 100% az ExploitBenchen, két zero-day és a Chrome-hibák

Az AI kiberbiztonság 2026 szeptemberében végleg kilépett a konferenciatermekből. Az OpenAI szeptember 3-án bemutatott GPT-6 Astra modellje 100%-os eredményt ért el az ExploitBench nevű teszten, a tesztelése során pedig két, addig senki által nem ismert biztonsági hibát (zero-day sérülékenységet) talált. Szeptember közepén aztán kiderült, hogy a háromfős Hacktron AI biztonsági csapat még júliusban, az Anthropic Claude Opus 5 modelljének segítségével 72 órán belül bejutott OpenAI-dolgozók fiókjaiba, amiért a felelős bejelentés után 6 500 dolláros hibavadász-jutalmat (bug bountyt) kapott. A Chrome böngészőben közben két olyan hibát javított a Google, amelyet a támadók már élesben kihasználtak.

Egy 12 fős webshop vagy egy könyvelőiroda vezetője joggal kérdezi, mi köze mindehhez. A válasz egyszerűbb és kellemetlenebb, mint gondolnád: ugyanaz a képesség, amelyik most a nagy laborok rendszereiben talál rést, néhány hónapon belül olcsón elérhető lesz bárkinek, így a régóta frissítetlen WordPress-bővítmény vagy a kétfaktoros belépés nélküli admin fiók sokkal gyorsabban válik valódi kockázattá. A jó hír az, hogy a védekezéshez is ugyanez az eszköztár áll rendelkezésre. A folytatásban 2026. szeptember 22-i állapot szerint végigvesszük, mi történt pontosan, mit jelent ez egy magyar webshopnak vagy ügyviteli rendszernek, mennyibe kerül a védekezés forintban, végül melyik az a négy teendő, amelyet még ezen a héten érdemes elindítani.

Röviden

• Az OpenAI GPT-6 Astra modellje a 2026. szeptember 3-i bejelentés szerint 100%-ot ért el az ExploitBench teszten (az előd GPT-5.6 Sol 78,5%-ot), a tesztek során két korábban ismeretlen zero-day hibát talált, amelyeket az OpenAI a karbantartóknak jelentett.
• A Hacktron AI háromfős csapata a Claude Opus 5 segítségével 72 órán belül jutott el OpenAI-dolgozói fiókokig, felelős bejelentés után az OpenAI 6 500 dollár jutalmat fizetett, a javítást pedig nagyjából 14 órán belül megerősítette.
• A tanulság egy magyar KKV-nak az, hogy az AI jelentősen csökkenti a támadáshoz szükséges szakértelmet és időt, ezért a nyilvánosságra került hibák és a befoltozásuk között eltelt „türelmi idő” gyakorlatilag nullára zsugorodik.
• A leggyakoribb kis cégeknél látott rés nem egzotikus: elavult CMS vagy bővítmény, kétfaktoros hitelesítés nélküli admin fiók, közös jelszavak, hiányzó naplózás és a harmadik fél szolgáltatásaihoz adott túl széles jogosultság.
• A sürgős teendők sorrendje: minden rendszer és böngésző frissítése, kétfaktoros belépés mindenhol, naplózás és riasztás bekapcsolása, végül egy külső biztonsági audit, amely ma már AI-eszközökkel is gyorsítható.
• Ugyanaz a technológia, amely támadásra képes, védekezésre is használható: az OpenAI Daybreak programja 1 milliárd dollárt szán a védők támogatására, a Google pedig a Fairwind programon keresztül ad kibervédelmi modellt megbízható védőknek.

Mi történt: az Astra 100%-ot ért el az ExploitBenchen és két ismeretlen hibát talált

A GPT-6 Astra az OpenAI 2026. szeptember 3-án bemutatott modellje, amely a cég adatai szerint az ExploitBench kiberbiztonsági teszten 100%-ot ért el, sőt a tesztelés során két, korábban ismeretlen zero-day sérülékenységet is talált. Az OpenAI a modellt a Preparedness Framework nevű saját kockázati keretrendszerében a kiberbiztonság területén „kritikus” képességi szintre sorolta.

Kezdjük a fogalmakkal, mert a hírek címei ritkán magyarázzák el őket. A zero-day sérülékenység olyan szoftverhiba, amelyről a gyártó még nem tud, így javítás sem létezik rá: a „nulla nap” arra utal, hogy a fejlesztőknek nulla napjuk volt a befoltozásra. Az exploit az a program vagy eljárás, amely egy ismert hibát ténylegesen kihasználhatóvá tesz. Az ExploitBench a The Hacker News összefoglalója szerint azt méri, mennyire képes egy modell már ismert szoftverhibákat működő kihasználássá alakítani. Az előd GPT-5.6 Sol ugyanitt 78,5%-ot ért el.

A kép ennél árnyaltabb, ha a többi mérést is megnézzük. Az ExploitGym nevű, összetettebb teszten az Astra eredménye 42,4% volt (a Cloud Security Alliance szeptember 5-i elemzése szerint a Sol ugyanitt 30,3%-ot ért el), a bináris visszafejtési feladatokban 88%-ot. Vagyis a modell az ismert hibák feldolgozásában gyakorlatilag hibátlan, a nyitottabb, valóságosabb feladatoknál viszont még messze nem mindenható. Egy támadónak persze nem kell mindenhatónak lennie: elég, ha a sok ezer kiszemelt rendszerből néhány tucatnál sikerrel jár.

Mit tudunk a két zero-day hibáról?

A két hibáról nagyon keveset hozott nyilvánosságra az OpenAI, ami így van rendjén. A The Hacker News szerint a hibák a 2026 júniusa és augusztusa közötti képességtesztek során kerültek elő, az érintett szoftvert nem nevezték meg. A Cloud Security Alliance kutatási jegyzete azt emeli ki, hogy a hibákat felelős csatornákon jelentették a gyártóknak, további kihasználás nélkül. Ez a felelős közzététel (coordinated disclosure) lényege: a gyártó előbb kap időt a javításra, a nyilvánosság csak utána tudja meg a részleteket.

Egy KKV számára ebből nem az a fontos, melyik program volt érintett, hanem a nagyságrend. Egy olyan modell, amely a rutinszerű tesztelés közben „mellékesen” talál két ismeretlen hibát, nagyon jól mutatja, hogy a szoftverhibák felderítése már nem kizárólag a legjobb emberi szakértők kiváltsága. Ami tegnap hónapokig tartó, drága szakmunka volt, az ma egyre inkább számítási kapacitás kérdése.

Miért nem kaphatja meg bárki a teljes képességet?

Az OpenAI a nyilvános Astra-verziót úgy állította be, hogy a haladó kiberfeladatokat, például a működő kihasználó kód (proof-of-concept exploit) megírását kezdetben megtagadja, helyette a biztonságos kódátvizsgálásra és a javításra koncentrál. A kevésbé korlátozott hozzáférést a Daybreak nevű program adja. A The Hacker News és a Cloud Security Alliance szerint az OpenAI 1 milliárd dollárt szán arra, hogy a védők használhassák a legfejlettebb kiberképességeket: a program első körben amerikai víz- és szennyvízszolgáltatókat, áramhálózat-üzemeltetőket, állami és helyi önkormányzatokat, regionális bankokat, nonprofit szervezeteket és nyílt forráskódú projektek karbantartóit célozza.

Az OpenAI a The Hacker News által idézett bejelentésében így fogalmazott (saját fordításunkban): „van egy védői ablakunk, egy szűkülő lehetőségünk arra, hogy az AI segítségével bezárjuk a biztonsági réseket, mielőtt a támadók kihasználják őket.” A Google hasonló utat választott: a Gemini 3.8 Flash Cyber modellt szeptember 2-től csak a Fairwind programon keresztül, megbízható védőknek teszi elérhetővé. A cég szerint ez a modell 20 programozási nyelven 70% feletti arányban deríti fel a sérülékenységeket.

Tisztán kell látni, mit jelentenek ezek a korlátozások. A gyártói tiltás lassít, de nem állít meg senkit, hiszen a nyílt súlyú modellek (amelyeket bárki letölthet és a saját gépén futtathat) hónapokkal lemaradva, de követik a zárt modellek képességeit. A korlátozás tehát időt ad, amelyet a védőknek érdemes kihasználniuk: ez a „védői ablak” lényege.

Egy Claude-ügynök 72 órán belül feltörte az OpenAI dolgozói fiókjait: mi történt valójában?

A Hacktron AI háromfős biztonsági csapata az Anthropic Claude Opus 5 modelljének segítségével két sérülékenységet kapcsolt össze, így 72 órán belül hozzáfért OpenAI-dolgozók ChatGPT- és Codex-fiókjaihoz. Az eset felelős biztonsági kutatás volt: a csapat bejelentette a hibákat, az OpenAI javította őket, majd 6 500 dolláros hibavadász-jutalmat fizetett.

A történetet a TechCrunch 2026. szeptember 18-i cikke tette ismertté, később a The Hacker News és az AI Weekly is részletesen beszámolt róla. A folyamat magas szinten így nézett ki: az OpenAI közösségi fórumát futtató Discourse, egy széles körben használt nyílt forráskódú fórumszoftver egyik képfeldolgozó komponensében volt egy memóriakezelési hiba, a másik gyenge pontot az OpenAI egyszeri bejelentkezési (single sign-on, SSO) rendszerének egyik hibája jelentette. A két rést összekapcsolva a kutatók bejelentkezett hozzáférést szereztek több OpenAI-dolgozó fiókjához, ezeken keresztül pedig az OpenAI egyik belső kódtárához is eljutottak.

A kutatók a The Hacker News beszámolója szerint a hozzáférést egyetlen ártalmatlan módosítási kérelemmel (pull request) igazolták, forráskódot nem olvastak, változtatást nem vezettek be és ügyféladathoz sem nyúltak. Ez a különbség a felelős biztonsági kutatás és a támadás között: a cél a bizonyítás, a kár elkerülése mellett.

Az idővonal és a jutalom

Az AI Weekly összefoglalója szerint a kutatók július 25-én találták meg a kiinduló hibát, a fórumszoftver fejlesztői július 27-én adtak ki javítást, az OpenAI pedig a bejelentés után nagyjából 14 órával megerősítette, hogy a saját oldalán is javította a problémát. A 6 500 dolláros jutalmat szeptember 1-jén ítélték oda, a nyilvánosság csak ezt követően, szeptember közepén ismerte meg a részleteket. Az AI Weekly szerint a teljes kutatás tokenköltsége 3 000 dollár alatt maradt, ami kerekített 320 Ft-os dollárárfolyammal számolva kevesebb mint 960 000 Ft.

Miért ez a legfontosabb mondat az egész ügyben?

A TechCrunch által idézett nyilatkozat szerint (saját fordításunkban) az előző Claude-modell, az Opus 4.8 „több munkameneten át küszködött” a feladattal, az Opus 5 viszont a megjelenése után „néhány órán belül” sikerrel járt. A cég alapítója, Mohan Pedhapati szerint „az AI csökkenti az exploitok kifejlesztéséhez szükséges ritka szakértelmet: ami korábban hónapokig tartott, az most napok alatt megvan.”

Ugyanilyen fontos, amit a kutatók a The Hacker News szerint hozzátettek: a szakképzett emberi irányítás továbbra is számított, ez nem gomblenyomásra működő, automatikus hackelés volt. Ez a két állítás együtt adja a helyes képet. Az AI nem helyettesíti a tapasztalt biztonsági szakembert, de a munkáját nagyságrendekkel felgyorsítja, ami a jó és a rossz szándékú felhasználókra egyaránt igaz.

Mit tanulhat ebből egy kis cég?

Három tanulság közvetlenül átültethető egy magyar KKV működésére. Az első, hogy a betörés nem az OpenAI saját fejlesztésű, agyonvédett rendszerén kezdődött, hanem egy harmadik féltől származó, nyílt forráskódú fórummotor egyik alkatrészén: a leggyengébb láncszem sokszor egy mellékes, rég elfelejtett rendszer. A második, hogy az egyszeri bejelentkezés kényelmes, de ha egy helyen megbicsaklik, akkor egyszerre nyit ki sok ajtót. A harmadik, hogy a javítás gyorsasága (14 óra) csak akkor ér valamit, ha van valaki, aki a bejelentést fogadja és azonnal cselekszik.

A The Hacker News a védekezéshez két gyakorlati javaslatot is kiemelt: a harmadik féltől származó komponenseket (itt a képfeldolgozó könyvtárat) naprakészen kell tartani, továbbá a nem megbízható forrásból érkező fájlokat elszigetelt környezetben kell feldolgozni. Az egyszeri bejelentkezés hatókörét szűkíteni kell, az érzékeny műveletek előtt pedig újra hitelesítést kell kérni. Ezek nem nagyvállalati luxusok: egy webshopban a termékképek feltöltése, egy ügyviteli rendszerben a számlák PDF-jeinek beolvasása ugyanilyen kívülről érkező fájlfeldolgozás.

Mit jelent az AI kiberbiztonság egy magyar webshopnak vagy ügyviteli rendszernek?

Egy magyar webshopnak vagy ügyviteli rendszernek az AI-alapú hibakeresés elsősorban azt jelenti, hogy a régi, ismert, de be nem foltozott hibák sokkal gyorsabban és olcsóbban válnak kihasználhatóvá. Nem a zero-day a fő veszély, hanem a hónapok óta elérhető, mégis telepítetlen frissítés, amelyet egy AI-val felfegyverzett támadó automatikusan megtalál.

Vessünk egy őszinte pillantást arra, hogyan néz ki egy tipikus magyar KKV informatikai háttere. Van egy WordPress- vagy WooCommerce-alapú weboldal, rajta húsz-harminc bővítménnyel, amelyekből néhányat évek óta senki nem frissített. Van egy számlázó- vagy ügyviteli rendszer, egy könyvelőprogram, egy közös Gmail- vagy Microsoft 365-fiók, esetleg egy Odoo vagy egy egyedi fejlesztésű CRM. A jelszavakat gyakran egy Excel-táblázat vagy a böngésző tárolja, a rendszergazdai feladatokat pedig „az unokaöcs” vagy egy régi szabadúszó végzi, akit évente egyszer hívnak fel. Ez nem szégyen, hanem a magyar kisvállalati valóság, de 2026 őszén már komolyabb kockázat, mint két éve volt.

Egy képzeletbeli debreceni webshop

Vegyünk egy képzeletbeli debreceni webshopot, amely háztartási kisgépeket árul WooCommerce-szel, havi 4 000 rendeléssel. A bolt tulajdonosa két éve telepített egy termékszűrő bővítményt, amelynek fejlesztője időközben felhagyott a munkával, így a bővítmény egyik ismert hibájára soha nem érkezett javítás. Korábban egy ilyen elhagyott bővítmény megtalálása és kihasználása egy támadónak kézi munka volt, ezért a kisebb boltok sokszor „nem érték meg a fáradságot”. Ma egy AI-val támogatott, automatizált eszköz rövid idő alatt végigpásztázhat ezer webshopot, felismerheti a sérülékeny verziót, a támadó pedig a kiválasztott célpontokra koncentrálhat.

A webshopnál a kockázat nemcsak az, hogy „leáll az oldal”. A vevők nevei, címei, telefonszámai személyes adatok, így egy adatszivárgás a GDPR szerint főszabályként bejelentési kötelezettséggel jár a magyar adatvédelmi hatóság, a NAIH felé. Ha a támadó a fizetési oldalt is módosítja, a bankkártyaadatok is veszélybe kerülhetnek, még akkor is, ha a fizetést egy külső szolgáltató kezeli. A frissítési fegyelem egy webshopnál ezért nem informatikai apróság, hanem üzletfolytonossági kérdés.

Egy képzeletbeli budapesti könyvelőiroda

Mondjuk egy 8 fős budapesti könyvelőirodát, amely 140 ügyfél bizonylatait kezeli egy felhőalapú ügyviteli rendszerben. Az iroda munkatársai ugyanazzal a jelszóval lépnek be a közös postafiókba, ahová az ügyfelek naponta több tucat PDF-számlát küldenek. Az OpenAI-esetből ismerős minta itt is megvan: kívülről érkező fájlokat dolgoz fel egy rendszer, miközben egyetlen fiók több szolgáltatáshoz ad hozzáférést. Ha a közös fiók jelszava kiszivárog, a támadó egyszerre látja 140 cég pénzügyi adatait, ráadásul hiteles feladóként küldhet hamis „új bankszámlaszám” leveleket az ügyfeleknek.

A könyvelőiroda esetében az AI a támadó oldalán főleg a megtévesztésben segít: a tökéletes magyarsággal megírt, az adott ügyfél korábbi leveleinek stílusát utánzó csaló e-mail már nem árulkodik helyesírási hibákkal. A védekezésnek ezért nem az a kérdése, hogy észreveszi-e a munkatárs a gyanús levelet, hanem hogy egy ellopott jelszó önmagában elég-e a belépéshez. Kétfaktoros hitelesítéssel nem elég.

Egy képzeletbeli kecskeméti asztalosüzem

Tegyük fel, hogy egy 12 fős kecskeméti asztalosüzemnek egy bemutatkozó WordPress-oldala van ajánlatkérő űrlappal, egy Odoo ERP-je az árajánlatokhoz és a gyártásütemezéshez, valamint egy irodai hálózata, amelyen a CNC-gép vezérlő számítógépe is lóg. Az üzem vezetője joggal gondolhatja, hogy „minket ugyan ki akarna feltörni”. A válasz az, hogy valószínűleg senki személyesen, de az automatizált támadások nem válogatnak: a feltört weboldalt kéretlen hirdetések terjesztésére, adathalász oldalak tárolására vagy más támadások kiinduló pontjaként használják. Egy irodai gépre bejutott zsarolóvírus a gyártásütemezést is megbéníthatja, ami egy asztalosüzemnél napokban mért bevételkiesést jelent.

Az asztalosüzem példája azt mutatja, hogy a kiberbiztonság egy kis cégnél nem csak a weboldalról szól. A legérzékenyebb pont gyakran az a rendszer, amelyre senki nem gondol: a régi Windows a műhelyben, a gyártó által sosem frissített router vagy a távoli eléréshez évekkel ezelőtt beállított, azóta elfelejtett hozzáférés.

Miért zsugorodik nullára a frissítésig hagyott türelmi idő?

A türelmi idő azért zsugorodik, mert az AI-modellek a nyilvánosságra került hibák leírásából gyorsan képesek működő kihasználást készíteni, így a javítás megjelenése és az első támadások között eltelt idő napokra vagy órákra csökken. A Cloud Security Alliance szeptemberi elemzése szerint az internetről elérhető rendszereknél már azzal kell számolni, hogy ez az idő nulla.

A hagyományos gondolkodás úgy szólt, hogy ha a gyártó kiad egy javítást, akkor van néhány hét, amíg a támadók kidolgozzák a kihasználás módját. Ezt a heteket használták a kis cégek (és sok nagy is) arra, hogy „majd a hónap végén frissítünk, ha lesz rá idő”. Az ExploitBench-eredmény pontosan ezt a feltételezést kérdőjelezi meg: ha egy modell az ismert hibák 100%-át képes kihasználhatóvá alakítani, akkor a javítás közzététele gyakorlatilag térképet ad a támadóknak arról, hol érdemes próbálkozni.

A Cloud Security Alliance 2026. szeptember 5-i kutatási jegyzete ezért azt javasolja, hogy a szervezetek térjenek át a „folyamatos sérülékenységkezelési működésre” a periodikus „szkennelünk, aztán foltozunk” ciklus helyett. Egy nagyvállalatnál ez külön csapatot jelent. Egy KKV-nál sokkal egyszerűbb: automatikus frissítések mindenhol, ahol lehetséges, mellettük egy felelős, aki hetente egyszer tényleg ránéz, mi maradt ki.

A Chrome mint intő példa

A böngésző a legjobb példa arra, milyen gyorsan kell ma frissíteni. A Help Net Security 2026. szeptember 4-i cikke szerint a Google a Chrome 152.0.7977.82-es és .83-as verziójában javított egy olyan hibát a V8 JavaScript-motorban (CVE-2026-85046), amelyet a Google közlése szerint már élesben kihasználtak. A Security Affairs szeptember 9-i beszámolója szerint néhány nappal később a Chrome 153.0.8010.36-os és .37-es verziója egy újabb, szintén a V8-at érintő és aktívan kihasznált hibát (CVE-2026-87491) zárt be. A Security Affairs számítása szerint ez volt 2026 hetedik aktívan kihasznált Chrome zero-day hibája.

A Chrome 153-as és 154-es kiadásainak 42 biztonsági javításáról külön cikkben írunk, itt most csak a gyakorlati tanulságra koncentrálunk. A Chrome letölti ugyan a frissítést magától, de a javítás csak a böngésző újraindítása után él. Egy irodában, ahol a munkatársak hetekig nem zárják be a böngészőt, harminc megnyitott fülön dolgoznak és a gépet csak alvó állapotba teszik, a „frissített” Chrome valójában napokig vagy hetekig a sérülékeny verziót futtatja. A megoldás egyszerű: hetente egyszer mindenki indítsa újra a böngészőjét, céges környezetben pedig az adminisztrátor kényszerítheti az újraindítást.

Hogyan véd az AI a támadások ellen?

Az AI a védekezésben ugyanazt tudja, mint a támadásban: gyorsan átnézi a kódot, megtalálja a hibás beállításokat, elemzi a naplókat és rangsorolja, mit kell először javítani. A különbség az, hogy a védő tudja, mit keres a saját rendszerében, így az eredményt azonnal javításra fordíthatja.

A nagy AI-laborok mind ezt az üzenetet erősítik. Az OpenAI a nyilvános Astra-verziót kifejezetten a biztonságos kódátvizsgálásra és a javításra hangolta, a Daybreak program pedig kevésbé korlátozott hozzáférést ad a kritikus infrastruktúrát védőknek. A Google a Gemini 3.8 Flash Cyber modellt a Fairwind programon keresztül kínálja megbízható védőknek. Maga a Hacktron is AI-alapú biztonsági cég, amely a Claude segítségét felelős kutatásra, vagyis egy hiba megtalálására és bejelentésére használta, nem kártevésre.

Egy magyar KKV nem fog Daybreak-hozzáférést kapni, de nincs is rá szüksége. A kereskedelmi forgalomban elérhető modellek és a rájuk épülő biztonsági szolgáltatások ma is jól használhatók olyan feladatokra, amelyek korábban drága szakértői időt igényeltek.

Mire használható az AI a védekezésben egy kis cégnél?

• Egyedi fejlesztésű kód átvizsgálása: egy webshop saját bővítménye, egy egyedi CRM vagy egy régi PHP-alapú ügyviteli modul biztonsági szempontú átnézése, a talált hibák magyarázatával és javítási javaslattal.
• Beállítások ellenőrzése: a tárhely, a CMS, a Microsoft 365 vagy a Google Workspace biztonsági beállításainak összevetése a gyártói ajánlásokkal, érthető magyar nyelvű összefoglalóval.
• Naplóelemzés: a szerver és a webalkalmazás naplóiban a szokatlan mintázatok (például éjszakai tömeges belépési kísérletek, ismeretlen országból érkező admin belépések) kiszűrése és emberi nyelven való összefoglalása.
• Adathalász levelek felismerése: a gyanús e-mailek előszűrése, a munkatársaknak szóló figyelmeztetéssel.
• Szabályzatok és oktatás: egyszerű, a cég méretéhez illő biztonsági szabályzat megírása és rövid oktatóanyag készítése a munkatársaknak.

Egy fontos korlátot viszont nem szabad elfelejteni. Az AI által talált „hibák” egy része téves riasztás, bizonyos valódi hibákat viszont az AI egyszerűen nem vesz észre. Az OpenAI saját adatai szerint az Astra a nyitottabb ExploitGym feladatoknak is csak 42,4%-át oldotta meg, ami jól mutatja, hogy a védekező felhasználásban is számolni kell a tévedésekkel és a kimaradt hibákkal. Az AI-t ezért érdemes gyorsítónak tekinteni, amely a szakember munkáját teszi hatékonyabbá, de nem váltja ki a döntést arról, mi valódi kockázat és mi nem.

Mit ne adj oda egy AI-eszköznek?

A védekezésre használt AI-eszköz maga is kockázati pont lehet, ha rossz helyen, rossz jogosultsággal fut. Ne másold be jelszavakat, API-kulcsokat, adatbázis-mentéseket vagy ügyféllistákat egy ingyenes, nyilvános chatfelületre, egy AI-ügynöknek pedig ne adj élő rendszerben írási jogot csak azért, hogy „nézzen körül”. A kódátvizsgáláshoz elég a kód egy másolata, a naplóelemzéshez egy olyan kivonat, amelyből a személyes adatokat előtte kiszűrted. Ha a céges adatot külső AI-szolgáltatónak adod át, a GDPR szerint ez adatfeldolgozásnak minősülhet, ezért vállalati csomagra és adatfeldolgozói szerződésre van szükség.

Sürgős teendők: frissítés, kétfaktoros belépés, naplózás, biztonsági audit

A legsürgősebb négy teendő egy magyar KKV-nál a következő: minden szoftver és böngésző frissítése, kétfaktoros hitelesítés bekapcsolása minden fontos fióknál, a naplózás és a riasztások beállítása, végül egy külső biztonsági audit. Ezek együtt kiszűrik az automatizált, AI-val gyorsított támadások döntő többségét.

A sorrend nem véletlen. A frissítés zárja be a már ismert réseket, amelyeken a támadások többsége bejön, a kétfaktoros belépés megakadályozza, hogy egy ellopott jelszó önmagában elég legyen, a naplózás pedig biztosítja, hogy ha mégis baj van, arról időben tudj. Az audit ezután mutatja meg, mi maradt ki. Aki az audittal kezd, az jellemzően egy hosszú hibalistát kap olyan tételekkel, amelyeket az első három lépés magától megoldott volna.

Lépésről lépésre: az első 30 nap

• Készíts leltárt (1. hét): írd össze egy táblázatba az összes rendszert, amelyet a cég használ (weboldal, webshop, tárhely, domainregisztrátor, e-mail, számlázó, könyvelőprogram, CRM, ERP, felhőtárhely, közösségi fiókok), majd mindegyik mellé írd oda, ki a felelőse és ki fér hozzá admin jogosultsággal.
• Frissíts mindent (1. hét): a CMS-t, az összes bővítményt és témát, a PHP-verziót a tárhelyen, az irodai gépek operációs rendszerét, a böngészőket és a routert. A WordPress-oldalaknál a 7.1.1-es biztonsági kiadás telepítése most különösen sürgős, erről külön cikkben írunk.
• Töröld, amit nem használsz (1. hét): az inaktív bővítményeket, a régi admin fiókokat, a volt munkatársak és a volt szabadúszók hozzáféréseit, a teszt aloldalakat. Ami nincs, azt nem lehet feltörni.
• Kapcsold be a kétfaktoros hitelesítést (2. hét): először az e-mailnél, a domainregisztrátornál, a tárhelynél és a banknál, utána a CMS admin fiókjainál, a számlázónál és a közösségi fiókoknál.
• Vezess be jelszókezelőt (2. hét): minden munkatárs saját fiókkal lépjen be mindenhová, a közös jelszavakat egy céges jelszókezelő tárolja, ne egy Excel-táblázat.
• Állítsd be a naplózást és a riasztást (3. hét): a CMS-ben, a tárhelyen és a felhőszolgáltatásokban legyen bekapcsolva a belépések és az admin műveletek naplózása, te pedig kapj e-mailes értesítést az új eszközről történő admin belépésről.
• Ellenőrizd a mentéseket (3. hét): legyen napi, a tárhelytől független helyen tárolt mentés, a visszaállítást pedig egyszer próbáld is ki. A ki nem próbált mentés csak remény.
• Rendelj külső auditot (4. hét): egy független szakember nézze át az internetről elérhető rendszereket, a jogosultságokat és a beállításokat, majd adjon rangsorolt, forintosított javítási tervet.

Frissítés: miért nem elég az „automatikus”?

Az automatikus frissítés jó kiindulás, de önmagában nem elég, mert három tipikus helyen elakad. Az első a fizetős bővítmény, amelynek licence lejárt, így a frissítés csendben leáll. A második az elhagyott bővítmény, amelyhez a fejlesztő már nem ad ki javítást, tehát nincs mit frissíteni: ezt le kell cserélni. A harmadik a tárhely PHP-verziója, amelyet sokszor senki nem mer emelni, mert „hátha elromlik valami”. Ez utóbbi hamarosan kényszerű lesz: a WooCommerce a 2027 januárjára tervezett 11.5-ös verziótól már nem támogatja a PHP 7.4-et és a 8.0-t.

Egy jó gyakorlat a heti tízperces „frissítési kör”: egy kijelölt munkatárs vagy a külső üzemeltető minden hétfőn ránéz a CMS frissítési oldalára, a tárhely vezérlőpultjára és a böngészők verziójára. Ha a frissítés után valami elromlik, arra van a mentés és a tesztkörnyezet, amely egy komolyabb webshopnál ma már alapelvárás.

Kétfaktoros belépés: hol kezdd?

A kétfaktoros hitelesítés (2FA) azt jelenti, hogy a jelszó mellé egy második bizonyíték is kell a belépéshez, például egy telefonos hitelesítő alkalmazásban megjelenő kód vagy egy fizikai biztonsági kulcs. A Hacktron-eset egyik tanulsága éppen az volt, hogy az egyszeri bejelentkezés egy ponton keresztül sok rendszert nyit ki, ezért az érzékeny műveletek előtt újbóli hitelesítést kell kérni.

Egy KKV-nál a prioritási sorrend egyszerű. Az e-mail fiók az első, mert azon keresztül minden más jelszó visszaállítható. A domainregisztrátor és a tárhely a második, mert ezek elvesztésével a weboldal és az e-mail egyszerre kerülhet idegen kézbe. Utána jöhet a bank, a számlázó, a CMS és a közösségi fiókok. Az SMS-ben érkező kód jobb a semminél, de a hitelesítő alkalmazás vagy a jelszó nélküli belépési kulcs (passkey) biztonságosabb, mert nehezebb eltéríteni.

Naplózás: tudd meg időben, ha baj van

A naplózás a legkevésbé látványos, mégis az egyik legértékesebb teendő, mert nélküle sokszor hetekig nem derül ki egy betörés. A Hacktron-esetben a kutatók maguk jelentették be a hozzáférést, egy valódi támadó viszont nem jelentkezik. Egy kis cégnek nem kell saját biztonsági felügyeleti központ: elég, ha a CMS, a tárhely, a Microsoft 365 vagy a Google Workspace riasztást küld az új eszközről történő admin belépésről, a jelszóváltoztatásról és a szokatlan helyről érkező bejelentkezésről.

A naplókat érdemes legalább 90 napig megőrizni, lehetőleg nem ugyanazon a szerveren, amelyet védenek, mert egy betörő első dolga lehet a nyomok eltüntetése. Itt tud az AI a leglátványosabban segíteni: egy hónapnyi, több ezer soros naplót egy modell percek alatt összefoglal, majd emberi nyelven jelzi, mi tér el a megszokottól.

Biztonsági audit: mit kérj számon?

A biztonsági audit egy független szakember által végzett, dokumentált átvizsgálás, amely feltérképezi a rendszerek gyenge pontjait és rangsorolt javítási tervet ad. Egy KKV-nak nem kell teljes körű behatolásteszt (amelynek során engedéllyel, ellenőrzött módon próbálják megtörni a rendszert), egy alapos konfigurációs és frissítési audit is sokat ér.

Mennyibe kerül a védekezés egy KKV-nak forintban?

Egy 5 és 50 fő közötti KKV-nál az alapszintű védekezés havi néhány tízezer forintból megoldható, egy egyszeri külső audit pedig saját becslésünk szerint 160 000 és 240 000 Ft közé esik. Ez töredéke annak, amibe egy néhány napos leállás vagy egy adatszivárgás kerülhet.

Az alábbi számítások saját becslések, a feltételezéseket minden esetben feltüntetjük. Az óradíjnál 10 000 Ft-os fejlesztői óradíjjal, a dollárnál kerekített 320 Ft-os árfolyammal számolunk (a tényleges árfolyam 2026. szeptember 21-én kb. 317 Ft volt).

A rendszeres karbantartás

Egy átlagos WordPress- vagy WooCommerce-oldal heti frissítési köre, a havi mentésellenőrzés és a naplók átnézése saját becslésünk szerint havonta nagyjából három fejlesztői órát igényel, ez 10 000 Ft-os óradíjjal havi 30 000 Ft. A kétfaktoros hitelesítés a Google és a Microsoft céges szolgáltatásaiban díjmentesen bekapcsolható, a WordPresshez ingyenes bővítmények is elérhetők, a hitelesítő alkalmazások szintén ingyenesek, így itt jellemzően csak a bevezetésre fordított munkaidő a költség.

Mennyibe kerül egy AI-alapú kódátvizsgálás?

Vegyünk egy képzeletbeli, 15 000 soros egyedi webshop-bővítményt. Ha soronként átlagosan 10 tokennel számolunk, a teljes kód körülbelül 150 000 token. Egy alapos, három menetben végzett átvizsgálás ennek háromszorosát, 450 000 bemeneti tokent, valamint mondjuk 80 000 kimeneti tokent használ el. A GPT-6 Astra listaárával (10 dollár millió bemeneti és 50 dollár millió kimeneti tokenenként) ez 4,5 plusz 4 dollár, összesen 8,5 dollár, azaz kb. 2 720 Ft. A Meta Muse Spark 1.3 árával (1,25 és 4,25 dollár) ugyanez kb. 0,9 dollár, vagyis nagyjából 290 Ft.

A tokenköltség tehát elhanyagolható. A valódi költség a szakember ideje, aki a talált hibákat ellenőrzi, kiszűri a téves riasztásokat és megírja a javítást. Ha ez négy óra, akkor 40 000 Ft, ami még mindig jóval kevesebb, mint amennyibe az ugyanilyen alapos, teljesen kézi átnézés kerülne.

Mibe kerülhet, ha nem teszel semmit?

Maradjunk a képzeletbeli debreceni webshopnál, amely havi 4 000 rendelést teljesít. Ha az átlagos kosárérték 18 000 Ft, akkor a havi forgalom 72 millió Ft, ami napi nagyjából 2,4 millió Ft. Egy háromnapos leállás tehát kb. 7,2 millió Ft kiesett forgalmat jelent, amelyben még nincs benne a helyreállítás munkadíja, a vevők elvesztett bizalma, egy esetleges adatvédelmi eljárás vagy a Google-találatok visszaesése egy feltört, kéretlen tartalommal teleszórt oldal után. Ehhez képest az évi 360 000 Ft-os karbantartás és egy 200 000 Ft körüli audit együtt is egy nap forgalmának töredéke. A forgalom persze nem azonos a nyereséggel, a nagyságrend azonban így is beszédes.

Vonatkozik rád a magyar kiberbiztonsági törvény (NIS2)?

Az 5 és 50 fő közötti KKV-k többségére a magyar kiberbiztonsági törvény közvetlenül nem vonatkozik, mert a szabály jellemzően a meghatározott ágazatokban működő közép- és nagyvállalatokat érinti. Közvetetten viszont sok kis cég is kap elvárásokat, ha ilyen nagyobb partner beszállítója.

A 2024. évi LXIX. törvény Magyarország kiberbiztonságáról az EY összefoglalója szerint 2025. január 1-jén lépett hatályba. A törvény az Európai Unió NIS2 irányelvét ülteti át a magyar jogba. A felügyeletet a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) látja el. Az SZTFH 2025. szeptember 19-i közleménye szerint az érintett szervezeteknek 2025. augusztus 31-ig kellett szerződést kötniük a hatóság listáján szereplő auditorok egyikével, az első kötelező kiberbiztonsági auditot pedig 2026. június 30-ig kellett lezárniuk. A hatóság 2025. szeptember 15-én megkezdte azoknak a szervezeteknek az ellenőrzését, amelyek nem teljesítették ezeket a kötelezettségeket.

Egy kisebb cég számára a gyakorlati következmény az ellátási lánc. A NIS2 hatálya alá tartozó szervezeteknek a beszállítóik biztonságával is foglalkozniuk kell, ezért előfordulhat, hogy egy energetikai, egészségügyi, közlekedési vagy élelmiszeripari partner biztonsági kérdőívet küld, sőt szerződésben kér kétfaktoros belépést, naplózást vagy incidensbejelentési vállalást. Aki ezekre már most tud igennel felelni, az előnyből indulhat egy beszállítói kiválasztásnál. Ha nem vagy biztos benne, hogy a céged érintett-e, a törvény szövegét és az SZTFH tájékoztatóit érdemes egy szakértővel közösen átnézni.

Mire figyelj, ha AI-ügynököt engedsz a céges rendszerek közelébe?

Ha AI-ügynököt kötsz be a céges rendszerekbe, adj neki külön fiókot, csak a feladathoz szükséges jogosultságot, minden következményes lépés előtt pedig kérj emberi jóváhagyást. Az ügynök minden műveletéről készüljön tőle független napló, mert maga az AI-eszköz is lehet biztonsági rés.

Az AI kiberbiztonság kérdése ugyanis nemcsak arról szól, hogy a támadók AI-t használnak, hanem arról is, hogy a céged által bevezetett AI-eszközök maguk is hibásak lehetnek. A szeptemberi hírek ezt több oldalról is megerősítették. Szeptember 7-én kiderült, hogy a népszerű LiteLLM modellközvetítő réteg MCP-hitelesítésében aktívan kihasznált bejelentkezés-megkerülési hiba volt, amelyen keresztül a csatolt eszközök is elérhetővé váltak. A DeepSeek sandboxában a CVE-2026-82533 azonosítójú hiba miatt a futtatási korlátozások megkerülhetők voltak. A Z.ai ZCode nevű fejlesztői eszközéről kiderült, hogy csendben 313 MB-os munkaterület-archívumokat töltött fel (a Z.ai ezután nyílt forráskódúvá tette az eszközt), Patrick Wardle biztonsági kutató pedig a Meta Muse macOS-alkalmazásában talált olyan hibát, amelyen keresztül egy helyi alkalmazás megszerezhette a Muse hitelesítési tokenjét. Az AI-ügynökök adatvédelmi kockázatairól és a spanyol adatvédelmi hatóság vizsgálatáról külön cikkekben írunk részletesen.

A gyakorlati szabályok egy KKV-nál jól kezelhetők. A Cloud Security Alliance azt javasolja, hogy egy olyan erős modell bekapcsolását, mint az Astra, kezeljék kiemelt jogosultságú változtatásként, amelyhez biztonsági jóváhagyás kell, ne rutinszerű kapcsolóként. Ezzel összhangban az OpenAI a vállalati ChatGPT-munkaterületeken alapból kikapcsolva hagyta az Astrát, az adminisztrátornak kell engedélyeznie. Egy kis cégnél ez annyit jelent, hogy az ügyvezető tudjon róla, melyik AI-eszköz milyen rendszerhez fér hozzá, ezt pedig a leltárban (a 30 napos terv első lépésében) is rögzítsd.

• Az ügynök kapjon saját, névvel ellátott fiókot, ne a tulajdonos vagy egy munkatárs fiókját használja.
• Ahol elég az olvasási jog, ott ne kapjon írási jogot, élő webshopban pedig a rendelések és a fizetési beállítások módosítása maradjon emberi feladat.
• A kívülről érkező tartalmat (e-mailt, feltöltött fájlt, weboldalt) az ügynök adatként kezelje, ne utasításként, erre a rendszer tervezésénél kell figyelni.
• Az ügynök műveleteiről a szolgáltatótól független napló készüljön, amelyet egy ember rendszeresen átnéz.
• A bekötött eszközöket (MCP-szervereket, integrációs rétegeket) ugyanúgy frissíteni kell, mint a CMS-t, mert a hibák nemcsak a modellekben, hanem a köztes rétegekben is előfordulnak.

Mire számíthatsz az AI kiberbiztonság terén a következő hónapokban?

A következő hónapokban a támadó és a védő oldali AI-képességek is gyorsan terjednek: a zárt modellek korlátozott kiberfunkciói fokozatosan bővülnek, a nyílt súlyú modellek pedig felzárkóznak. Egy KKV-nak ezért most kell rendbe tennie az alapokat, mert a türelmi idő tovább rövidül.

A Cloud Security Alliance szerint a Daybreak támogatása várhatóan hat hónapon belül elfogy, ami azt jelzi, hogy a legerősebb kibervédelmi eszközök gyorsan terjednek a védők körében. Az OpenAI szeptember 29-én tartja a DevDay 2026 fejlesztői konferenciát San Franciscóban, ahol újabb ügynöki és biztonsági bejelentések várhatók. A Reuters szeptember 19-i értesülése szerint az Anthropic a tőzsdére lépése előtt egy új modell kiadását fontolgatja, a versenyfutás tehát nem lassul.

A nyílt súlyú modellek oldalán is nagy a mozgás. A DeepSeek-V4.1-Flash MIT-licenccel érhető el, a StepFun a Step 5 modell nyílt súlyait október 15-re ígérte. Ezeket a modelleket bárki letöltheti és a gyártói korlátozások nélkül futtathatja, így a zárt modellekbe épített tiltások csak átmeneti védelmet adnak. A webes oldalon a WordPress 7.2 végleges kiadását december 8. és 10. közé tervezik, a WooCommerce pedig 2027 januárjától, a 11.5-ös verzióval hagyja el a PHP 7.4 és 8.0 támogatását, így az év végéig érdemes a tárhely PHP-verzióját is rendbe tenni.

A mi ítéletünk egyértelmű: nem a zero-day hibák miatt kell most aggódni, hanem azok miatt a régi, ismert hibák miatt, amelyeket az AI mostantól olcsón és gyorsan megtalál. Aki ősszel végigviszi a frissítést, a kétfaktoros belépést, a naplózást és egy alapszintű auditot, az a kis cégeket érő támadások döntő többségétől megvédi magát, így nyugodtabban figyelheti, hová fejlődnek tovább az AI-modellek.

Miben segít a Convergo?

A Convergónál abban segítünk, hogy a céged ne a következő automatizált támadás után kezdjen el a biztonsággal foglalkozni. Az IT audit és digitális tanácsadás keretében feltérképezzük a weboldalad, a webshopod és az ügyviteli rendszereid gyenge pontjait, majd forintosított, rangsorolt javítási tervet adunk. A support, üzemeltetés és tárhely szolgáltatásunkban (30 000 Ft/hó, havi 3 fejlesztői órával) rendszeresen elvégezzük a frissítéseket, ellenőrizzük a mentéseket és figyeljük a naplókat. Ha AI-eszközt vezetnél be, az AI-felmérés során azt is megnézzük, milyen jogosultsággal és milyen adatokkal dolgozzon biztonságosan. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük a 30 napos teendőlistát.