# Mi az a PHP2Shell? A rés egyszerűen elmagyarázva > PHP2Shell egyszerűen elmagyarázva: mi rejlik a két kritikus PHP-rés mögött, mely szerverek érintettek, és milyen lépéseket tegyen meg most. Forrás: https://phpsos.de/hu/php2shell/was-ist-php2shell/ Állapot: 2026. 10. 25. Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6 **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?](https://phpsos.de/hu/php2shell/betroffene-php-versionen/) 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](https://phpsos.de/hu/php2shell/php-version-pruefen/) 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](https://phpsos.de/hu/ratgeber/php2shell-chronologie/) foglalja össze. ## Mit tegyenek most a vállalkozások 1. **Tisztázni, ki a felelős:** saját szerver, menedzselt szerver vagy tárhelyszolgáltató. 2. **A PHP frissítése** egy javított verzióra vagy egy megerősített backportra. 3. **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. 4. **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. 5. **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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal ad. > **Fontos:** > 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](https://phpsos.de/hu/leistungen/php2shell-soforthilfe/) á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. ## Források - [php.net: biztonsági közlemények](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/) - [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)