Röviden: A PHP-hez való virtuális javítás áthidalja az időt a valódi frissítés telepítéséig. Ehhez egy webalkalmazás-tűzfal szabályait kombináljuk azokkal az átmeneti intézkedésekkel, amelyeket a php.net a PHP2Shell kapcsán közzétett, és rögtön megállapítjuk a rendes javításhoz vezető utat. Teljes védelmet ez nem nyújt, de az átmeneti időben csökkenti a kockázatot.
Mikor van értelme a virtuális javításnak PHP-hez
A BSI (a német Szövetségi Információbiztonsági Hivatal) PHP2Shell esetében azonnali frissítést ajánl, és ha az nem megy, a webszerverek átmeneti levételét a hálózatról. Sok vállalkozásnak egyik sem megy azonnal: egy webshopnak elérhetőnek kell maradnia, egy saját fejlesztés a frissítés előtt tesztet igényel, vagy a szerver PHP 8.1-gyel és régebbivel fut, amelyhez nincs már hivatalos frissítés.
Ezekben az esetekben a virtuális javítás egy híd. Nem helyettesíti annak eldöntését, hogy nem lenne-e helyénvalóbb az offline üzem. Ezt a mérlegelést Ön végzi, mi a műszaki értékelést adjuk.
Miért nem elég egy WAF önmagában
A Cloudflare támadási kísérleteket észlelt, és védelmi szabályokat vezetett be, de figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. Ennek oka a rések természetében rejlik. A CVE-2026-109618 esetében egy Out-of-Memory állapot megszakíthatja a PHP-t, miközben a kérésadatok csak részben vannak inicializálva. A CVE-2026-109619 esetében a belső állapot a memória felszabadítása után megmaradhat, és egy későbbi kérés ugyanabban a workerben felhasználhatja. Az ilyen hibák a szerver állapotától függnek, nem csak egyetlen kérés tartalmától.
Ezért több rétegre építünk: a szerver előtti WAF-szabályokra, magában a PHP-ban lévő átmeneti intézkedésekre és a szerver fokozott megfigyelésére. Minden réteg elfog egy részt, egyik sem elég egyedül. Együtt időt nyernek Önnek a frissítés rendezett telepítéséhez.
A php.net szerinti átmeneti intézkedések
A php.net több olyan beállítást nevez meg, amely csökkenti a kockázatot, kifejezetten teljes védelem nélkül. Fontos, hogy az alkalmazások ne írhassák felül ezeket az értékeket. Példa egy feltöltéseket is kezelő PHP-FPM-poolra:
; PHP2Shell átmeneti intézkedések (nem teljes védelem), utána az összes workert újra kell indítani
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; csak PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Feltöltések nélkül a php.net post_max_size = 8M értéket ajánl. Mivel a memory_limit korlátozását feloldják, hozzátartozik egy memóriahatár a konténer vagy a cgroup szintjén, nem az RLIMIT_AS vagy az RLIMIT_DATA révén. A session.upload_progress.enabled=0 beállításnak a php.ini-be, az FPM-poolba vagy a szerverkonfigurációba kell kerülnie, nem az ini_set()-be vagy a .user.ini-be. Egyúttal ez a megoldás a CVE-2026-115560 tudnivalójára is. Az összes intézkedés áttekintése a Azonnali intézkedések, ha még nem tud javítani oldalon van.
Az átmeneti intézkedések csak az összes PHP-worker újraindítása után hatnak. És csak a jövőbeli támadások ellen védenek: azt, hogy korábban bejutott-e már valaki, nem válaszolják meg.
Mikor jobb választás az offline üzem
A virtuális javítás nem minden helyzetben a helyes válasz. Egyes konstellációkban azt tanácsoljuk, hogy kövesse a BSI-t, és a webszervert vegye át ideiglenesen le a hálózatról a javításig:
- a szerver Apache-csal és mod_php-val fut, ahol a PHP-csapat a legmagasabbra értékeli a kockázatot, és exploitot mutattak be, még mielőtt az alkalmazáskód egyáltalán futna
- a szerveren különösen védendő adatok vannak, például egészségügyi, ügyfél- vagy fizetési adatok
- nincs lehetőség az átmeneti intézkedések rögzítésére a szerverkonfigurációban, például egyes megosztott tárhelycsomagoknál
- már vannak jelek arra, hogy a szervert megtámadták
Az átmeneti offline üzem nem jelenti azt, hogy a weboldalát feltörték. Egyes szolgáltatók elővigyázatosságból levették a weboldalaikat. A látogatóknak szóló rövid, tárgyilagos tájékoztató oldal ilyenkor többnyire jobb megoldás, mint egy meg nem magyarázott kiesés.
Hogyan segít konkrétan a PHP SOS?
- A helyzet vizsgálata: Felmérjük a PHP-verziókat, az üzemmódokat és a meglévő védelmi rétegeket, például a CDN-t, a WAF-ot vagy a reverse proxyt. A mod_php esetében felhívjuk a figyelmet a PHP-csapat által ott látott megnövekedett kockázatra.
- Rétegek kiépítése: Aktiváljuk vagy kiegészítjük a WAF-szabályokat, az átmeneti intézkedéseket rögzítetten beállítjuk a szerverkonfigurációban, és konténeren vagy cgroupon keresztül korlátozzuk a memóriát. Nginx-beállításoknál az Nginx és PHP-FPM biztosítása oldalra támaszkodunk.
- Újraindítás és teszt: Az összes PHP-folyamatot újraindítjuk, majd ellenőrizzük a feltöltéseket, űrlapokat, bejelentkezést és a pénztárat.
- Megfigyelés: Az átmeneti időben fokozottan figyelünk a workerek összeomlásaira, a memóriacsúcsokra és a szokatlan folyamatokra.
- A javítás megtervezése: Meghatározzuk, mikor és hogyan jön a rendes frissítés, és a PHP-javítási szolgáltatással valósítjuk meg.
Mit kap, mire van szükségünk, és mit nem ígérünk
Dokumentációt kap az összes beállított szabályról és beállításról indoklással, a tesztek eredményeiről, valamint a valódi javításhoz tartozó időpont- és intézkedési tervről. Öntől szerver- vagy panel-hozzáférésre, a CDN-hez vagy WAF-hoz való hozzáférésre (ha van), egy műszaki kapcsolattartóra és az alkalmazásai feltöltési funkcióira vonatkozó adatokra van szükségünk.
Nem ígérjük, hogy a virtuális javítás megakadályoz egy támadást. Korlátozott ideig csökkenti a kockázatot. A PHP 8.1 és régebbi verzióknál nem tartós állapot; ott az átállás egy támogatott verzióra beletartozik a tervbe.
Gyakori kérdések
Mi az a virtuális javítás?
A virtuális javítás azt jelenti, hogy egy ismert rést az alkalmazás előtt árnyékolunk le, ahelyett hogy magát a kódot módosítanánk. Ez többnyire webalkalmazás-tűzfalon (WAF) vagy konfigurációs változtatásokon keresztül történik. Áthidalás, nem a frissítés pótléka.
Elég a CDN-szolgáltatóm WAF-ja a PHP2Shell ellen?
Önmagában általában nem. A Cloudflare védelmi szabályokat vezetett be, de maga is figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A WAF az átmeneti intézkedések és a javítás mellett egy további réteg.
Meddig támaszkodhatok a virtuális javításra?
A lehető legrövidebb ideig. Arra való, hogy áthidalja a rendes frissítésig tartó időt, például amíg szabad lesz egy karbantartási időablak, vagy amíg egy alkalmazást letesztelnek. A PHP 8.1 és régebbi verzióknál ehhez migrációs terv is tartozik.
Zavarhatják a weboldalamat az átmeneti intézkedések?
Igen, ez lehetséges. A kisebb feltöltési korlátok megakadályozhatják a nagy fájlok feltöltését, a session upload progress kikapcsolása pedig a feltöltés közbeni folyamatjelzőket érinti. A legfontosabb funkciókat minden változtatás után teszteljük.