Röviden: A WAF a frissítés helyett nem működik a PHP2Shellnél. Egy webalkalmazás-tűzfal, vagyis a weboldal előtti szűrő, ellenőrzi a kéréseket, és blokkolhatja az ismert támadási mintákat. Maga a rés azonban a PHP-értelmezőben van, és csak a frissítéssel és az összes PHP-folyamat újraindításával szűnik meg. A WAF értelmes kiegészítő réteg és néhány napra szóló híd, nem a megoldás.
Miért teszik fel ezt a kérdést éppen most ilyen gyakran
Sok üzemeltető a PHP2Shell hetében egy látszólag jó hírt olvasott: a Cloudflare saját közlése szerint 2026. 10. 21. 03:02 UTC óta védelmi szabályokat tart aktívan, az ingyenes csomag ügyfeleinek is. Aki amúgy is a Cloudflare vagy egy másik WAF mögött áll, érthetően azt kérdezi, sürgős-e még akkor a frissítés.
Az őszinte válasz: igen. A Cloudflare maga is korlátoz: a kérésadatokon alapuló szabályok önmagukban nem elegendők, ezért a szolgáltatás a szerver válaszát is ellenőrzi. A Cloudflare emellett megváltozott támadási mintákat figyelt meg. És a védelem csak olyan forgalomra hat, amely ténylegesen a Cloudflare-en keresztül fut. Erről a szolgáltatóról a részleteket a Cloudflare védelmi szabályai a PHP2Shell ellen írja le. Itt az alapvető mérlegelésről van szó, szolgáltatótól függetlenül.
Mit lát a WAF, és mit változtat a frissítés
A WAF az alkalmazás előtt ül. Minden kérést lát, összeveti a szabályokkal, és átengedi, blokkolja vagy naplózza. Nem tudja, hogyan dolgozza fel a PHP belsőleg a kérést. A két PHP2Shell-rés viszont pontosan ott keletkezik: a CVE-2026-109618 egy Out-of-Memory állapotnál, miközben a kérésadatok csak részben inicializáltak, a CVE-2026-109619 pedig egy olyan belső állapot miatt, amely egy kérés után ugyanabban a workerben megmarad.
A frissítés kijavítja ezt a kódot. Utána az ok megszűnt, akárhogy néz is ki egy kérés. Aki meg akarja érteni, hol történik ez egy kérés lefolyásában, az alapokat a A kérés életciklusa a PHP-ban tartalmazza.
WAF a frissítés helyett: az őszinte összehasonlítás
| Szempont | Webalkalmazás-tűzfal | PHP-frissítés újraindítással |
|---|---|---|
| Mi javul ki? | Semmi, az ismert mintákat elfogják | Az ok a PHP-értelmezőben |
| Védelem új támadási változatok ellen | Csak ha a szabályokat időben módosítják | Igen, a rés már nem létezik |
| Megkerülhető? | Igen, például az origin szerver közvetlen elérhetőségén keresztül | Nem, feltéve, hogy az összes PHP-folyamatot újraindították |
| Sebesség | Gyakran azonnal aktív | A verziótól, a hozzáféréstől és a karbantartási ablaktól függ |
| Mellékhatások | Téves riasztások, zavart űrlapok vagy feltöltések | Ritkán, verzióugrásoknál kompatibilitási tesztek szükségesek |
| Haszon a következő résnél | Magas, ha gondozott | Nincs, minden résnek megvan a saját frissítése |
| Segít a PHP 8.1-nél és régebbieknél? | Átmenetként | Csak backporttal vagy migrációval |
A táblázat megmutatja, miért tartozik össze a két intézkedés. A WAF gyors és széles, de soha nem teljes. A frissítés teljes, de csak egy bizonyos résre vonatkozik, és nem mindig lehetséges azonnal.
A gyakorlatban gyakran figyelmen kívül hagynak egy pontot: a WAF megváltoztatja a weboldal viselkedését. A szigorú szabályok blokkolhatnak jogos megrendeléseket, kapcsolatfelvételi űrlapokat vagy fájlfeltöltéseket anélkül, hogy valaki azonnal észrevenné. Aki egy WAF-ot válság közben élesít, ezért egyszer maga is végigkattintsa a weboldal legfontosabb folyamatait, és vizsgálja át az első napok naplóit blokkolt, de jogosult kérések szempontjából.
Így kombinálhatja értelmesen mindkettőt
- Azonnal: Ellenőrizze, van-e WAF, és aktívak-e a megfelelő szabályok. A Cloudflare fizetős csomagjainál a szolgáltató szerint állítsa a Managed Rulesetet Blockra.
- Azonnal: Gondoskodjon róla, hogy az origin szerver csak a WAF-on keresztül legyen elérhető, például a tűzfalban csak az ő címtartományaik engedélyezésével. Különben a védelem a levegőbe lő.
- A következő karbantartási ablakon belül: A PHP-t frissítse 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, vagy telepítse a disztribúció megerősített backportját.
- Közvetlenül utána: Indítsa újra az összes PHP-workert és folyamatot, és ellenőrizze, hogy már nem fut régi folyamat. Az új fájlok önmagukban nem elegendők; erről többet a A frissítés után: a PHP-FPM és az összes worker újraindítása tartalmaz.
- Ezután: Tartsa meg a WAF-szabályokat, értékelje a téves riasztásokat, és célzottan állítson be kivételeket a szabályok általános kikapcsolása helyett.
Egy ModSecurity és az OWASP Core Rule Set alapú saját WAF-fal hasonló érhető el; az alapokat a ModSecurity és az OWASP Core Rule Set alkalmazása írja le. Különleges forma a szakmai szerzők által javasolt feltöltési kérések szűrése a valódi feltöltési útvonalakon kívül. Nem hivatalos, megszakíthatja az űrlapokat, és csak teszt után kerüljön üzembe.
Sem a WAF, sem a frissítés nem távolítja el a korábban bejuttatott kártékony szoftvert. A javítás után ellenőrizze, hogy 2026. 10. 17. óta felléptek-e feltűnő jelenségek.
Mikor nincs szüksége WAF-ra, és mikor szolgáltatóra
A WAF nem minden weboldalnál kötelező. Egy kis cégweboldal egy olyan tárhelyszolgáltatónál, amely a PHP-t időben javítja és ezt megerősíti, saját WAF nélkül is gyakran elég jól védett, ha a CMS és a bővítmények naprakészek. Aki a szerverét rövid időn belül maga tudja frissíteni, annak sem kell a WAF hídként.
Értelmessé válik webshopoknál, portáloknál és sok űrlappal rendelkező alkalmazásoknál, olyan régi rendszereknél, amelyeket nem lehet azonnal frissíteni, és ott, ahol több weboldalt akarnak központilag védeni. Szolgáltatóra ehhez csak akkor van szüksége, ha a beállítást, a teszteket és a folyamatos gondozást belül nem fedik le.
Hogyan segít konkrétan a PHP SOS?
- Ellenőrizzük, hogy a WAF-ja ténylegesen minden hozzáférés előtt ül-e, és az origin szerver közvetlenül elérhető-e.
- Szabályokat állítunk be vagy igazítunk, és az űrlapokat, feltöltéseket és interfészeket mellékhatások szempontjából teszteljük.
- Telepítjük a PHP-frissítést, újraindítjuk az összes folyamatot, és dokumentáljuk az állapotot.
- Ahol a frissítés időt vesz igénybe, ott WAF-fal és virtuális javítással áthidaljuk, és a valódi javításra rögzített időpontot adunk.
Összegzés
A „WAF vagy frissítés” kérdés rosszul van feltéve. A frissítés lezárja a rést, a WAF időt nyer, és sok mást elfog. Aki csak a WAF-ra támaszkodik, olyan szabályokban bízik, amelyeket a támadók megkerülhetnek. Aki csak javít, a következő résnél ismét híd nélkül áll.
Gyakori kérdések
Elég a WAF védelemnek a PHP2Shell ellen?
Nem. A WAF ellenőrzi az adatforgalmat, és blokkolhatja az ismert támadási mintákat. Maga a rés a PHP-értelmezőben van, és addig fennáll, amíg a PHP-t nem frissítik és nem indítják újra. A Cloudflare kifejezetten hangsúlyozza, hogy a szabályai nem helyettesítik a frissítést.
Automatikusan védett vagyok a Cloudflare mögött?
Csak azon forgalomra, amely ténylegesen a Cloudflare-en keresztül fut. Ha az origin szerver közvetlenül elérhető az internetről, a védelmet megkerülik. Fizetős csomagoknál a Cloudflare szerint ellenőrizze, hogy a Managed Ruleset Block állásban van.
Megéri a WAF a frissítés után is?
Gyakran igen. A WAF el tudja fogni a tömeges szkenneléseket, a bővítmények elleni ismert támadásokat és a bejelentkezési oldalakkal való visszaéléseket, és a következő résnél időt nyer. Gondozásra és tesztelésre azonban szüksége van, különben a téves riasztások zavarják az üzemet.
Mi az a virtuális javítás?
Azt jelenti, hogy egy sebezhetőséget átmenetileg az alkalmazás előtti szabályokkal árnyékolnak le a kód módosítása helyett. Híd a valódi frissítésig, nem pótlék.