2026. október 21. | PHP | IT-biztonság
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.
A cikk tartalma
- Mi történt? Az események időrendje
- A két PHP-sebezhetőség áttekintése
- Kiket érint?
- Ezek a PHP-verziók biztonságosak
- Így ellenőrizheti és frissítheti a szerverét
- PHP 8.1 és régebbi: nincs hivatalos frissítés
- Átmeneti intézkedések és a „Le kell kapcsolni a szervert?” kérdés
- Gyakori kérdések
- A Biricon IT Services támogatása
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ó).
- 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ók | CVE-2026-109618 és CVE-2026-109619 |
| Értékelés | CVSS v4.0: 9,2 — kritikus |
| Hatás | Kód végrehajtása a szerveren (Remote Code Execution), bejelentkezés nélkül |
| 1. ok | Sérült memória, ha a PHP a feldolgozás során nem kap több munkamemóriát (Out-of-Memory) |
| 2. ok | Elavult globális állapot, amely a kérések között a memóriában marad |
| Különösen veszélyeztetett | Apache 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.
| PHP-ág | Legalább szükséges | Megjegyzés |
|---|---|---|
| PHP 8.5 | 8.5.12 | aktuális ág |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | A támogatás 2026. december 31-én ér véget |
| PHP 8.1 és régebbi | nincs 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.
apt changelog php8.3-fpm vagy az rpm -q --changelog php | grep CVE-2026-1096 paranccsal).
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_phpeseté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.
Á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.