Leállt a magyarország.hu egy PHP-hiba miatt: mit kell ma ellenőrizned a saját weboldaladon

Állapot: 2026. október 23. délelőtt. A cikk a PHP és a Node.js hivatalos közleményein, a Nemzeti Kibervédelmi Intézet (NKI) riasztásán, a brit NCSC, az AWS, a Wiz, a Cloudflare, a Sansec és az Aikido elemzésein, valamint a Help Net Security és a 444 (MTI) cikkein alapul. A helyzet óráról órára változik.

Október 21-ről 22-re virradó éjjel elérhetetlenné vált a magyarország.hu. Nem támadták meg: a kormány elővigyázatosságból kapcsolta le, mert a portál mögött futó PHP-ról kiderült, hogy egy kritikus hibával bárki átveheti az irányítást a szerver felett. A 444 (MTI) szerint Hollandiában a rotterdami kikötő és több kórház honlapja ment le ugyanezért, Finnországban, Dániában és Franciaországban kormányzati szolgáltatások álltak le.

A Cloudflare szerint a PHP-t a weboldalak közel 70 százaléka használja, köztük szinte minden WordPress-oldal és webáruház. Ha a cégednek van weboldala, nagy eséllyel téged is érint. Ebben a cikkben végigvesszük, mi történt október 17. és 23. között, mi a PHP2Shell, a Node2Shell és a LiteLLM-támadás lényege, és lépésről lépésre megmutatjuk, mit kell ellenőrizned.

Mi történt a PHP-val október 17. és 23. között?

A hibákat nyáron több csapat egymástól függetlenül találta meg: a Calif, a Wiz Research és az OpenAI. A Wiz augusztus 24-én jelentette a PHP biztonsági csapatának, és a javítás összehangolt, titoktartási időszak végén megjelenő kiadásra készült. A terv nem jött be: október 20-án a részletek kiszivárogtak, a PHP csapata ezért az eredeti időpontnál egy nappal korábbra hozta a kiadást.

A legfontosabb időpontok, a forrásokban megadott időzónával:

Az Amazon a saját elemzésében azt írja, hogy a kiadás előtti órákban több támadó is próbálkozott, a kiadás után pedig szinte azonnal megjelentek az újabb kihasználó kódok. Hogy a támadó honnan tudott a hibáról már október 17-én, az máig nem ismert.

Miért ilyen súlyos a PHP2Shell?

A legtöbb webes biztonsági rés egy konkrét bővítményben vagy alkalmazásban van. A PHP2Shell nem ilyen. A PHP hivatalos közleménye szerint minden webes kérést kiszolgáló PHP-telepítés érintett, és a támadás az Apache mod_php moduljánál a legveszélyesebb. A Wiz kutatói szerint egy egyszerű „Hello World” alkalmazás is sérülékeny lehet, ha a PHP-verzió érintett.

Mindkét hiba abból ered, ahogyan a PHP egy kérés közben fellépő végzetes hibát, jellemzően a memória elfogyását kezeli:

• CVE-2026-109618: ha a PHP-nak elfogy a memóriája, miközben a kérés adatait még csak félig állította be, a takarítás a félkész adatot érvényesnek kezeli. Ebből kódfuttatás lehet. A Wiz azt is kimutatta, hogy ugyanezzel a szerver memóriájából jelszavak, tokenek és API-kulcsok olvashatók ki, egy PHPSESSID sütiben visszaküldve, akkor is, ha az oldal nem használ munkamenetet.
• CVE-2026-109619: a kérés egy belső állapota túléli a memória felszabadítását, és ugyanannak a PHP-folyamatnak a következő kérése már a felszabadított, támadó által kitöltött memóriát használja (use-after-free).

A Wiz bemutatta, hogy a kódfuttatás bejelentkezés nélkül működik a WordPress, a Drupal és a Joomla legfrissebb konténerképein. A Sansec szerint a WooCommerce-, Shopware- és Magento-áruházak is érintettek, mert a hiba a motorban van, nem az áruház kódjában.

„These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history. The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”

Magyarul: „Ezek a PHP-ban valaha talált legsúlyosabb sérülékenységek közé tartoznak, és talán az egész szoftvertörténet legsúlyosabbjai közé is. A hibák évtizedek óta jelen voltak, de a kihasználhatóságuk bizonyítása rendkívül bonyolult lépéssort igényelt, az emberi kutatók gyakorlati lehetőségeinek határán. A fejlett MI-modellek ezt az akadályt jelentősen lejjebb vitték, és egy régóta meglévő hibából működő exploit lett.”

Kevin Beaumont biztonsági kutató a Help Net Security által idézett bejegyzésében így fogalmazott: „The PHP situation will lead to a mass of incidents – it’s one of the biggest vulns in years” (magyarul: „A PHP-helyzet incidensek tömegéhez vezet, ez az évek egyik legnagyobb sérülékenysége”).

Mennyire könnyű kihasználni a gyakorlatban?

Ebben a kutatók nem értenek egyet, és ezt érdemes őszintén leírni. A Wiz és a Datadog is reprodukálta a támadást, a Datadog egyetlen hitelesítés nélküli POST-kéréssel. A Sansec október 22-i frissítése óvatosabb: a nyilvános bizonyító kódok (PoC) alapbeállítású PHP ellen nem működnek, a legtöbbhöz az alkalmazásban is kell egy másik hiba, és szerintük egy webáruházat nem kell lekapcsolni. A Help Net Security által idézett VulnCheck szerint a hibák ARM64-en és címtér-véletlenítés (ASLR) nélküli x86-on használhatók kódfuttatásra.

A gyakorlati tanulság egyszerű: ne arra építs, hogy a te szervered konfigurációja véletlenül nehezíti a támadást. A javítás percek kérdése, a feltört szerver helyreállítása napoké.

Hogyan érintette Magyarországot?

A Nemzeti Kibervédelmi Intézet október 21-én riasztást adott ki a PHP-hibákról, a hibák súlyossága, várható kihasználása és a PHP széles elterjedtsége miatt. Az intézet a javítások azonnali telepítését sürgette, és azt javasolta, hogy ahol ez nem lehetséges, ott az érintett rendszereket ideiglenesen válasszák le az internetről.

A 444 (MTI) szerint Tanács Zoltán technológiai miniszter azt közölte, hogy támadásra utaló jelet nem találtak, de a portál leállt:

„Elővigyázatosságból az éjszaka során átmenetileg leállítottuk a magyarország.hu oldalt és néhány további kormányzati weboldal elérését.” A sérülékenység javításáig „a portálon keresztüli ügyintézés várhatóan 48 órán át szünetel.”

A miniszter a 444 szerint arra kért minden vállalkozást, hogy informatikai vagy információbiztonsági szakértőjével ellenőriztesse, érintett-e a weboldala. Ez a kérés a magyar KKV-knak szól, és ebben a cikkben ehhez adunk gyakorlati segítséget.

Az NKI egy külön cikkében a The Record alapján azt írja, hogy a VirusTotal elemzése szerint körülbelül 5,1 millió internetről elérhető IP-címen fut PHP, és ebből legalább 758 ezer már nem támogatott verzió. Ez nem a bizonyítottan sérülékeny rendszerek száma, de jól mutatja, mekkora a régi, frissítetlen PHP-k aránya.

Mi a Node2Shell, és kell-e Node.js biztonsági frissítést telepítened?

A Node2Shell a Node.js Brotli-dekóderének hibája (CVE-2026-111497). A Node.js 2026. október 21-én biztonsági kiadást adott ki rá mindhárom támogatott ágon. A kiadás összesen tíz hibát javított: négy magas (high), három közepes és három alacsony súlyosságút. A Node2Shell nevet a sajtó adta a Brotli-hibának. Egy kártékony tömörített bemenet a puffer végén túlra írhat, ami kódfuttatáshoz vezethet. A hibát az OpenAI Codex Security csapata jelentette.

Fontos különbség a PHP2Shell-hez képest: a Node.js ezt a hibát „high”, nem „critical” besorolással adta ki. Az Aikido október 22-i összefoglalója szerint a nyilvános bizonyító kód csak egy szándékosan gyengített buildet tört fel, és a The Hacker News addig nem tudott éles kihasználásról. Az Aikido szerint a hiba elérhető, ha az alkalmazás Brotli-tömörítésű kéréstörzset csomagol ki (például Express 5 a body-parser 2.x-szel), ha a fetch() Brotli-választ kap, vagy ha a kód közvetlenül a node:zlib modult használja.

Az Aikido arra is figyelmeztet, hogy a rögzített verziójú Docker-képek (például egy node:22.23.3-alpine) addig sérülékenyek, amíg újra nem építed őket. A hiba a Node.js saját Brotli-példányában van, ezért egy npm-csomag frissítése nem segít, csak a futtatókörnyezeté.

Mi történt a LiteLLM-mel, és miért fontos, ha AI-eszközöket használsz?

A LiteLLM egy népszerű Python-könyvtár, amely egységes felületet ad a különböző nyelvi modellek API-jaihoz. 2026. október 21-én ellátásilánc-támadás érte, ezért mindenkit érint, aki AI-alkalmazást fejleszt vagy üzemeltet. A Help Net Security szerint ez már a második ellátásilánc-támadás ellene idén.

A támadók október 21-én feltörték a LiteLLM kiadási folyamatát, és kiadták a kártékony v1.107.0 verziót. A csomag a PyPI-on 11:39 és 13:23 UTC között, a Docker-képek 11:46 és 14:20 UTC között voltak elérhetők. A kártevő felhő-, Git-, SSH-, böngésző- és AI-eszköz-hitelesítőket keresett (Codex, Claude, Gemini, Cursor), és akkor is lefutott, ha az alkalmazás nem töltötte be a LiteLLM-et. A Socket adatai szerint a könyvtárat hetente körülbelül 23 millióan töltik le.

Teendő: ha bármelyik rendszeredben a LiteLLM 1.107.0 futott, térj vissza a v1.106.2-re, és cserélj le minden hitelesítő adatot, amely azon a gépen elérhető volt. Erről bővebben az AI-ügynökök biztonsági kockázatairól szóló cikkünkben írtunk.

PHP-frissítés és WordPress-biztonság: mit tegyen egy magyar KKV 24 órán belül?

A teendő attól függ, hogyan fut a weboldalad. Az alábbi táblázatot a hivatalos közlemények alapján állítottuk össze, a magyar KKV-knál leggyakoribb üzemeltetési formákra:

Saját példánk: a socialpro.hu statikus HTML-oldal, amelyet buildeléskor generálunk, és a látogatói kéréseket nem PHP szolgálja ki. Ezért a PHP2Shell minket közvetlenül nem érintett. Ügyfeleinknél viszont az első kérdés mindig ugyanaz: van-e valahol egy elfeledett WordPress-aloldal, régi landing oldal vagy PHP-s űrlapkezelő. A sérülékeny rendszer ritkán a főoldal, sokkal gyakrabban az, amiről már senki sem tud. Ha a te oldaladat is PHP-futtatás nélküli, statikus megoldásra váltanád, a weboldal-készítési szolgáltatásunknál megnézheted, hogyan dolgozunk.

Hogyan nézd meg, melyik PHP-verzión fut az oldalad?

1. WordPressben: Eszközök → Webhely egészsége → Információ fül → Szerver szakasz → PHP-verzió.
2. Tárhely-vezérlőpulton: keresd a „PHP-verzió” vagy „PHP Selector” menüt.
3. Szerveren: a php -v parancs a parancssori PHP-t mutatja. Az OVHcloud figyelmeztetése szerint ez eltérhet attól, amelyiket a weboldalad használja, ha több PHP-verzió van telepítve. A webszerver által használt verziót egy ideiglenes phpinfo() oldal mutatja meg, amelyet ellenőrzés után azonnal törölj.

Ha a verzió 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy ennél újabb, a PHP2Shell ellen védett vagy. Ha ennél régebbi, frissíteni kell.

Mit tehetsz, ha ma nem tudsz frissíteni?

A PHP közleménye néhány átmeneti beállítást ad, de hangsúlyozza, hogy ezek csak részleges védelmet nyújtanak, a frissítést nem helyettesítik. Az AWS szerint nincs olyan beállítás, amely mindkét hibát teljesen kivédené. A php.net által javasolt lépések:

• session.upload_progress.enabled=0 a php.ini-ben vagy az FPM-poolban, majd minden worker újraindítása (az ini_set() és a .user.ini ehhez nem elég);
• a post_max_size csökkentése: fájlfeltöltés nélküli oldalon 8M, feltöltéssel 32M, és az upload_max_filesize maradjon ez alatt;
• memory_limit=-1, lehetőleg php_admin_value-val, hogy az alkalmazás ne írhassa felül (az OVHcloud szerint óvatosan, mert egyetlen kérés is elfogyaszthatja a szerver memóriáját);
• PHP 8.5-ön a fatal_error_backtraces=0 beállítás és a workerek újraindítása.

A Cloudflare szerint a mögötte futó oldalakat október 21-én 03:02 UTC óta alapból védik a php2shell elleni WAF-szabályok, az ingyenes csomagban is. A Cloudflare ugyanakkor maga írja, hogy a PHP-t ettől függetlenül frissíteni kell. A brit NCSC azt javasolja, hogy amit nem lehet frissíteni vagy enyhíteni, azt fontold meg lekapcsolni.

Honnan tudod, hogy megtámadtak-e?

Az NKI riasztása és a Wiz elemzése alapján ezekre figyelj a szerver naplóiban:

• ismétlődő HTTP 500-as válaszok üres tartalommal, szokatlan multipart kérések után;
• SIGSEGV vagy SIGABRT hibák a PHP-FPM naplójában, megmagyarázhatatlan worker-újraindulások;
• szokatlanul nagy vagy torz PHPSESSID sütik a válaszokban;
• PHP-folyamat, amely parancsértelmezőt (shell) vagy letöltőprogramot indít;
• a Mozilla/5.0 (php2shell-poc) vagy php2shell-verify/1.0 User-Agent a hozzáférési naplóban.

Ha bármelyiket látod, a frissítés után cserélj le minden jelszót, API-kulcsot és tokent, amely a szerveren elérhető volt, mert a memóriaszivárgás miatt ezek kikerülhettek.

Miért most jött el minden egyszerre? Az MI szerepe

A hét három incidensében van egy közös szál: a mesterséges intelligencia. A Wiz azt írja, hogy a PHP-hibákat a Wiz Atlas, a Gemini 4 Argon és a GPT-5.6 Sol modellekkel találta meg és fejlesztette ki rájuk az exploitot, és hogy egyetlen kutató egy hét alatt végzett azzal, ami korábban egy világszínvonalú csapatnak hónapokig tartott volna. A Node.js Brotli-hibáját az OpenAI Codex Security jelentette.

„AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit.”

Magyarul: „Az MI-támogatott elemzés olcsóbbá teszi, hogy egy javítás kódkülönbségéből vagy egy biztonsági közleményből működő exploit legyen.”

Ez a magyar KKV-knak két dolgot jelent. Az első: a javítás megjelenése és a tömeges támadás között már nem hetek telnek el, hanem órák. A „majd a hónap végén frissítünk” gyakorlat ma már nem tartható. A második: a régóta meglévő, „túl bonyolult ahhoz, hogy bárki kihasználja” hibák is valós célponttá válnak. Erről a trendről, és arról, hogyan készülhet fel rá egy kisvállalkozás, hétlépéses útmutatónkban írtunk részletesen.

PHP2Shell, Log4Shell, Heartbleed: miben hasonlítanak?

A Wiz a PHP2Shellt két korábbi, fordulópontot jelentő sérülékenységhez hasonlította. A táblázat első sora a Wiz megfogalmazását követi, a KKV-teendők sora a saját összefoglalásunk:

Hal Pomeranz számítástechnikai igazságügyi szakértő a Help Net Security által idézett bejegyzésében arra figyelmeztetett, hogy rengeteg beágyazott telepítést soha nem fognak frissíteni, és túl sok az elfeledett, karbantartatlan alkalmazás, ezért ennek a hibának hosszú lecsengése lesz („There will be a long tail for this one”). A Log4Shellnél is ez történt: évekkel később is találtak frissítetlen rendszereket.

Gyakori kérdések

Érinti a PHP2Shell a WordPress-oldalamat?

Nagy valószínűséggel igen, ha a szervered PHP-verziója régebbi a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verziónál. A hiba a PHP motorjában van, nem a WordPressben, ezért a WordPress és a bővítmények frissítése nem elég. A PHP-t a tárhelyszolgáltatónak vagy a szerver üzemeltetőjének kell frissítenie.

Elég, ha frissítem a WordPresst és a bővítményeket?

Nem. A PHP2Shell a PHP futtatókörnyezetében van, nem az alkalmazás kódjában, ezért a weboldal kódjának vagy a bővítményeknek a frissítése önmagában nem javítja. A Cloudflare is azt írja, hogy a PHP-t a WAF-védelem mellett is frissíteni kell, a 444 (MTI) cikke szerint pedig a szakértők figyelmeztettek: a WordPress-oldalak szokásos frissítése nem elegendő.

Mi a teendő, ha a tárhelyszolgáltató üzemelteti a PHP-t?

Kérdezd meg tőle írásban, hogy telepítette-e a 2026. október 21-i PHP-biztonsági javítást, és melyik verzión fut az oldalad. A vezérlőpulton nézd meg, melyik PHP-ágat választottad: ha 8.1-es vagy régebbi, kérd a váltást egy támogatott ágra.

Érinti a Node2Shell az alkalmazásomat?

Akkor érintheti, ha Node.js 22, 24 vagy 26 korábbi verzióját futtatod, és az alkalmazásod Brotli-tömörített adatot csomagol ki (például Express 5-tel, a fetch() Brotli-válaszaival vagy a node:zlib modullal). A javított verziók: 22.23.4, 24.22.1 és 26.12.1. A Docker-képeket újra kell építeni.

Mit tegyek, ha a LiteLLM 1.107.0 verzióját telepítettem?

Térj vissza a v1.106.2-es verzióra, és cserélj le minden hitelesítő adatot (felhő-, Git-, SSH- és AI-szolgáltatói kulcsokat), amely azon a gépen elérhető volt. A kártékony verzió 2026. október 21-én néhány óráig volt elérhető a PyPI-on és a Docker-regiszterben.

Források állapota: a PHP és a Node.js hivatalos közleményei, az NKI riasztása és háttércikke, a brit NCSC, az AWS, a Wiz, a Cloudflare, a Sansec és az Aikido elemzései, a Help Net Security és a 444 (MTI) cikkei, 2026. október 23-i állapot szerint. A cikk tájékoztató jellegű, nem helyettesíti a saját rendszereid szakértői átvizsgálását.