Röviden: Hogy le kell-e kapcsolnia egy weboldalt a PHP-rés miatt, egy kérdésen múlik: igazolhatóan javított állapoton fut-e a PHP azon a szerveren, és újraindították-e az összes folyamatot? Ha igen, nincs szükség lekapcsolásra. Ha a frissítés nem lehetséges azonnal, a BSI (a német Szövetségi Információbiztonsági Hivatal) azt javasolja, hogy a webszervert átmenetileg vegyék le a hálózatról. A várakozás csak akkor védhető, ha a rendszer nem használ PHP-t, nem érhető el nyilvánosan, vagy a szolgáltató írásban megerősítette a javítást.
A helyzet, amelyben döntenie kell
A PHP2Shell két rést foglal magában magában a PHP-ban, a CVE-2026-109618-at és a CVE-2026-109619-et, mindkettő CVSS v4.0 9,2 értékű. Bejelentkezés nélküli, távoli kártékony kódfuttatást tesznek lehetővé. A javított verziók 2026. 10. 21. óta elérhetők: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A PHP 8.1-hez és régebbiekhez már nincsenek hivatalos frissítések.
A BSI narancs riasztási szintet hirdetett, és azonnali frissítést javasol, ennek hiányában átmeneti lekapcsolást. A médiajelentések szerint Mainz városa, a hesseni tartományi kormány egyes szervei és további közintézmények elővigyázatosságból levették a weboldalaikat a hálózatról; a hesseni Staatskanzlei nem jelentett támadást. Hogy a vállalkozások mit vezethetnek le ebből, azt a A hatóságok lekapcsolják a weboldalaikat tartalmazza.
A vállalkozások felelősei számára a kérdés gyakorlatiasabb: mit kezdjünk ma a webshopunkkal, a portálunkkal, a cégweboldalunkkal?
Weboldal offline, javítás vagy várakozás: a három lehetőség összehasonlítása
A következő táblázat egymás mellé állítja a lehetőségeket. Nem helyettesíti az egyedi esetének értékelését, de láthatóvá teszi a mérlegelést.
| Szempont | Azonnali javítás | Átmeneti lekapcsolás | Várakozás |
|---|---|---|---|
| Védelem a PHP2Shell ellen | Magas, ha a javítás és az újraindítás igazolt | Magas a lekapcsolás idejére | Nincs, amíg javítatlan |
| Üzemszünet | Rövid, a frissítéshez és az újraindításhoz | Órák vagy napok | Nincs |
| Előfeltétel | Támogatott PHP-verzió, hozzáférés, karbantartási ablak | A vezetés döntése, statikus pótoldal | Igazolt ok arra, hogy miért nincs kockázat |
| Ráfordítás | Kicsi vagy közepes | Műszakilag kicsi, szervezetileg nagy | Kicsi, de ellenőrzési ráfordítás az igazoláshoz |
| Tipikus eset | Szerver PHP 8.2-től 8.5-ig | Régi rendszer PHP 8.1-gyel vagy régebbivel, tisztázatlan állapot | PHP nélküli vagy csak belsőleg elérhető rendszer |
| Fennmaradó kockázat | A korábbi behatolás lehetséges marad | A korábbi behatolás lehetséges marad | Teljes mértékben fennáll |
Egy sor figyelmet érdemel: sem a javítás, sem a lekapcsolás nem tisztázza, hogy korábban történt-e már valami. A médiajelentések szerint az első megfigyelt támadási kísérlet 2026. 10. 17-én volt, vagyis a javítás előtt. A lehetséges nyomok vizsgálata ezért minden lehetőséghez hozzátartozik.
Öt kérdéssel a döntésig
Dolgozza végig a kérdéseket sorban. Az első egyértelmű válasz többnyire a döntéshez vezet.
- Fut-e egyáltalán PHP a rendszeren, és elérhető-e az internetről? Ha nem, a rendszert a PHP2Shell közvetlenül nem érinti. Dokumentálja, hogyan állapította ezt meg.
- Igazolt-e a javítási állapot? Igazolt azt jelenti: javított verzió vagy backport a csomag changelogjában szereplő CVE-számokkal, és az összes PHP-folyamat újraindítása. A panelben látható verziókijelzés nem elég. Hogyan ellenőrizheti, azt a PHP-verzió és javítási állapot helyes ellenőrzése mutatja.
- Telepíthető-e a frissítés a következő órákban? Ha igen: javítani, újraindítani, ellenőrizni. Addig átmeneti intézkedések segíthetnek.
- Ha ez nem lehetséges, például PHP 8.1 vagy hiányzó hozzáférés miatt? Akkor a BSI szerint az átmeneti lekapcsolás az út. A php.net szerinti átmeneti intézkedések csökkentik a kockázatot, de nem védenek teljesen; a részleteket a Azonnali intézkedések, ha még nem tud javítani tartalmazza.
- Vannak-e kompromittálódásra utaló jelek? Akkor a kérdés már nem „javítani vagy lekapcsolni”, hanem „az incidens kezelése”. Lekapcsolni, bizonyítékokat rögzíteni, nem törölni elhamarkodottan.
Ha lekapcsol: lekapcsolni helyesen
A lekapcsolásnak a támadási felületet kell eltávolítania, nem csak a nyitóoldalt elrejteni. Egy karbantartási oldal, amelyet továbbra is PHP állít elő, nem teljesíti ezt a célt. Jobb egy statikus HTML-oldal, amelyet a webszerver PHP nélkül szolgál ki, vagy egy átirányítás egy másik szerverre.
Gondoljon mindenre, ami ugyanahhoz a PHP-hez kapcsolódik: aloldalak, alkalmazások vagy készletgazdálkodás felületei, admin-területek, fizetési visszahívások. Egyeztessen előre a fizetési szolgáltatóval és a logisztikával, ha egy webshop érintett. És tájékoztassa a munkatársakat és az ügyfeleket világos szavakkal: az oldal elővigyázatosságból offline, a kapcsolattartás telefonon és e-mailben zajlik. Ez jobb, mint a hallgatás, amely találgatásokat táplál.
A lekapcsolás vége is fontos. Rögzítse, milyen feltétellel kerül vissza az oldal online, például: „a PHP javított állapoton, az újraindítás ellenőrizve, az első nyomvizsgálat eredmény nélkül”. Így a vészféket rendezett folyamattá alakítja.
A lekapcsolás nem vereség. A médiajelentések szerint több közintézmény pontosan ezt tette anélkül, hogy támadás lett volna. Az elővigyázatossági lekapcsolás nem jelenti automatikusan, hogy egy weboldalt feltörtek.
Mikor nincs szüksége szolgáltatóra
Nem minden döntéshez kell külső segítség. Ha a weboldala olyan tárhelyszolgáltatónál van, amely írásban megerősíti a javítási állapotot és az újraindítást, és nincsenek feltűnő jelenségek, egy rövid dokumentációval jól áll. Ugyanez érvényes, ha a saját IT-ja egy támogatott PHP-verziójú szervert maga tud javítani, és uralja az ellenőrzést.
Segítség akkor éri meg, ha régi PHP-verziójú rendszerek futnak, az állapot tisztázatlan, több szerver érintett, vagy behatolásra utaló jelek vannak.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt rövid időn belül tisztázzuk, mely rendszerek érintettek, és milyen javítási állapot igazolt.
- A vezetésnek egy oldalas döntési alapot szállítunk: lehetőségek, kockázatok, ajánlott út.
- Megvalósítjuk a választott utat, vagyis a javítást újraindítással, az átmeneti intézkedéseket vagy a rendezett lekapcsolást statikus pótoldallal, a PHP2Shell azonnali segítségünk részeként.
- Ellenőrizzük a 2026. 10. 17. óta keletkezett nyomokat, és dokumentáljuk az eredményt.
Összegzés
A javítás a normál eset, a lekapcsolás a helyes vészfék, a várakozás csak igazolással védhető. Aki őszintén megválaszolja az öt kérdést, és a döntést írásban rögzíti, a BSI-ajánlásnak megfelelően jár el, és később meg tudja mutatni, miért.
Gyakori kérdések
Le kell kapcsolnom a weboldalamat a PHP2Shell miatt?
Nem, ha a PHP már javított állapoton fut, és az összes folyamatot újraindították. A BSI az átmeneti lekapcsolást arra az esetre javasolja, ha azonnali frissítés nem lehetséges.
Mibe kerül többe egy lekapcsolás: a bevételbe vagy a kockázatba?
Ez csak az egyedi esetben válaszolható meg. Egy órákig tartó kiesés többnyire jobban tervezhető, mint egy behatolás, amelynek következményeit és időtartamát senki sem ismeri. Rögzítse írásban a mérlegelést, függetlenül attól, hogyan végződik.
Futhat egy karbantartási oldal ugyanazon a szerveren?
Igen, ha statikus fájlként, PHP nélkül szolgálják ki. Ha a karbantartási oldalt továbbra is PHP állítja elő, a támadási felület megmarad.
Van olyan eset, amikor a várakozás a helyes választás?
Igen, jól körülhatárolt esetekben: ha a rendszeren nem fut PHP, ha nem érhető el az internetről, vagy ha a szolgáltató írásban megerősítette a javítást és az újraindítást. Az ilyen igazolások nélküli várakozás nem lehetőség, hanem kockázat.
Ki hozza meg a döntést?
Az a személy, aki az üzleti kockázatért felel, általában a cégvezetés vagy a tulajdonos. Az IT szállítja a tényeket. Hogy ki dönt, azt előre rögzíteni kell a vészhelyzeti tervben.