# Javítani, lekapcsolni vagy várni? Döntési segédlet a PHP-rés esetén

> Weboldalt offline venni a PHP-rés miatt? Döntési segédlet javítás, lekapcsolás és várakozás között, szempontokkal, lefolyással és őszinte korlátokkal.

Forrás: https://phpsos.de/hu/blog/patchen-abschalten-abwarten/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/blog/behoerden-webseiten-offline/) 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.

1. **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.
2. **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](https://phpsos.de/hu/php2shell/php-version-pruefen/) mutatja.
3. **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.
4. **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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) tartalmazza.
5. **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.

> **Fontos:**
> 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?

1. Önnel együtt rövid időn belül tisztázzuk, mely rendszerek érintettek, és milyen javítási állapot igazolt.
2. A vezetésnek egy oldalas döntési alapot szállítunk: lehetőségek, kockázatok, ajánlott út.
3. 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](https://phpsos.de/hu/leistungen/php2shell-soforthilfe/) részeként.
4. 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.

## Források

- [BSI: figyelmeztetés a PHP2Shellről](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [hessenschau: hesseni hatósági weboldalak lekapcsolva](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: biztonsági rés a PHP-ban](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)