Röviden: Ha azt gyanítja, hogy a szerverét a PHP2Shell-en keresztül törték fel, jelentkezzen most. Érintett? Hívjon minket. Segítünk. Az első üzenettől átvesszük a megfékezést, mentjük a nyomokat, lezárjuk a rést, eltávolítjuk a kártékony kódot, és az incidenst a lezárásáig dokumentáljuk.
Most ne töröljön semmit, és ne telepítsen újra semmit. A törölt fájlok és a felülírt naplók azok a nyomok, amelyekből kiderül, hogy valaki bejutott-e, és hogyan. Szükség esetén válassza le a szervert a hálózatról, de hagyja változatlanul. Vészhelyzet bejelentése, megmondjuk a következő lépést.
Érintett? Jelek arra, hogy a PHP2Shell-t már kihasználták
A PHP2Shell két kritikus rés neve magában a PHP-ban, amelyekkel a támadók bejelentkezés nélkül, távolról futtathatnak kártékony kódot. Egyértelmű ujjlenyomat egyelőre nincs. Ezért az számít, mit csinál a szerver, nem az, hogy mit talál egy szkenner. A behatolásra utaló jelek:
- Olyan webszerver- vagy PHP-FPM-folyamatok, amelyek shellt, például
sh-t vagybash-t indítanak. Ez erős figyelmeztető jel. - Új vagy módosított PHP-fájlok a feltöltési, gyorsítótár- vagy temp-mappákban, amelyeket senki sem hozott létre.
- Cron-feladatok, szolgáltatások vagy SSH-kulcsok, amelyeket Ön nem ismer.
- Ismeretlen célpontok felé irányuló kimenő kapcsolatok, hirtelen magas terhelés vagy szokatlan adatforgalom.
- Kérések a naplókban 2026. október 17-től, különösen feltűnő feltöltések és munkamenet-kérések a javítás telepítése előtt.
- A tárhelyszolgáltató, a böngésző vagy a keresőmotor jelzése spamről, kártevőről vagy átirányításokról.
Többet erről itt talál: Már feltörték a rendszeremet?. Ha egyetlen jel sem látszik, az nem bizonyítja, hogy a szerver tiszta. Csak azt jelenti, hogy eddig semmi sem tűnt fel.
Mit tegyen azonnal
- Ne változtasson semmit. Ne töröljön fájlokat, ne állítson vissza mentést, ne telepítsen újra semmit, amíg a mentés meg nem történt.
- Mentse a naplókat. Kérje meg a tárhelyszolgáltatóját vagy az informatikusait, hogy a hozzáférési, hiba- és rendszernaplókat ne írják felül. A szakmai sajtó azt javasolja, hogy a naplókat 2026. október 20-tól őrizzék meg.
- Döntsön az elérhetőségről. Ha adatok szivároghatnak ki, vagy a látogatók veszélybe kerülhetnek, vegye le az oldalt a hálózatról, vagy kapcsolja karbantartási módba.
- Gyűjtse össze a hozzáféréseket. Jegyezze fel, kinek van hozzáférése a szerverhez, a panelhez, a CMS-hez és az adatbázishoz. A jelszavakat csak egyeztetés után, és egy tiszta eszközről módosítsa.
- Értesítse az érintetteket. A vezetést, az adatvédelmi felelőst, meglévő biztosítás esetén a biztosítót.
- Hívjon vagy írjon nekünk. Minél korábban ismerjük a helyzetet, annál több marad igazolható.
Hogyan segít konkrétan a PHP SOS?
Távolról dolgozunk, kiszállás nélkül, egész Németországban és Európában.
- Helyzetfelmérés: Tisztázzuk, mely rendszerek futnak, melyik PHP-üzemmód van használatban, mi tűnt fel, és mely adatok lehetnek érintettek.
- Mentés és lezárás: Mentjük a fájlokat, az adatbázist és a naplókat, és minden változtatás előtt rögzítjük az állapotot. Utána a rést a javítással zárjuk le, vagy ha az még nem lehetséges, átmeneti intézkedésekkel, és újraindítjuk az összes PHP-folyamatot.
- Vizsgálat és tisztítás: Webshelleket, hátsó ajtókat, cron-feladatokat és idegen hozzáféréseket keresünk, és eltávolítjuk őket, vagy megbízható forrásokból újraépítjük az állapotot. Az eljárást a Kártevők és webshellek eltávolíttatása írja le.
- Keményítés és jelentés: Megváltoztatjuk az érintett titkokat, pótoljuk a védelmi intézkedéseket, és jelentést adunk, amely különválasztja a bizonyítottat, a valószínűt és az ismeretlent.
Ha az incidens egy szerveren túlra terjed, átlépünk a strukturált Incident Response eljárásba. Ha bíróság előtt is megálló bizonyítékokra van szükség, bevonjuk az IT-forenzikát.
Miért nem elég egy támadás után pusztán a javítás
A rések a PHP-értelmezőben vannak, nem a CMS-ben. A PHP-projekt 2026. október 21-én kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziót. Aki ezt követően frissített, és az összes workert újraindította, védett az ezen az úton érkező új támadások ellen. Ami viszont korábban odakerült egy támadótól, az ott marad: egy webshell, egy további fiók, egy ütemezett feladat. Éppen ezért különösen fontosak a 2026. október 17. és 21. közötti napok.
Ehhez jön egy második szempont: a webshell gyakran csak az első lépés. Aki a webszerveren kódot futtathatott, az konfigurációs fájlokat is olvashatott, és belőlük adatbázis-, levelezési és API-hozzáféréseket szerezhetett. Ezeket a titkokat le kell cserélni, különben az ajtó nyitva marad, noha a PHP javított. Hogyan érdemes a fájlokat és az időpontokat átvizsgálni, azt a Webshellek felismeréséről szóló útmutató írja le.
Bejelentési kötelezettség és dokumentáció
Ha személyes adatok is érintettek lehettek, a felügyeleti hatóságnak szóló bejelentés 72 órán belül szükségessé válhat. Az óra a tudomásszerzéstől számít, nem a vizsgálat lezárásától. Hogy az Ön esete bejelentésköteles-e, azt az adatvédelmi felelős vagy egy ügyvéd dönti el; jogi tanácsadást nem nyújtunk. A dokumentációnk ehhez adja az alapot. A határidőről többet olvashat itt: GDPR-bejelentési kötelezettség 72 órán belül, a további lépéseket pedig a Feltörés utáni ellenőrzőlista tartalmazza.
Mit érdemes elküldenie nekünk
- Leírás arról, mi tűnt fel, mióta, és ki vette észre
- A szerver típusa: saját szerver, menedzselt szerver vagy tárhelycsomag, valamint a tárhelyszolgáltató
- A
php -veredménye és, ha ismert, az üzemmód (PHP-FPM, mod_php, LiteSpeed) - A PHP-frissítés időpontja, ha már telepítették
- Hozzáférés a szerverhez, vagy engedély arra, hogy beszéljünk a tárhelyszolgáltatójával
- Olyan kapcsolattartó, aki dönthet a leállításról és az újraindításokról
Miért a PHP SOS
A munkánk Made in Germany, és a kiberbiztonsági szakemberekből álló partnerhálózatunkkal több mint 25 éve az informatikai biztonságra szakosodtunk. Önnek egyetlen kapcsolattartója van, aki az első üzenettől a lezárásig kíséri. Minden, amit teszünk, dokumentált, hogy a vezetés, a biztosító és a hatóságok felé igazolni tudja. Nem ígérünk olyat, amit senki sem tarthat be: ha hiányoznak a naplók, azt nyíltan megmondjuk, és megnevezzük, mi bizonyított, és mi marad feltételezés.
Érintett? Hívjon minket. Segítünk.
Ne várjon, amíg a gyanú bizonyossággá válik. Hívjon minket, vagy írjon WhatsAppon. Az első üzenettől átvesszük az ügyet, és addig maradunk, amíg az incidens le nem zárul, és dokumentált nem lesz. Vészhelyzet bejelentése most.
Gyakori kérdések
Elég frissíteni a PHP-t, ha a szerveremet esetleg már feltörték?
Nem. A frissítés lezárja a rést, de nem távolítja el a már bejuttatott kártékony szoftvert, és nem bizonyítja, hogy korábban nem történt semmi. A javítás után a szervert meg kell vizsgálni, nincsenek-e rajta a behatolás nyomai.
Hogyan ismerhető fel egy sikeres PHP2Shell-támadás?
Nincsenek közzétett, megerősített Indicators of Compromise. A felismerés a viselkedésen alapul: shellt indító webszerver-folyamatok, új PHP-fájlok a feltöltési vagy gyorsítótár-mappákban, ismeretlen cron-feladatok vagy SSH-kulcsok, valamint feltűnő kimenő kapcsolatok.
Le kell választanom a szervert a hálózatról, ha behatolást gyanítok?
Gyakran ez a helyes lépés, hiszen a BSI még akkor is azt javasolja, hogy a webszervert átmenetileg le kell választani a hálózatról, ha a frissítés nem lehetséges azonnal. Fontos, hogy közben semmit se töröljön, és őrizze meg a naplókat és a fájlokat, hogy az incidens kivizsgálható legyen.
Egy PHP2Shell-támadás után értesítenem kell az adatvédelmi hatóságot?
Ha személyes adatok is érintettek lehetnek, 72 órán belüli bejelentés válhat szükségessé. A döntést az adatvédelmi felelőssel vagy egy ügyvéddel együtt hozza meg; ehhez mi a műszaki tényeket szolgáltatjuk.
Valóban törtek már fel szervereket a PHP2Shell-en keresztül?
Médiabeszámolók szerint 2026. október 17-től voltak az első megfigyelt támadási kísérletek, és a Cloudflare is beszámolt megfigyelt támadási kísérletekről. A BSI kezdetben nem jelentett széles körben megerősített, sikeres támadásokat. Egyedi esetben ez csak magán a szerveren tisztázható.