Röviden: A PHP2Shell két kritikus biztonsági rés közös neve magában a PHP-ban, a CVE-2026-109618 és a CVE-2026-109619. Ezeken keresztül a támadók sebezhető webszervereken bejelentkezés nélkül futtathatnak kártékony kódot. Megoldást csak a javított PHP-verzióra való frissítés nyújt, az összes PHP-folyamat ezt követő újraindításával.
Mi az a PHP2Shell?
A PHP az a programozási nyelv, amelyen a weboldalak nagy része fut: a WordPress-t vagy TYPO3-at használó céges oldalak, a Shopware-t vagy WooCommerce-t használó webshopok, a belső portálok és a saját fejlesztések. 2026. október 21-én a PHP-projekt biztonsági frissítéseket tett közzé két résre, amelyek PHP2Shell néven váltak ismertté.
Mindkét rést CVSS v4.0 9,2 értékkel minősítették, vagyis kritikusnak. A következmény mindkét esetben ugyanaz: kártékony kód távoli futtatása anélkül, hogy a támadónak be kellene jelentkeznie. A szakemberek „unauthenticated Remote Code Execution“-ről beszélnek. Aki kódot futtathat a szerveren, az a legrosszabb esetben adatokat olvashat, hátsó ajtókat építhet be, vagy a szervert további támadásokra használhatja.
A megértéshez fontos: a rés nem egy meghatározott CMS-ben vagy bővítményben van, hanem a PHP-ban. A WordPress, a Shopware vagy a TYPO3 frissítése ezért nem zárja le.
Miért ennyire komoly a rés?
A biztonsági hatóságok szemszögéből három pont teszi a PHP2Shell-t különösen kényessé:
- Kiterjedés: A PHP elterjedt üzemmódjai érintettek, nevezetesen a PHP-FPM, az Apache mod_php-val, a php-cgi, a FrankenPHP és a LiteSpeed. A Palo Alto Networks (Unit 42) több mint 22,6 millió kitett, potenciálisan sebezhető példányt számolt össze.
- Nincs szükség bejelentkezésre: A támadónak sem jelszóra, sem felhasználói fiókra nincs szüksége.
- Korai időpont: Az Apache mod_php esetében a PHP-csapat szerint exploitot mutattak be, még mielőtt az alkalmazáskód egyáltalán futna. A weboldalon belüli védelmi funkciók ilyenkor nem érvényesülnek.
A BSI a 3. riasztási szintet (narancs) hirdette ki. Azonnali frissítést ajánl, és ha az nem lehetséges azonnal, az érintett webszerverek átmeneti levételét a hálózatról.
Mely szerverek érintettek a PHP2Shell által?
A réseket a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították. E ágak régebbi állapotai érintettek. A PHP 8.1-hez és a régebbiekhez már nincs hivatalos frissítés; a szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg. A teljes áttekintést a Mely PHP-verziókat érinti? oldalon találja.
Egy sajátosság: a Linux-disztribúciók és a tárhelyszolgáltatók a javításokat részben backportként telepítik. Ilyenkor a Plesk például továbbra is 8.2.34-et jelez, noha a hiba javítva van. A csomagállapot és a szolgáltató megerősítése a mérvadó. Hogyan ellenőrizze ezt, azt a PHP-verzió és javítási állapot helyes ellenőrzése magyarázza.
Mi bizonyított, és mi van nyitva?
Bizonyított a két CVE-szám, a javított verziók és az átmeneti intézkedések, amelyeket a php.net közzétett. Október 23-án érkezett egy tudnivaló egy további résről, a CVE-2026-115560-ról, amely csak szokatlan konfigurációnál érvényesül.
Valószínű, hogy a támadók továbbra is aktívan keresik a javítatlan szervereket. Médiabeszámolók szerint egy első támadási kísérletet már október 17-én megfigyeltek, vagyis a javítások közzététele előtt. A Cloudflare támadási kísérletekről számolt be, és védelmi szabályokat vezetett be, de felhívja a figyelmet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők.
Nyitott, hogy hány szervert támadtak meg már sikeresen. Széles körben megerősített sikeres támadások a BSI szerint kezdetben nem voltak ismertek. Nincsenek közzétett, megerősített Indicators of Compromise. Hogy egy szerver érintett volt-e, ezért csak viselkedéselemzéssel lehet megítélni. Az időbeli lefolyást az október 17-től 25-ig tartó kronológia foglalja össze.
Mit tegyenek most a vállalkozások
- Tisztázni, ki a felelős: saját szerver, menedzselt szerver vagy tárhelyszolgáltató.
- A PHP frissítése egy javított verzióra vagy egy megerősített backportra.
- Az összes PHP-folyamat újraindítása. Az új fájlok önmagukban nem elegendők, amíg a régi folyamatok a memóriában futnak.
- A naplók mentése, méghozzá október 20-tól. A szakmai sajtó azt tanácsolja, hogy ezeket az adatokat őrizzék meg.
- Nyomok ellenőrzése. A javítás nem távolítja el a már bejuttatott kártékony szoftvert, és nem bizonyítja, hogy korábban nem történt semmi. Tudnivalókat a Már feltörték a rendszeremet? oldal ad.
A frissítés lezárja az ajtót, de nem takarít ki. Ha a szervere október 17. és a javítás között elérhető volt, a nyomok ellenőrzése kötelező, nem opcionális.
Hogyan segít konkrétan a PHP SOS?
A PHP2Shell azonnali segítséggel átvesszük azokat a lépéseket, amelyeket sok vállalkozás belsőleg rövid időn belül nem tud lefedni:
- Állapotfelmérés: Megállapítjuk minden érintett szerver PHP-verzióját, üzemmódját és csomagállapotát.
- Javítás vagy átmenet: Telepítjük a frissítést, vagy ahol az még nem megy, beállítjuk a php.net átmeneti intézkedéseit, és tisztázzuk, hogy a szervert átmenetileg le kell-e venni a hálózatról.
- Újraindítás és igazolás: Újraindítjuk az összes PHP-folyamatot, és dokumentáljuk az állapotot előtte és utána.
- Nyomellenőrzés: Mentjük a naplókat október 20-tól, és feltűnő jeleket keresünk, amíg az incidens le nem zárul és dokumentálva nincs.
Gyakori kérdések
A PHP2Shell WordPress-rés?
Nem. A rések a PHP-ban vannak, vagyis abban a programozási nyelvben, amelyen a WordPress, a Shopware, a TYPO3 és sok más rendszer fut. A CMS frissítése ezért nem zárja le őket. A szerveren lévő PHP-állapot a döntő.
Nekem mint tárhelyszolgáltatói ügyfélnek magamnak kell tennem valamit?
Megosztott tárhelynél általában a tárhelyszolgáltató telepíti a PHP-frissítést. Ennek ellenére kérjen írásos megerősítést arról, hogy az Ön által használt PHP-verziót javították és újraindították. Azt, hogy a javítás előtt történt-e valami, a frissítés nem válaszolja meg.
Honnan ered a PHP2Shell név?
A név a következményt írja le: a PHP-n keresztül egy támadó a legrosszabb esetben parancssorhoz, vagyis shellhez juthat a szerveren. A hivatalos megnevezések a CVE-2026-109618 és a CVE-2026-109619 CVE-számok.
Megtámadták már a weboldalamat, ha offline-ra vették?
Nem feltétlenül. Egyes szolgáltatók elővigyázatosságból levették a weboldalakat a hálózatról, ahogy a BSI (a német Szövetségi Információbiztonsági Hivatal) ajánlja, ha a frissítés nem lehetséges azonnal. Ez védelmi intézkedés, nem bizonyíték egy támadásra.