Röviden: A LiteSpeed PHP-frissítés az lsphp csomagokat érinti, amelyeken keresztül a LiteSpeed LSAPI-val futtatja a PHP-t. A frissítés után az összes lsphp folyamatnak újra kell indulnia, és ez a LiteSpeednél nem mindig történik meg automatikusan a webszerverrel együtt. Mielőtt a szervert javítottnak minősíti, ellenőrizze a csomagállapotot és a folyamatok indulási idejét.
A LiteSpeed, az LSAPI és az lsphp röviden
A LiteSpeed Web Server és az ingyenes változata, az OpenLiteSpeed nem modulként futtatja a PHP-t, hanem egy saját, LSAPI nevű felületen keresztül. Az ehhez tartozó PHP-programok neve lsphp, és többnyire saját csomagforrásokból érkeznek, verziónként például lsphp83 vagy lsphp84. Az olyan paneleken, mint a cPanel, a Plesk vagy a CyberPanel, emellett a panel saját PHP-csomagjai is szerepet kaphatnak.
A PHP2Shell a CVE-2026-109618 és a CVE-2026-109619 rést jelöli magában a PHP-ban, mindkettő CVSS v4.0 9,2 értékű. A PHP-projekt kifejezetten az érintett üzemmódok között említi a LiteSpeedet. Javított a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzió.
LiteSpeed PHP-frissítés: a készlet felmérése
Először derítse ki, mely lsphp-verziók vannak telepítve, és melyek vannak használatban. A következő parancsok csak olvasnak. Az útvonalak és a csomagnevek példák, és a telepítéstől és a disztribúciótól függnek.
# Telepített lsphp-verziók (tipikus útvonal)
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null
for p in /usr/local/lsws/lsphp*/bin/lsphp; do echo "$p"; "$p" -v | head -1; done
# Csomagállapot (példák)
rpm -qa | grep -E '^lsphp[0-9]+' | sort
dpkg -l | grep -E 'lsphp[0-9]+'
# Futó lsphp folyamatok indulási idővel
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Vesse össze a listát a konfigurációval: melyik virtuális host melyik External App Handlert használja? A LiteSpeed felületén ezt a Server Configuration alatt és a virtuális hostok beállításaiban találja. A hozzárendelés nélküli verziókat is frissítse vagy távolítsa el.
Backportok és csomagforrások figyelembevétele
Ha az lsphp külső forrásból származik, annak csomagállapota dönt. Ha egy panel vagy egy disztribúció szállítja a PHP-t, annak adata érvényes. Mindkét esetben a javítás backportként is érkezhet, anélkül hogy a megjelenített verziószám megváltozna. Ellenőrizze ezért a csomagszolgáltató változási tájékoztatóit, és kétség esetén erősíttesse meg az állapotot. A verziószám önmagában nem bizonyíték.
Újraindítás: mire kell figyelni a LiteSpeednél
A LiteSpeed a PHP-t ún. Detached Modeban is üzemeltetheti. Ilyenkor az lsphp folyamatok a webszervertől függetlenül tovább futnak, hogy a weboldalak a webszerver újraindítása után gyorsabban válaszoljanak. Biztonsági frissítésnél ez buktató: a webszerver újraindult, de a sebezhető kóddal rendelkező régi PHP-folyamatok aktívak maradnak.
# A webszerver újraindítása (az útvonal példa)
/usr/local/lsws/bin/lswsctrl restart
# Utána ellenőrzés: minden lsphp folyamat fiatalabb-e a frissítésnél?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Ha egy lsphp folyamat indulási ideje a frissítés előtti, fejezze be célzottan. A LiteSpeed a következő kérésnél új folyamatot indít a frissített kóddal. Ezt a lépést tervezze a fő terhelési időszakon kívülre, mert utána weboldalanként az első kérés kicsit tovább tarthat.
A PHP-frissítés után a szerver akkor javított, ha egyetlen lsphp folyamat sem régebbi a frissítésnél. Az ellenőrzést rögzítse dátummal és időponttal.
Átmeneti intézkedések a javítás megérkezéséig
Ha egy lsphp-verzióhoz még nem érhető el javított csomag, a php.net átmeneti intézkedéseket javasol. Ezek nem nyújtanak teljes védelmet. Az értékeket az adott lsphp-verzió php.ini fájljában vagy a szerverkonfigurációban adja meg, ne a .user.ini fájlban, és ne ini_set()-tel.
; az érintett lsphp-verzió php.ini fájlja (az útvonal telepítésenként eltér)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Feltöltési funkcióval a php.net post_max_size = 32M értéket nevezi meg, az upload_max_filesize ennél kisebb. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. A memóriakorlátokat cgroupokon keresztül állítsa be, CloudLinuxon például az ott előirányzott korlátokkal, ne a RLIMIT_AS vagy a RLIMIT_DATA segítségével. Ezután ismét az összes lsphp folyamat újraindítása következik. További részletek: Azonnali intézkedések javítás nélkül. A BSI azt javasolja, hogy ha a frissítés nem lehetséges azonnal, a webszervert ideiglenesen vegyék le a hálózatról.
A frissítés után
A javítás bezárja a rést, de nem távolítja el a már bejuttatott kártevőt, és nem bizonyítja, hogy korábban nem történt semmi. Őrizze meg a hozzáférési naplókat 2026. október 20-tól, és ellenőrizze a weboldalakat új PHP-fájlokra a feltöltési könyvtárakban, idegen adminisztrátori fiókokra és szokatlan kimenő kapcsolatokra. A folyamatos felügyelethez útmutatást ad a biztonsági monitoringunk. A LiteSpeedet futtató cPanel-szervereken emellett érdemes megnézni a cPanel és WHM oldalt.
Sok LiteSpeed-szerver olyan tárhelypanel alatt fut, mint a cPanel, a Plesk, a DirectAdmin vagy a CyberPanel. A panel ilyenkor meghatározza, honnan származik az lsphp, és hogyan telepítik a frissítéseket. Ebben az esetben a frissítéseket a panelen vagy annak csomagforrásain keresztül végezze, és ne telepítsen párhuzamosan egy második forrásból, mert különben nehezen követhető, melyik változat fut ténylegesen. Rögzítse emellett, melyik weboldal melyik lsphp-verzióval működik. Sok ügyfélfiókos szervereken ez a lista az alapja annak, hogy célzottan tájékoztassa a fióktulajdonosokat, és a frissítés után szúrópróbaszerűen ellenőrizze, hibátlanul futnak-e a weboldalak. Azok a weboldalak, amelyek már nem támogatott PHP-verziót követelnek, külön listára tartoznak, mert rájuk nem jön hivatalos frissítés.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a szerver összes lsphp-verzióját, csomagforrását és kezelő-hozzárendelését.
- A PHP-javítási szolgáltatáson keresztül frissítünk, befejezzük az összes régi lsphp folyamatot, és dokumentáljuk az igazolást.
- Ahol még nincs csomag, az átmeneti értékeket szerverszinten állítjuk be, és cgroupokkal korlátozzuk a memóriát.
- Ellenőrizzük a weboldalakat támadás nyomaira, és mentjük a naplókat.
Gyakori kérdések
Érinti a LiteSpeedet a PHP2Shell?
Igen. A PHP-projekt szerint a LiteSpeed az érintett üzemmódok közé tartozik. A rések magában a PHP-ban vannak, amelyet a LiteSpeed LSAPI-n keresztül futtat. Ezért az lsphp csomagok állapota a döntő.
Miért futnak a frissítés után még régi lsphp folyamatok?
A LiteSpeed a PHP-folyamatokat a webszervertől függetlenül tovább futtathatja, hogy rövidítse a betöltési időket. A webszerver újraindítása az üzemmódtól függően nem fejezi be azonnal őket. Ezért ellenőrizze az összes lsphp folyamat indulási idejét.
Érvényes ez az OpenLiteSpeedre is?
Alapvetően igen. Az OpenLiteSpeed is lsphp-t használ LSAPI-n keresztül. Az útvonalak, a csomagforrások és a kezelőfelület eltérnek, de a frissítés, az újraindítás és az ellenőrzés elve ugyanaz marad.
Segít a LiteSpeed-gyorsítótár a rés ellen?
Nem. Az oldal-gyorsítótár ugyan bizonyos oldalakat PHP nélkül szolgál ki, de a PHP-ig eljutó kérések támadhatók maradnak. A gyorsítótár nem helyettesíti a PHP-frissítést.