PHP2Shell: ezért állt le a magyarorszag.hu – és mit jelent ez neked

Mi az a PHP2Shell?

A PHP egy programozási nyelv, amiben a weboldalak nagy része készül – a W3Techs mérése szerint azoknak az oldalaknak körülbelül 70 százaléka, amelyeknél tudható, milyen nyelv fut a kiszolgálón. Vagyis amikor a PHP-ben találnak súlyos hibát, az nem egy szűk réteg problémája, hanem az internet jelentős részéé.

Október 21-én a PHP fejlesztői két ilyen hibát javítottak. A kettő együtt kapta a PHP2Shell nevet, a hivatalos azonosítójuk CVE-2026-109618 és CVE-2026-109619, és mindkettő súlyossága 9,2 a tízes skálán, a PHP biztonsági csapatának saját besorolása szerint. (Terjedt egy 10,0-es érték is, de azt a PHP Foundation szerint nem ők adták.)

Hogy mitől ilyen súlyos? Attól, amit a támadó elérhet vele. Mindkét hiba távoli kódfuttatást tesz lehetővé: egy támadó bejelentkezés nélkül, egyetlen kéréssel futtathat saját kódot a kiszolgálón. Innen jön a név is – a shell parancssort jelent, vagyis azt, hogy a támadó parancsokat adhat ki a gépen. Onnantól nem egy weboldalt lehet elcsúfítani, hanem a kiszolgálón lévő adatokhoz is hozzá lehet férni.

Röviden a technikai lényeg: az egyik hiba akkor jelentkezik, amikor egy kérés feldolgozása közben elfogy a PHP memóriája, és a takarítás után a félig beállított adatokat érvényesnek hiszi a rendszer. A másik olyan belső állapotot hagy a kiszolgálón, amely már felszabadított memóriára mutat – és a következő kérés ezt még használhatja. Egyik sem a te weboldalad kódjának a hibája: a PHP motorjában vannak, tehát akkor is érintett vagy, ha a saját kódod hibátlan.

A hibák több mint egy évtizede ott voltak

Ami ebben a történetben a legérdekesebb: a hibás kódrészlet a jelek szerint a PHP 5.4-es verziójáig, vagyis bő egy évtizeddel korábbra vezethető vissza. A PHP Foundation szerint az egyik hiba nyomát egy fejlesztő már a PHP 2024-es külső biztonsági auditja során észrevette – kihasználható támadássá formálni viszont akkor nem sikerült.

Most sikerült, és ebben a mesterséges intelligenciának is szerepe volt. A hibákat a Wiz Research, a Calif és az OpenAI biztonsági csapata jelentette, a javításon pedig a PHP biztonsági csapata a Google Gemini-csapatával együtt dolgozott. A Wiz leírása szerint a támadás összerakása olyan összetett lépéssort kívánt, amely az emberi kutatók gyakorlati teljesítőképességének határán volt, és éppen ezt a korlátot vitték le érezhetően a legfejlettebb AI-modellek. A Calif ugyanakkor hozzátette: a mai modellek önmagukban, egy homályos, két évtizedes alapelemből kiindulva nem jutnának el idáig – vagyis emberi kutatásra továbbra is szükség volt.

Ettől függetlenül érdemes elgondolkodni rajta: olyan hibák kezdenek most előkerülni, amelyek évekig azért maradtak rejtve, mert túl bonyolult volt kiaknázni őket.

Miért állt le a magyarorszag.hu?

Magyarországon a Nemzeti Kiberbiztonsági Intézet október 21-én kritikus, 9,2-es súlyossági besorolású riasztást adott ki a hibáról, és azonnali javítást javasolt. Ahol a javítás nem oldható meg rögtön, ott azt tanácsolta, hogy az érintett szolgáltatásokat ideiglenesen korlátozzák.

A kormányzat pontosan ezt tette. Szerda éjjel elővigyázatosságból leállították a magyarorszag.hu portált és néhány további kormányzati weboldalt. A bejelentést Tanács Zoltán tudományos és technológiai miniszter tette közzé csütörtök reggel, és akkor azt mondta, hogy a portálon keresztüli ügyintézés várhatóan 48 órán át szünetel, a biztonsági hiba kijavításáig.

Végül nem tartott addig: a portál ugyanazon a napon, csütörtök 15:15-kor újraindult. A miniszter szerint a szükséges biztonsági intézkedések megtörténtek, és támadásra utaló jelet nem találtak – vagyis a leállás megelőzés volt, nem egy incidens következménye. Arról sem szólt közlemény, hogy bármilyen adat kiszivárgott volna.

Érdemes ezt a döntést a helyén látni, mert elsőre riasztóan hangzik, hogy egy ország leállítja a központi ügyintézési portálját. A nemzetközi gyakorlat viszont éppen ez: a brit nemzeti kiberbiztonsági központ is azt javasolta, hogy a szervezetek vegyék fontolóra az olyan rendszerek lekapcsolását, amelyeket nem tudnak azonnal megjavítani, a CISA pedig kifejezetten azt írta, hogy a PHP-alapú rendszereket vigyék offline állapotba, amíg nem tudják frissíteni őket. A CERT-EU azt tanácsolta, hogy vegyék fontolóra az internet felé nyitott alkalmazások elszigetelését, amíg a javítás el nem készül és nem ellenőrzik.

A hazai közlemény egyetlen konkrét kérést tartalmazott, és nem az állampolgároknak szólt: a cégeket arra kérte, hogy informatikusaikkal ellenőriztessék, érintett-e a saját weboldaluk, és a hibát minél előbb javítsák.

Hol állt le még a világban?

A legjobban dokumentált eset Hollandia: ott október 21-én megelőzésből lekapcsolták a DigiD azonosítási rendszert, a MijnOverheid ügyintézési portált, a parlament alsóházának oldalát, a nemzeti kiberbiztonsági központ és az adatvédelmi hatóság weboldalát, valamint több oktatási rendszert. A holland kiberbiztonsági központ szerint ők sem láttak a hiba kihasználására utaló jelet; a DigiD üzemeltetője, a Logius pedig azt közölte, hogy a DigiD-es belépés más szervezeteknél közben működött.

A magánszektorból a BambooHR HR- és bérszámfejtési szolgáltatás a legláthatóbb eset: amerikai, kanadai és írországi kiszolgálóit körülbelül hat órára lekapcsolta, és jelezte, hogy a bérszámfejtés megszakad. Japánban két tartalomkezelő-rendszer gyártója reagált: a Six Apart vészhelyzeti PHP-frissítést ütemezett a Movable Type felhős környezeteiben – a szoftvert saját gépen futtatóknak maguknak kell frissíteniük –, az Alfasado pedig azt javasolta, hogy aki nem tudja frissíteni a PHP-t, függessze fel az érintett oldalakat; a PowerCMS felhős szolgáltatását október 22-én indította újra.

A magyar bejelentés emellett arról is beszámolt, hogy állami és közszolgáltatások szüneteltek Finnországban, Dániában és Franciaországban, valamint hogy a Wikipédia és a BBC egyes szolgáltatásai is elérhetetlenné váltak. Ezekre a független nemzetközi forrásokban nem találtunk megerősítést, ezért itt csak a miniszteri bejelentés állításaként jelezzük őket.

Egy dolog viszont közös: az eddig ismert leállások mind megelőzésből történtek, és megerősített betörésről egyetlen érintettnél sem számoltak be.

Érint-e téged felhasználóként?

Kezdjük a jó hírrel: a saját gépeden, telefonodon nincs mit tenned. Ez nem olyan hiba, mint egy böngészőben vagy a Windowsban lévő sérülékenység – nem a te eszközödön fut a hibás program, hanem azokon a kiszolgálókon, amelyek a weboldalakat szolgáltatják. Nincs letölthető frissítés, és nincs olyan beállítás, amelyet át kellene kapcsolnod.

Két dologban mégis érint téged.

Az egyik a kiesés. Ha csütörtökön ügyet akartál intézni a magyarorszag.hu-n, nem tudtál – és ha egy olyan szolgáltatást használsz, amely még nem végzett a javítással, előfordulhat újabb rövid szünet. Ez kellemetlen, de nem veszélyes.

A másik, ami fontosabb: azoknak az oldalaknak egy része, ahol fiókod van, nem fogja időben kijavítani a hibát. A nagy szolgáltatók órák alatt frissítenek, egy évek óta nem gondozott kisebb webshop vagy fórum viszont hónapokig sérülékeny maradhat. Ha egy ilyen oldalt betörnek, a nálad lévő jelszó és e-mail-cím is veszélybe kerül.

Ebből egy nagyon gyakorlati tanács következik, és ez nem új, csak most különösen aktuális: ne használd ugyanazt a jelszót két helyen. Ha minden oldalhoz külön jelszó tartozik, akkor egy ilyen betörés egyetlen fiókot érint, nem az egész digitális életedet. Ha ezt eddig nem oldottad meg, a jelszókezelőkről szóló összehasonlításunk végigvezet rajta.

És ha pont most jön egy levél arról, hogy valamelyik szolgáltatónál adatszivárgás volt: a Kifli.hu esete jó emlékeztető arra, mit tudsz lecserélni egy ilyen után, és mit nem.

Adathalászat a leállás árnyékában – erre számíts

Ez a rész az, amiért érdemes volt ezt a cikket megírni. A csalók minden nagy, nyilvános leállást kihasználnak, mert a kiesés hitelessé teszi a hamis levelet. A sémája mindig ugyanaz: „a rendszerhiba miatt megszakadt az ügyintézése, kérjük, azonosítsa magát újra.”

Amire a következő hetekben számíts:

• Hamis levél vagy SMS a magyarorszag.hu nevében. Arról, hogy a leállás miatt újra be kell jelentkezned, meg kell erősítened az adataidat, vagy elveszett a beadványod. Ezekben a linkek egy megtévesztő, de nem állami oldalra visznek.

• Hamis banki értesítés. „A kiberbiztonsági incidens érintette a kártyáját” – és már kéri is a kártyaadatokat. A bankod soha nem kér telefonon vagy levélben kártyaszámot, PIN-t vagy jóváhagyó kódot.

• Telefonos hívás „a kiberbiztonsági hatóság” nevében. Ez a legkellemetlenebb változat, mert a hír valódi, és így a hívás is hitelesnek hangzik. A hatóság nem hív fel azzal, hogy utalj át pénzt vagy telepíts távsegítő programot.

A védekezés egyszerű, és egyetlen szabályra épül: az állami ügyintézést soha ne levélből érkező linken kezdd el. Írd be magad a címet, vagy indulj a telefonodon lévő alkalmazásból – a Digitális Állampolgárság (DÁP) appból, az e-Szignóból vagy a NAV Mobilból. Ha nem vagy biztos benne, melyikre mi való, azt külön cikkben szedtük szét.

A csalók módszereiről egyébként két korábbi írásunk is részletesen szól: az egyik azt mutatja meg, hogyan veszik rá a magyar ügyfeleket, hogy maguk utalják el a pénzüket, a másik pedig azt, hogyan mutat a böngésző valódi linket, miközben máshova visz.

Van saját oldalad vagy webshopod? – ellenőrzőlista

Innentől azoknak szól, akik üzemeltetnek valamit: céges oldalt, webshopot, WordPress-blogot, otthoni kiszolgálót. Ha ez te vagy, ez a rész nem elhalasztható, mert a hibát már kihasználják. Az Amazon biztonsági csapata a saját csapdahálózatán október 17-én, négy nappal a nyilvánosságra kerülés előtt észlelt egy próbálkozást, október 21-től pedig több kísérletet is dokumentált – a használt eszközök szerintük több, egymástól független támadóra utalnak. Az Amazon megfogalmazása szerint a hibát mostanra széles körben kihasználják. Megerősített betörésről egyelőre nincs nyilvános hír, de ez nem ok a várakozásra.

1. Nézd meg, melyik PHP-verzió fut

A javítás négy sorozathoz jelent meg, és mindegyikhez más verziószámmal. A sajátodat ahhoz hasonlítsd, amelyik nálad fut: a 8.5-es sorozatban a 8.5.12, a 8.4-esben a 8.4.27, a 8.3-asban a 8.3.36, a 8.2-esben a 8.2.35 az első javított kiadás. Ha a tiéd ennél kisebb a saját sorozatán belül, érintett vagy.

A verziót a tárhelyszolgáltató vezérlőpultján nézheted meg a legegyszerűbben. Kiszolgálón a php -v parancs kézenfekvő, de az csak a parancssori PHP verzióját mutatja, ami gyakran más, mint amelyik a weboldalt szolgálja ki. A weben futó verzióhoz a php-fpm -v parancs vagy egy phpinfo() oldal ad pontos választ.

2. Frissíts – vagy kérd meg a szolgáltatót

Ha bérelt tárhelyen vagy, a frissítés nagyrészt a szolgáltató dolga; érdemes rákérdezni, megvan-e. Ha saját kiszolgálót üzemeltetsz, a Linux-disztribúciók és a hosszú támogatású csomagokat kiadó szállítók előre megkapták a javítást, tehát a saját csomagkezelőd frissítése a legegyszerűbb út.

3. Ha PHP 8.1-es vagy régebbi fut nálad, az külön eset

A PHP projekt a 8.1-es és régebbi sorozatokhoz nem adott ki rendes frissítést, csak minimális forráskódos javítást a 7.4-es, 8.0-as és 8.1-es változatokhoz. Az 5.4-től 7.3-ig tartó verziók a PHP projekttől már semmilyen javítást nem kapnak – a disztribúciók és az LTS-szállítók viszont adhatnak visszaportolt javítást, ezért érdemes a sajátodnál rákérdezni.

A CISA ajánlása ebben az esetben világos: aki nem tud azonnal frissíteni, vagy 8.1-es vagy régebbi PHP-t futtat, vigye offline állapotba a rendszert, amíg a javítás meg nem történik.

Egy dátum, amit érdemes most beírni a naptárba: a PHP 8.2 támogatása 2026. december 31-én lejár. Ha most a 8.2.35-re frissítesz, az jó döntés, de két hónap múlva már a 8.3-as vagy újabb sorozat felé kell lépned.

4. Ha most nem tudsz frissíteni, ennyivel csökkentheted a kitettséget

Előre: ezek nem megoldások. A PHP egyértelműen fogalmaz – teljes javítást csak a frissítés ad, a következő beállítások egyes támadási utakat zárnak le, de nem teszik biztonságossá a telepítést. Három ilyen beállítás van.

• Az első hibánál a memory_limit=-1 értéket kell beállítani úgy, hogy az alkalmazás ne tudja felülírni. Ezt csak akkor tedd meg, ha a folyamat memóriáját konténer- vagy cgroup-szinten korlátozod, különben a PHP memóriakorlát nélkül marad, és egy terheléses hiba leállíthatja a kiszolgálót. A PHP maga is ezt a konténeres korlátot ajánlja mellé – rendelkezésre állási határként, nem védelemként.

• A másik hibánál a session.upload_progress.enabled=0 beállítás kell.

• A 8.5-es sorozatban emellé a fatal_error_backtraces=0 is.

Mindhárom után újra kell indítani az összes PHP-folyamatot, különben nem lépnek érvénybe.

5. Ami különösen veszélyes

A PHP minden olyan telepítése érintett, amely webes kéréseket szolgál ki – a PHP-FPM, az Apache mod_php, a php-cgi, a FrankenPHP és a LiteSpeed is. A PHP saját értékelése szerint a mod_php a legkockázatosabb üzemmód. A Calif szerint emellett sikerült a WordPress, a Drupal, a Joomla és a Magento bizonyos verzióival bejelentkezés nélkül kódot futtatni – vagyis a legelterjedtebb tartalomkezelők is célpontok.

6. És ha tűzfal mögött vagy?

A Cloudflare minden előfizetési csomagjához – az ingyeneshez is – kiadott szűrőszabályokat az ismert támadási mintákra, de saját megfogalmazása szerint ez csak áthidaló megoldás, és csak a rajta átmenő forgalomra érvényes. A támadók ráadásul már változtatták a kérések tartalmát, hogy kicselezzék ezeket a szabályokat. A tűzfal tehát nyer egy kis időt, nem helyettesíti a frissítést.

Mit tanulhatunk belőle?

Három dolgot, és egyik sem technikai.

Az első: a gyors lekapcsolás nem pánik, hanem szakmai döntés. Könnyű kritizálni egy állami portál leállítását, pedig a brit és az amerikai hatóság is pontosan ezt ajánlotta azoknak, akik nem tudnak azonnal javítani. Jobb bő fél napra szüneteltetni az ügyintézést, mint utólag adatszivárgást bejelenteni. Magyarországon a bejelentett 48 óra helyett a portál lényegesen hamarabb visszatért, ami inkább jó, mint rossz jel.

A második: a „nekem nincs mit frissítenem” érzés félrevezető. Ebben az esetben tényleg nincs – de azért, mert a hiba olyan rendszerekben van, amelyekre nincs ráhatásod. Az adataid védelme itt azon múlt, hogy mások mennyire voltak gyorsak. Ez nem kellemes, viszont pontosan ezért érdemes megtenni azt a kevés dolgot, ami rajtad áll: külön jelszó minden oldalhoz, kétlépcsős azonosítás, és fenntartás minden olyan levéllel szemben, amely azonnali intézkedést kér.

A harmadik, ami a leginkább elgondolkodtató: megváltozott az a tempó, ahogy a régi hibák előkerülnek. Ez a két hiba több mint egy évtizedig ott volt a PHP-ben, és nem azért maradt észrevétlen, mert senki nem nézte – 2024-ben egy audit során fel is tűnt az egyik nyoma. Az addig hiányzó lépést, a kihasználható támadás összerakását most AI-modellek segítették, még ha emberi kutatás nélkül ez sem ment volna. Ebből következik, hogy a következő években valószínűleg több ilyen, régóta meglévő hiba kerül majd elő, hirtelen és csoportosan.

A gyakorlati következtetés ugyanaz, mint minden ilyen hírnél: frissíts, amint lehet – és ha valamit üzemeltetsz, ne a következő hírből tudd meg, hogy érintett vagy. A rendszeres frissítésről a legutóbbi Microsoft-javítócsomagnál is írtunk, és a böngésződ automatikus frissítésénél is van egy csavar, amiről érdemes tudni.