Tanács Zoltán, a tudományos és technológiai miniszter csütörtök reggel bejelentette, hogy elővigyázatosságból lekapcsolták a magyarorszag.hu-t és más kormányzati honlapokat egy több országot érintő, kritikus informatikai biztonsági kockázat miatt. A fenyegetést csütörtök délutánra sikerült elhárítani, az oldal újraindult.
A veszély pontos oka két, a PHP nevű, széles körben használt szerveroldali programozási nyelvben felfedezett sérülékenység volt. A hibák lehetővé tették, hogy hitelesítés nélkül, távolról kódot futtassanak egy PHP-alapú webszerveren, illetve érzékeny adatokat — például jelszavakat vagy API-kulcsokat — kiolvassanak a szerver memóriájából.
Mit érintett a hiba és miért volt különösen veszélyes?
A PHP-t sok népszerű webalkalmazás használja: a W3Techs adatai szerint a publikus információval rendelkező honlapok közel 70 százalékánál szerveroldali nyelvként alkalmazzák; ilyenek például a WordPress és a MediaWiki (amely a Wikipédia motorja). Emiatt egy PHP-szintű kritikus hiba széles körben okozhat problémát.
A most felfedezett két sérülékenységet a Calif és a Wiz nevű kiberbiztonsági cégek, valamint az OpenAI azonosította — részben fejlett mesterségesintelligencia-modellek segítségével, az OpenAI által támogatott Patch the Planet kezdeményezés keretében. A kutatók egy php2shell nevű demonstrációs szkriptet is összeállítottak, amely kombinálva a sebezhetőségeket bemutatta, hogy távolról, belépés nélkül lehet kódot futtatni a szerveren.
Ez különösen súlyos, mert a hagyományos támadási folyamatban általában valamilyen belépési pontot vagy ellopott fiókot kell szerezni; itt viszont az automatizált támadáselőkészítés elméletben lehetővé tette volna, hogy parancsszkriptek önmaguktól tömegesen próbálkozzanak a világhálón.
A felfedezés háttere és az MI szerepe
A Calif a problémát visszavezetve azt írta, hogy egy memóriakezeléssel kapcsolatos, részben korábban ismert hibára építve sikerült kihasználhatónak bizonyítani a rést; az OpenAI függetlenül ugyanarra a következtetésre jutott. A Wiz, a Calif és az OpenAI blogposztjai szerint a nagy nyelvi modellek és speciális belső modellek (például a Wiz Atlas modellje, a Gemini 4 Argon és a GPT-5.6 Soll említve) jelentősen felgyorsították a tesztelést és a kihasználhatóság igazolását.
A kutatók szerint a memóriakezelési hibák manuális bizonyítása sok esetben rendkívül időigényes és bonyolult; a fejlett MI-modellek azonban automatizált tesztelési lehetőséget adtak, így gyorsabban derült ki, hogy a hibák élesben is kihasználhatók.
Idővonal, nyilvánosság és a javítások megjelenése
A PHP Alapítvány már szeptember óta dolgozott a hibák javításán, és eredetileg október 22-re tervezték a nyilvános bejelentést. Október 20-án azonban különböző fórumokon elkezdtek terjedni információk a sebezhetőségről, ezért a PHP előrébb hozta az értesítést és a javítócsomag közzétételét.
Ugyanezen a napon a Calif közzétett, majd gyorsan eltávolított egy videót a php2shellről, ami felgyorsította az információ terjedését; a Chainguard nevű cég pedig órákkal az embargó lejárta előtt nyilvánosságra hozta a javítást, amit szintén sokan kritizáltak. Az Amazon szerint már október 17-én kísérlet történt a sérülékenységek kihasználására, majd 20-án is több aktív próbálkozást észleltek.
Javítások és teendők
A hibákra vonatkozó javítócsomagok megjelentek: a frissítések a PHP 8.2-re és az azt követő verziókra érhetők el. Fontos azonban, hogy a W3Techs szerint az ismert weboldalak körülbelül 31 százaléka még PHP 7-es vagy annál régebbi verziót futtat, így jelentős részük nem kapja meg közvetlenül ezeket a frissítéseket.
A PHP Alapítvány, valamint olyan szolgáltatók, mint az AWS és a Cloudflare, már közzétettek olyan intézkedéseket és átmeneti megoldásokat, amelyekkel csökkenteni lehet a kitettséget. A biztonsági szervezetek és állami ügynökségek egyértelmű felhívása: telepítsék a frissítéseket, vagy ha erre nincs mód, ideiglenesen vegyék le a szolgáltatást az internetről és tervezzék meg a verziófrissítést.
Miért fontos ez most?
A történet azt is megmutatja, hogy a felelős kommunikáció és a javítások ütemezése mennyire kritikus: ha a javítások és a részletes információk egyszerre kerülnek nyilvánosságra, kevesebb pánik és kevesebb szükségszerű leállás lenne. A mostani esetben a szivárgások és a korábbi nyilvánosság miatt több országban ideiglenesen leálltak oldalak — köztük állami felületek és nagyméretű nemzetközi szolgáltatások —, míg a javítások elterjedéséig a fenyegetés fennállt.
A rendszergazdáknak és üzemeltetőknek most az a legfontosabb teendőjük: ellenőrizzék PHP-verziójukat, telepítsék a PHP 8.2+ javításait, vagy ha erre nincs azonnali lehetőség, vegyék le az érintett szolgáltatásokat és alkalmazzák a PHP Alapítvány és a felhőszolgáltatók által javasolt átmeneti védekezéseket.
