Továbbugrás a tartalomhoz

PHP2Shell: kritikus PHP-rések – így foltozza őket most

A BSI figyelmeztet a CVE-2026-109618 és CVE-2026-109619 kapcsán: érintett verziók, biztonságos frissítések és ellenőrzési útmutató
2026. október 21. által
PHP2Shell: kritikus PHP-rések – így foltozza őket most

2026. október 21. | PHP | IT-biztonság

PHP2Shell: kritikus PHP-sebezhetőség, CVE-2026-109618 és CVE-2026-109619, frissítse most a PHP-t

2026. október 21-én a PHP biztonsági csapata frissítéseket tett közzé az összes még támogatott PHP-verzióhoz. Ezek két kritikus sebezhetőséget zárnak be, amelyek PHP2Shell néven váltak ismertté. A BSI ezzel kapcsolatban figyelmeztetést adott ki, és az érintett rendszerek haladéktalan foltozását követeli. Aki PHP-s webszervert üzemeltet, még ma lépjen. Ez azokra is vonatkozik, akik „csak” egy WordPress-t, Nextcloudot vagy Joomlát üzemeltetnek, mert ezek az alkalmazások PHP-n futnak.

Ez a cikk összefoglalja, mi történt, mely PHP-verziók érintettek, melyik verzióra van most szüksége, és hogyan ellenőrizheti néhány perc alatt, hogy a szervere védett-e.

Mi történt? Az események időrendje

A PHP biztonsági csapata előre bejelentette a javítások közzétételét, hogy a tárhelyszolgáltatóknak és az adminisztrátoroknak legyen idejük felkészülni. Maga a közzététel 2026. október 21-én történt. A BSI még ugyanazon a napon kiadta figyelmeztetését (1.1-es verzió).

Idővonal: előzetes figyelmeztetés 2026. 10. 20-án, PHP-javítások 2026. 10. 21-én 14:00 UTC-kor, BSI-figyelmeztetés 2026. 10. 21-én

  • 2026. október 20.: A PHP biztonsági csapatának előzetes figyelmeztetése, hogy másnap biztonsági frissítések jelennek meg.
  • 2026. október 21., 14:00 UTC (16:00 közép-európai nyári idő szerint): Megjelennek a PHP 8.5, 8.4, 8.3 és 8.2 javításai.
  • 2026. október 21.: A BSI figyelmeztet a „kritikus sebezhetőségekre, amelyek világszerte fenyegetik a webalkalmazásokat”, és haladéktalan foltozást javasol. A BSI közlése szerint nagy tárhelyszolgáltatók részben elővigyázatosságból leválasztották a szervereket a hálózatról.

A két PHP-sebezhetőség áttekintése

Két különálló hibáról van szó a PHP magjában: a CVE-2026-109618 és a CVE-2026-109619. Mindkettő a PHP biztonsági csapatának közlése szerint ahhoz vezethet, hogy egy támadó programkódot hajthat végre a szerveren bejelentkezés nélkül (unauthenticated Remote Code Execution). A sebezhetőségeket CVSS v4.0: 9,2 (kritikus) értékeléssel minősítették.

JellemzőJelentés
AzonosítókCVE-2026-109618 és CVE-2026-109619
ÉrtékelésCVSS v4.0: 9,2 — kritikus
HatásKód végrehajtása a szerveren (Remote Code Execution), bejelentkezés nélkül
1. okSérült memória, ha a PHP a feldolgozás során nem kap több munkamemóriát (Out-of-Memory)
2. okElavult globális állapot, amely a kérések között a memóriában marad
Különösen veszélyeztetettApache mod_php-val

A BSI értékelése szerint a közzététel időpontjában nem voltak megerősített támadások, de voltak meg nem erősített jelek kihasználási kísérletekre. Egy ilyen széles körben elterjedt szoftver kritikus résein tapasztalat szerint számítani kell arra, hogy a támadók elemzik a javításokat, és automatizált támadásokat készítenek elő. A foltozásra szánt időablak ezért rövid.

Kiket érint?

Alapvetően minden olyan szerver érintett, amelyen PHP fut, függetlenül attól, hogyan csatlakozik a PHP: PHP-FPM, mod_php az Apache-ban, php-cgi, FrankenPHP vagy LiteSpeed. A PHP biztonsági csapata szerint a kockázat Apache mod_php-val a legmagasabb.

A BSI kifejezetten megnevezi azokat a PHP-ra épülő alkalmazásokat, amelyek emiatt szintén érintettek lehetnek:

  • Tartalomkezelő rendszerek: WordPress, Drupal, TYPO3, Joomla
  • Webshop-rendszerek: Magento
  • Felhő- és fájltárolás: Nextcloud
  • Tűzfal-felületek: pfSense, OPNsense

Ehhez az alkalmazásnak magának nem kell hibásnak lennie. A rés a PHP-ban van, ezért a WordPress, a Nextcloud & társai frissítése önmagában nem segít. A szerveren lévő PHP-verziót kell frissíteni. Az olyan tűzfalaknál, mint a pfSense és az OPNsense, a javított PHP-verzió a gyártó mindenkori firmware-frissítésével érkezik.

Ezek a PHP-verziók biztonságosak

A sebezhetőségeket a következő verziók javítják. Minden, ami ez alatt van, sebezhetőnek számít.

Biztonságos PHP-verziók a CVE-2026-109618 és CVE-2026-109619 után: PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35

PHP-ágLegalább szükségesMegjegyzés
PHP 8.58.5.12aktuális ág
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35A támogatás 2026. december 31-én ér véget
PHP 8.1 és régebbinincs hivatalos frissítés, lásd alul

Így ellenőrizheti és frissítheti a szerverét

1. A telepített PHP-verzió megállapítása

A szerver parancssorában a php -v a parancssori PHP verzióját mutatja. A webszerver másik PHP-verziót is használhat. Ezért ellenőrizze a PHP-FPM, illetve az Apache-modul verzióját is, például a php-fpm8.3 -v paranccsal, vagy egy olyan oldalon keresztül, amely a phpinfo() függvényt kiírja (ezt utána azonnal távolítsa el).

2. Frissítés telepítése a csomagkezelőn keresztül

Debian, Ubuntu, RHEL és rokon rendszerek esetén a javított verzió a szokásos csomagkezelőn keresztül érkezik, például apt update && apt upgrade vagy dnf upgrade paranccsal. Harmadik féltől származó forrásoknál, mint a Sury PPA vagy a Remi repository, az új csomagok általában rövid időn belül megjelennek.

3. A PHP-szolgáltatás újraindítása

Egy csomagfrissítés önmagában nem elég: a futó PHP-folyamatok a régi kódot tartják a memóriában. Indítsa újra a PHP-FPM-et (systemctl restart php8.3-fpm), illetve az Apache-ot (systemctl restart apache2), majd ellenőrizze, hogy a folyamatok a frissítés után indultak-e el.

4. Tárhelyen futó weboldalak

Megosztott tárhelynél általában a szolgáltató frissít. Az ügyfélmenüben többnyire weboldalanként beállítható a PHP-verzió. Válasszon ott egyet a fent említett biztonságos verziók közül, vagy érdeklődjön a szolgáltatónál a javítások állásáról. A BSI közlése szerint egyes szolgáltatók elővigyázatosságból levették a szervereket a hálózatról. Ha az Ön oldala rövid időre elérhetetlen, ez lehet az oka.

PHP 8.1 és régebbi: nincs hivatalos frissítés

A PHP 8.1-hez és régebbi verziókhoz már nincsenek hivatalos biztonsági frissítések. Az ilyen rendszerek üzemeltetőinek két lehetősége van:

  • Átállás egy támogatott verzióra (ajánlott). Minél régebbi a verzió, annál nagyobb az alkalmazás és a bővítmények átalakítási igénye, ezért az átállást előtte tesztelni kell.
  • A javítások visszaportolása. A PHP biztonsági csapata a javításokat fejlesztési ágakban a GitHubon tette elérhetővé. Aki maga fordítja a PHP-t, ezeket a módosításokat átveheti régebbi verziókba. Ez átmeneti megoldás, és szakértelmet igényel.

A PHP 8.2 is csak 2026. december 31-ig támogatott. Tervezze be ezért már most az átállást a PHP 8.4-re vagy 8.5-re, és ne halassza az évfordulóra.

Átmeneti intézkedések és a „Le kell kapcsolni a szervert?” kérdés

A PHP biztonsági csapata a bejelentéssel együtt ideiglenes védelmi intézkedéseket is leírt. Ezek csökkentik a kockázatot, de a réseket nem zárják be teljesen. Nem helyettesítik a frissítést, és csak arra valók, hogy áthidalják a frissítésig tartó időt.

Hogy egy szervert a frissítésig le kell-e venni a hálózatról, az a jelentőségétől és az elérhetőségétől függ. A BSI kifejti, hogy nagy szolgáltatók megtették ezt a lépést. Ökölszabályként érvényes:

  • Nyilvánosan elérhető szerver, a frissítés most lehetséges: azonnal foltozni, leállítás nem szükséges.
  • Nyilvánosan elérhető szerver, a frissítés rövid időn belül nem lehetséges: a hozzáférést korlátozni (például tűzfallal csak ismert címekre), vagy a szolgáltatást átmenetileg leállítani, különösen mod_php esetén.
  • Csak belsőleg elérhető szerver: hamarosan foltozni, a sürgősség kisebb.

Gyakori kérdések

Frissítenem kell a WordPresst, a Joomlát vagy a Nextcloudot?

Nem emiatt a sebezhetőség miatt. A hiba a PHP-ben van, nem az alkalmazásban. Frissítse a PHP-verziót a szerveren. Az alkalmazás frissítése ettől függetlenül mégis ajánlott.

Honnan tudhatom, hogy valaki már kihasználta a sebezhetőséget?

Biztos állítást nehéz tenni. Gyanút keltenek az ismeretlen PHP-fájlok a webkönyvtárban, a webszerver felhasználója alatt futó szokatlan folyamatok, az új felhasználói fiókok vagy cron-feladatok, valamint a szokatlan kimenő adatforgalom. Konkrét gyanú esetén a rendszert forenzikus vizsgálatnak kell alávetni, kétség esetén pedig újra kell telepíteni.

Elég egy Web Application Firewall?

A tűzfal képes elfogni az ismert támadási mintákat, de nem helyettesíti a frissítést. A több védelmi réteg együttműködéséről további információt talál a következő cikkünkben: Az Odoo 19 védelme: tűzfal, 2FA & Web RBL. Az alapelvek minden webalkalmazásra érvényesek.

Érinti az Odoót?

Nem. Az Odoo Pythonban íródott, és nem PHP-n fut. Csak az ugyanazon a szerveren futó PHP-alkalmazásokat érintheti a probléma.

Hol találom a hivatalos információkat?

A PHP biztonsági csapatának közleményét a következő helyen találja: php.net hírarchívum (a 2026. október 20-i bejegyzés), a verziókat pedig itt: php.net/downloads. A BSI figyelmeztetésének száma 2026-297981-1032, és itt jelent meg: bsi.bund.de .

A Biricon IT Services támogatása

Ha nem biztos abban, hogy melyik PHP-verzió fut a szerverén, vagy segítségre van szüksége a javítások telepítésében, szívesen támogatjuk: az összes PHP-rendszer felmérésében, a frissítések telepítésében, a támogatott PHP-verzióra való átállásban és a kompromittálódás ellenőrzésében. IT-szolgáltatóként kis- és középvállalkozások szervereit, tűzfalait és webalkalmazásait gondozzuk.

Lépjen velünk kapcsolatba

Állapot: 2026. október 21. A helyzet rövid időn belül változhat; mérvadók a PHP biztonsági csapatának és a BSI-nek a közzétételei.