Kritikus PHP- és Node.js-hiba 2026 októberében: érintett-e a weboldalad, és mit tegyél?

2026. október 21-én a PHP két kritikus biztonsági hibára adott ki javítást, és ugyanazon a napon a Node.js is kiadta a saját javító csomagját. Ha az elmúlt napokban figyelmeztető levelet kaptál a tárhelyszolgáltatódtól, valószínűleg erről szólt.

A jó hír, hogy a megoldás frissítés, és a munka nagy része nem a tiéd, hanem a szolgáltatóé vagy a fejlesztődé. A te dolgod annyi, hogy megkérdezd, megtörtént-e, és tudd, mit kérdezz.

A rövid válasz

Hiba	Kit érint	Javított verzió	Kinek a dolga
PHP2Shell (CVE-2026-109618, CVE-2026-109619)	minden PHP-n futó weboldalt: WordPress, Joomla, Drupal, Laravel, webshopok	8.5.12, 8.4.27, 8.3.36, 8.2.35	osztott tárhelyen a szolgáltatóé, saját szerveren az üzemeltetőé
CVE-2026-115560 (PHP)	szűk kör, csak bizonyos beállítás mellett	még nincs, addig egy beállítás kikapcsolása	a szolgáltatóé vagy az üzemeltetőé
Node.js Brotli-hiba (CVE-2026-111497)	Node.js-en futó webalkalmazásokat, a legtöbb kisvállalkozói weboldalt nem	22.23.4, 24.22.1, 26.12.1	a fejlesztőé

Mi történt a PHP-val?

A PHP az a programnyelv, amin a WordPress és a magyar weboldalak nagy része fut. A hiba magában a PHP-ben van, nem a WordPressben vagy egy pluginban, ezért a bővítmények frissítése most nem segít. Az számít, hogy a szerveren melyik PHP-verzió fut.

A két hibát PHP2Shell néven emlegetik, és mindkettő a legmagasabb, kritikus kategóriába került. Egy támadó bejelentkezés nélkül, egy speciálisan összerakott kéréssel saját kódot futtathat a szerveren. A második hibával a szerver memóriájából is kiolvashat adatokat, például jelszavakat és hozzáférési kulcsokat, akkor is, ha kódot nem tud futtatni.

Javítást a 8.5.12, a 8.4.27, a 8.3.36 és a 8.2.35 kapott. A PHP 8.1-hez és a régebbiekhez hivatalos javítás nem jön, mert ezek támogatása már lejárt. Néhány szolgáltató saját, javított csomagot ad a régi verziókhoz is, de erre csak akkor számíts, ha a szolgáltatód ezt írásban megerősíti.

A régi PHP-t is érinti?

A PHP csapata hivatalosan csak a még támogatott 8.2-8.5 verziókat vizsgálta, a régieket nem. Arra viszont a 7.4-hez, a 8.0-hoz és a 8.1-hez is készítettek egy minimális javítást forráskódként, saját fordításhoz, ami arra utal, hogy ezek is érintettek. A hibát felfedező kutatók szerint az érintett verziók egészen a PHP 5.4-ig visszanyúlnak, ezt a PHP nem erősítette meg. Arra tehát, hogy egy régi verzió védett ettől a hibától, nem érdemes építeni.

A régi PHP ettől függetlenül is veszélyes. A PHP 7.4 2022 novembere óta, az 5.6 2018 vége óta nem kap biztonsági javítást, így minden azóta felfedezett hiba nyitva maradt rajtuk. A mostani hiba csak egy a sorban, amelyik ráadásul a hírekbe is bekerült.

Támadják már?

A részletek a hivatalos kiadás előtt egy nappal kiszivárogtak. Október 21-én reggel több tárhelycég jelezett támadási kísérleteket, és a Cloudflare még a javítás megjelenése előtt szűrőszabályokat tett ki. A cikk írásakor a jelentések főleg pásztázásról és próbálkozásról szólnak, sikeres betörésről megerősített hír nincs. Ettől még a frissítéssel nem érdemes várni, mert az automata programok ilyenkor napok alatt végigpróbálják az internetet.

És ami október 23-án jött

Két nappal később a PHP egy újabb hibát jelzett (CVE-2026-115560). Ez a frissen javított verziókat is érinti, és még nincs rá javítás, a következő rendes kiadásba kerül. A kihasználása három feltétel együttes teljesülését kívánja, ezért jóval szűkebb a kör. Addig egyetlen PHP-beállítás kikapcsolása véd ellene (session.upload_progress.enabled), ami a PHP2Shell egyik útvonalát is lezárja. Ezt a szolgáltató vagy az üzemeltető állítja be, neked annyi a teendőd, hogy rákérdezel.

Mennyi magyar weboldalt érinthet?

Saját méréseimmel egy kisebb szegmenst néztem meg: közel kétezer kis- és középvállalkozói weboldalt. A bérelt webshop- és oldalépítő platformokat kihagytam, mert azoknál a PHP a platform gondja. A maradékból nagyjából 200 oldal a válaszában kiírja, milyen PHP-verzión fut. Ezek közül:

• 64% olyan PHP-n fut, amihez már nem jön hivatalos javítás. 27% a PHP 7.4-en, 13% a 7.0-7.3 valamelyikén, 11% a 8.0-n vagy a 8.1-en, 13% az 5-ös vagy még régebbi verziókon.

• 36% fut támogatott verzión (8.2-8.5). Ezeknél a javítás egy frissítésnyire van, a szolgáltatónak csak telepítenie kell.

A leggyakoribb lejárt verzió tehát a 7.4. Az 5-ös verziók közül a legtöbb az 5.6, ami 2018 vége óta nem kap javítást. A legrégebbi, amit mértem, egy PHP 4.2: ez 2002-ben jelent meg, vagyis az oldal alatt több mint 24 éves szoftver fut.

És a többi oldal?

A többi oldal nem mutatja a verzióját, és ez jó, mert a kiírt verziószám a támadónak is megmondja, mit próbáljon. Róluk csak becsülni lehet. Ha náluk is hasonló az arány, a cégoldalak nagyjából kétharmada fut lejárt PHP-n. Szerintem ennél valamivel jobb a helyzet, mert aki elrejti a verziót, az jellemzően a frissítésre is jobban figyel. A minta egy kisebb szegmens, ezért országos számként nem kezelném.

A szolgáltatók ettől még nem dolgoznak rosszul. A tárhelyszolgáltatók szinte mind kínálnak friss PHP-verziót. Az oldalak azért ragadnak le a 7.4-en, mert egy régi plugin, sablon vagy saját fejlesztésű rész az újabb verzión nem működne, és senki nem nézte meg, mi kellene a váltáshoz.

Miért jön egyre több ilyen hiba?

2026-ban havonta kétszer annyi biztonsági hibát hoznak nyilvánosságra, mint az év elején. A Google fenyegetéselemző csoportja szerint januárban 5045, augusztusban 10 740 új hiba jelent meg. Az emelkedés egy része az AI-nak köszönhető: a mesterséges intelligencia egyre jobban talál hibát a programkódban, és a Google adatai szerint az AI-jal talált hibák fele távoli kódfuttatást enged, a teljes körben ez az arány 26%. A szám egy részét az is felhajtja, hogy a hibaadatbázisok régi bejegyzéseket is pótoltak.

A támadások ennél lassabban szaporodnak. A valóban kihasznált hibák havi átlaga 2025-ben 10,5 volt, 2026 első nyolc hónapjában 18. A Google szerint a támadók valószínűleg AI-jal is elemzik a kiadott javításokat, hogy gyorsabban építsenek belőlük támadást, de ezt ők is feltevésként írják.

Neked ebből annyi következik, hogy a frissítések sűrűsödnek, és a kiadásuk után egyre kevesebb idő van a telepítésükre. Egy évente egyszer frissített oldal ebben a tempóban lemarad.

Érint-e a Node.js-hiba?

A legtöbb kisvállalkozói weboldalt nem. A Node.js a szerveren futó JavaScript, modern webalkalmazások, webshopok egyedi része, API-k és szerveroldali megjelenítés használja. Egy hagyományos WordPress-oldal alatt jellemzően nincs Node.js.

A hiba a Brotli-kicsomagolóban van (a Brotli egy tömörítési formátum). Akkor veszélyes, ha a program olyan tömörített adatot csomagol ki, amit egy támadó küld vagy irányít: egy letöltött választ, vagy egy beérkező kérés törzsét. A Node.js csapata magas súlyosságúnak sorolta, több biztonsági szervezet kritikusnak. Kihasználásáról eddig nincs hír.

A javított verziók a 22.23.4, a 24.22.1 és a 26.12.1. A Node.js 20 már nem kap javítást, azt újabb verzióra kell váltani. Ha egyedi webalkalmazásod van, kérdezd meg a fejlesztődet, fut-e alatta Node.js, és melyik verzió.

Mit tegyél, ha weboldalad van?

1. Nézd meg a leveleidet. Több tárhelyszolgáltató küldött ki figyelmeztetést, egyesek konkrét teendővel. Olvasd el, mit írnak. Ha a levélben belépés vagy fizetés gomb van, ne azon keresztül lépj be: nyisd meg magad a szolgáltató oldalát. Az ilyen hírek után mindig jönnek hamis „biztonsági figyelmeztetések" is.

2. Kérdezd meg a szolgáltatót vagy a fejlesztőt. Elég ennyi:

• Milyen PHP-verzión fut az oldalam?

• Telepítve van-e már a 2026. október 21-i javítás (PHP2Shell)?

• Ki van-e kapcsolva a session.upload_progress a CVE-2026-115560 miatt?

• Ha egyedi alkalmazásom van: fut-e alatta Node.js, és frissítve van-e?

3. Ha az oldalad 8.1-en vagy régebbin fut, ez a valódi feladat. Osztott tárhelyen, például cPanel alatt, a PHP-verzió váltása a kezelőfelületen néhány kattintás. A kattintás egyszerű, a kérdés az, hogy az oldal működik-e az új verzión. Váltás előtt kell egy friss mentés, és utána végig kell nézni az oldalt: űrlapok, webshop-kosár, belépés. Ha valami eltörik, vissza lehet váltani, de akkor ott maradsz a javítatlan verzión, és a régi bővítményt vagy sablont kell rendbe tenni.

4. Ha saját szervered vagy VPS-ed van, a frissítés a te vagy az üzemeltetőd dolga. Egyes kezelőpanelek a PHP-t külön forrásból telepítik, és az automatikus rendszerfrissítés nem viszi magával. Frissítés után a PHP-folyamatokat újra is kell indítani, különben a régi kód fut tovább a memóriában.

Miért ragad le egy oldal régi PHP-n?

Szinte mindig ugyanaz a történet. Az oldal elkészül, működik, és évekig senki nem nyúl hozzá. Közben a PHP halad tovább, a tárhely egyszer csak figyelmeztet, hogy a régi verziót megszünteti, és kiderül, hogy egy bővítmény vagy egy egyedi kódrész az újon már nem fut. Ilyenkor a legkönnyebb visszaállítani a régi verziót, és ott hagyni.

Egy ilyen biztonsági hibánál derül ki, mennyibe került ez a döntés. A frissen tartott oldalon a javítás egy csomagfrissítés és egy újraindítás. A 7.4-en ragadt oldalon előbb az oldalt kell felkészíteni az új PHP-ra, és ez napokig is tarthat, miközben a rés nyitva van.

Ezért tettem a PHP-verzió követését a weboldal karbantartás rendszeres feladatai közé. Egy év alatt ez néhány óra munka, és nem egy ilyen hét közepén kell kapkodni vele.

Fejlesztőknek, röviden

• A webet kiszolgáló PHP-t ellenőrizd, ne a parancssorit. A php -v mást mutathat, mint amit az FPM vagy az Apache használ. A php-fpm8.4 -v vagy egy ideiglenes phpinfo() a biztos.

• Frissítés után újraindítás: FPM, Apache, a queue workerek és minden hosszan futó PHP-folyamat. A konténerképeket újra kell építeni.

• Ideiglenes védelem, ha nem tudsz azonnal frissíteni: session.upload_progress.enabled = 0 a php.ini-ben (nem ini_set()-tel), PHP 8.5-ön fatal_error_backtraces = 0, alacsonyabb post_max_size. Ezek szűkítik a támadási utat, de nem tesznek biztonságossá.

• Node.js: a szolgáltatás környezetében ellenőrizd a verziót (process.versions), mert a shell más bináris lehet. Az npm-csomagok frissítése nem javítja, csak a futtatókörnyezeté. Átmenetileg a body-parser inflate: false beállítása elutasítja a tömörített kéréstörzseket.

• Rejtsd el a verziót: expose_php = Off, és a webszerver se írja ki a saját verzióját.

Nem tudod, milyen PHP fut az oldalad alatt?

Küldd el az oldalad címét, megnézem, mi látszik belőle kívülről, és megmondom, mit kérdezz a szolgáltatótól. Ha az oldal régi PHP-n ragadt, abban is segítek, mi kell a váltáshoz. Ha nem akarsz legközelebb ilyen hírek miatt aggódni, az üzemeltetési csomagban a PHP és a szerver frissítése is benne van. Írj nekem.