Röviden: Aki root szervert vagy vServert maga kezel, annak a PHP2Shell után maga kell megvédenie is: a PHP-csomagokat javított állapotra kell hozni, az összes PHP-folyamatot újra kell indítani, és ellenőrizni kell az eredményt. A számítóközpont üzemeltetője általában csak a hardverrel, a virtualizációval és a hálózattal foglalkozik. Ezután érdemes a szervert tartósan megerősíteni.
Az Ön felelőssége a saját szervernél
Nem menedzselt root szervernél vagy vServernél számítási kapacitást bérel, nem gondozást. Az operációs rendszer, a webszerver, a PHP, az adatbázis, a tűzfal, a mentések és a felügyelet az Ön kezében van. Ügyvezetők és tulajdonosok számára ez azt jelenti: ha a cégen belül vagy egy szolgáltatónál senki nem vállalta át kifejezetten ezeket a feladatokat, akkor senki nem végzi el őket.
A PHP2Shell ezt láthatóvá teszi. A CVE-2026-109618 és a CVE-2026-109619 rés magában a PHP-ban van, és bejelentkezés nélküli kódfuttatást tesz lehetővé. A PHP-projekt 2026. október 21-én kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziót. A BSI (a német Szövetségi Információbiztonsági Hivatal) azonnali frissítést javasol, és ha az nem lehetséges, a webszerver ideiglenes leválasztását a hálózatról.
vServer védelme: a készlet és a csomagállapot ellenőrzése
Először szerezzen áttekintést arról, mely PHP-verziók vannak telepítve, és honnan származnak. Sok szerver a disztribúció csomagjai mellett további csomagforrásokat is használ. A következő parancsok csak olvasnak. A csomagnevek példák.
# Debian/Ubuntu: a telepített PHP-csomagok és eredetük
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Egyáltalán milyen PHP-binárisok vannak?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
A verziószám önmagában nem elég. A disztribúciók a biztonsági javításokat gyakran backportként szállítják, a megjelenített szám ilyenkor régebbi marad. A döntő a csomag változásnaplója.
# Debian/Ubuntu (a csomagnév példa)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-család (a csomagnév példa)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Részletes útmutatót a következő oldalon talál: A PHP-verzió és a javítási állapot ellenőrzése.
A frissítés telepítése és az összes folyamat megújítása
Telepítse a frissítéseket a csomagkezelőn keresztül, majd indítson újra minden szolgáltatást, amely betölti a PHP-t. Felépítéstől függően ez a PHP-FPM, az Apache mod_php-vel, a LiteSpeed vagy egy alkalmazásszerver. A lemezen lévő új fájlok nem elegendők, amíg régi folyamatok futnak a memóriában.
# PHP-t futtató szolgáltatások keresése
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Folyamatok megjelenítése indulási idővel
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: elavult könyvtárakat használó programok felismerése (ha telepítve van)
needrestart -r l
Minden érintett folyamatnak a frissítés után kellett elindulnia. Hasznos a needrestart eszköz Debian-rendszereken, amely megmutatja az elavult könyvtárakat használó szolgáltatásokat. Az újraindítás részleteit a következő oldal írja le: A PHP-FPM és az összes worker újraindítása.
A javítás nem távolítja el a frissítés előtt bejuttatott kártevőt. Őrizze meg a webszerver naplóit 2026. október 20-tól, és ellenőrizze a szervert nyomokra, mielőtt tisztának minősíti.
Az első nyomkereséshez néhány olyan ellenőrzés kínálkozik, amely nem módosít semmit. Keressen olyan PHP-fájlokat, amelyeket 2026. október 17. óta hoztak létre vagy módosítottak a webes könyvtárakban, ismeretlen bejegyzéseket az összes felhasználó crontabjaiban, új rendszerfelhasználókat és SSH-kulcsokat, valamint a webszerver-felhasználó olyan folyamatait, amelyek kimenő kapcsolatokat tartanak fenn.
# 2026. október 17. óta módosított PHP-fájlok (az útvonal példa)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Hálózati kapcsolatok a hozzájuk tartozó folyamattal
ss -tupn
Ezen ellenőrzések egyike sem bizonyít önmagában betörést, és az üres eredmény sem bizonyítja az ellenkezőjét. Megmutatják viszont, hogy szükség van-e mélyebb vizsgálatra. A naplók másolatain dolgozzon, és a gyanús fájlokat ne módosítsa, amíg az állapotot nem mentette. Lelet esetén a rendezett vizsgálat a biztos út. Ilyenkor ne kapcsolja ki egyszerűen a szervert, és ne telepítse azonnal újra, mert így elvesznek azok a nyomok, amelyek a bejelentési kötelezettségek értékeléséhez és egy esetleges feljelentéshez fontosak.
A szerver tartós megerősítése
Az akut javítás után az alapvédelem következik. Nem akadályoz meg minden rést, de korlátozza a kárt, és lerövidíti a reakcióidőt legközelebb. Ezek a pontok váltak be:
- Hozzáférések: SSH csak kulccsal, közvetlen root bejelentkezés nélkül, a kezelőfelületek csak ismert hálózatokból legyenek elérhetők.
- Tűzfal: csak azokat a portokat nyissa meg, amelyekre valóban szükség van, korlátozza a webszerver kimenő kapcsolatait.
- PHP-konfiguráció: veszélyes függvények letiltása, weboldalanként
open_basedir, alkalmazásonként saját poolok és felhasználók. - Fájljogosultságok: a webszerver ne írhassa a programkódot, a feltöltési könyvtárakban ne fusson PHP.
- Frissítések: a biztonsági frissítések automatikus telepítése, az újraindítás és az ellenőrzés fix beütemezése.
- Mentések: mentés a 3-2-1 szabály szerint, legalább egy másolat a szerveren kívül és módosítás ellen védve.
- Naplók: a naplók központi gyűjtése és kellően hosszú megőrzése.
Hogyan néz ki egy megbízható mentés, azt a következő oldal írja le: Mentések a 3-2-1 szabály szerint. Vállalkozások számára keretként a BSI IT-Grundschutz (német IT-alapvédelem) ajánlható.
Mikor jobb választás a menedzselt szerver
A saját szerver akkor éri meg, ha valaki megbízhatóan átveszi a gondozását: követi a frissítéseket, értékeli az olyan helyzeteket, mint a PHP2Shell, és éjszaka is tud reagálni. Ha ez a kapacitás hiányzik, vagy menedzselt szerver, vagy fix karbantartási szerződés a célszerű. Mindkét esetben fontos az illetékességeket írásban rögzíteni. Erről többet itt talál: Menedzselt szerver: a felelősség tisztázása.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a szerver összes PHP-telepítését, csomagforrását és szolgáltatását, és értékeljük a tényleges javítási állapotot.
- Telepítjük a frissítéseket, újraindítjuk az összes folyamatot, és dokumentáljuk az eredményt.
- Ellenőrizzük a szervert a kompromittálódás nyomaira, és mentjük a naplókat egy későbbi kiértékeléshez.
- A szerver-megerősítésünk keretében rendezetten beállítjuk a hozzáféréseket, a tűzfalat, a PHP-poolokat és a jogosultságokat.
- Kérésre átvesszük a folyamatos gondozást biztonsági karbantartási szerződés keretében.
Gyakori kérdések
Automatikusan javítja a vServeremet a számítóközpont?
A nem menedzselt root szervereknél és vServereknél általában nem. A szolgáltató a hardvert vagy a virtualizációt és a hálózatot biztosítja, az operációs rendszert és az összes rajta futó szolgáltatást Ön maga kezeli. Kétség esetén nézze meg a szerződését.
Elegendők az automatikus biztonsági frissítések?
Segítenek, de az ellenőrzést nem helyettesítik. Az automatikus frissítések nem mindig indítják újra a futó PHP-folyamatokat, és a külső forrásból származó csomagokat gyakran nem fedik le. Minden biztonsági frissítés után ellenőrizze a csomagállapotot és a folyamatok indulási idejét.
Hogyan tudom meg, hogy a csomagom tartalmaz-e backportot?
A csomag változásnaplójából és a disztribúció biztonsági közleményeiből. Ha ott szerepel a CVE-szám, a javítás benne van, akkor is, ha a verziószám régebbinek tűnik. Ha a bejegyzés hiányzik, tisztázza az állapotot, mielőtt a szervert javítottnak minősíti.
Mit tegyek, ha a PHP-verziómhoz nem jön javítás?
A PHP 8.1-hez és a régebbiekhez már nem adnak ki hivatalos frissítést. Állítsa be a php.net szerinti átmeneti intézkedéseket, tervezze meg mielőbb az áttérést egy támogatott verzióra, és a BSI ajánlása szerint szükség esetén ideiglenesen vegye le a szervert a hálózatról.