Röviden: Ha problémái vannak a PHP-szerverével, és közvetlenül szakértővel szeretne beszélni, hívjon minket, vagy írjon WhatsAppon. Érintett? Hívjon minket. Segítünk. Távolról tisztázzuk, hogy kiesés, hibás konfiguráció vagy támadás áll-e a háttérben, és az első üzenettől átvesszük az ügyet, amíg az incidens le nem zárul, és dokumentált nem lesz.
Most ne töröljön semmit, és ne telepítsen újra semmit. Az újraindítás vagy a visszaállítás is elmoshatja a nyomokat. Először írja le nekünk, mit lát. Vészhelyzet bejelentése, utána meghatározzuk a következő lépést.
Érintett? Ezek a zavarok ránk tartoznak
Nem minden zavar támadás, de ezekben a napokban érdemes utánanézni. Jelentkezzen, ha a PHP-rendszerénél a következők fordulnak elő:
- A PHP-folyamatok vagy a webszerver megszakadnak, újra meg újra újraindulnak, vagy a rendszer leállítja őket (137-es kilépési állapot).
- A terhelés látható ok nélkül nő, vagy megtelik a memória.
- Az oldalak üres válaszokat, 500-as hibákat vagy korábban nem létező hibaüzeneteket adnak.
- A webszerver vagy a PHP-FPM alatt shellt indító folyamatok futnak.
- A feltöltési vagy gyorsítótár-mappában olyan PHP-fájlok vannak, amelyeket nem ismer.
- Egy PHP-frissítés után egy alkalmazás már nem működik.
- A tárhelyszolgáltatója letiltotta a hozzáférést, vagy lekapcsolta az oldalt.
A kiesés és a támadás közötti különbség többnyire csak a naplókból derül ki. Az első támpontokat arról, mire kell figyelni, a A webszerver shellt indít cikk írja le.
Mit tegyen azonnal
- Figyeljen, mielőtt beavatkozik. Jegyezze fel az időpontot, a hibaüzeneteket és azt, hogy mit módosítottak utoljára (frissítés, bővítmény, konfiguráció).
- Mentse a naplókat. Másolja el a webszerver-, PHP- és rendszernaplókat, mielőtt rotálódnak. A szakmai sajtó azt javasolja, hogy a naplókat 2026. október 20-tól őrizzék meg.
- Ne indítsa újra vakon. Az újraindítás megold néhány kiesést, de elpusztítja a múlékony nyomokat. Indítsa újra, ha az üzem megköveteli, és jegyezze fel, mit tett.
- Mérlegelje az elérhetőséget. Ha támadást gyanít, gyakran helyes az elzárás vagy a lekapcsolás. A BSI ezt javasolja, ha a frissítés nem lehetséges azonnal.
- Állapítsa meg a PHP-verziót. A
php -vmegmutatja a verziót, de nem mindig a webszerver futtatókörnyezetéét. - Hívjon vagy írjon. Minél pontosabban le tudja írni a helyzetet, annál gyorsabban jutunk a lényegig.
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: Az első beszélgetésben meghallgatjuk, és célzottan rákérdezünk: rendszerek, PHP-üzemmód, időpont, utolsó módosítások. Utána tudni fogja, hogy kiesést látunk-e, vagy támadás gyanúját.
- Mentés és lezárás: Mentjük az állapotot, elhárítjuk az okot, és szükség esetén lezárjuk a rést frissítéssel, újraindítással és átmeneti intézkedésekkel.
- Vizsgálat és tisztítás: Ha behatolás derül ki, eltávolítjuk a kártékony kódot, ellenőrizzük a hozzáféréseket és a titkokat. Egyébként dokumentáljuk az okot, és rendben tartjuk az üzemet.
- Keményítés és jelentés: Rövid jelentést és ajánlásokat kap, hogy a zavar ne ismétlődjön.
Ha többről van szó, átlépünk a Feltört weboldal vészhelyzeti segítségébe vagy a strukturált Incident Response eljárásba.
Memória, megszakadások és az új korlát
A 2026. október 21-i biztonsági kiadások (8.5.12, 8.4.27, 8.3.36, 8.2.35) óta létezik a memory_hard_limit_percent direktíva. Azóta a memory_limit puha határ. Saját beállítás nélkül kemény határként a memory_limit kétszerese érvényes 1G-ig, afölött a memory_limit plusz 1G. Ha túllépik, a folyamat azonnal 137-es kilépési állapottal ér véget. Egy üzem, amely a frissítés előtt a korlát közelében futott, ezáltal hirtelen megszakadásokat mutathat. Ez nem támadás, hanem a javítás következménye, és a megoldás az alkalmazás vagy a korlát rendezett hozzáigazítása, nem a frissítés visszavonása.
Fordítva is igaz: aki összeomlott folyamatokat lát, és még nem javított, ne tekintse ezt véletlennek, mert a CVE-2026-109618 rés Out-of-Memory állapottal függ össze. Hogy ez az Ön esetében szerepet játszik-e, azt a naplók mutatják. A memóriakezelés hátterét az Out-of-Memory a PHP-ban oldalon találja, a lehetséges behatolási jeleket pedig a Gyanús folyamatok Linuxon oldalon.
Ha a tárhelyszolgáltató közbelép
Egyes szolgáltatók letiltják a fiókokat, vagy elővigyázatosságból offline-ra teszik az oldalakat. Ez nem jelenti automatikusan, hogy feltörték, de feltűnő jelenségek következménye lehet. Kérdezze meg az okot és az időpontot, kérje a naplókat, és jegyezze fel, mit kér a szolgáltató. Egyeztetünk a tárhelyszolgáltatójával, ha ezt kívánja. Érdemes előre tisztázni, hogy a szolgáltatónál ki hozhat döntéseket, és hogy vannak-e ott olyan szervernaplók, amelyeket Ön maga nem láthat. Az ilyen adatok, például a hálózati szintű hozzáférések, később döntőek lehetnek, ha egy lehetséges behatolás időpontját kell leszűkíteni.
Mit érdemes elküldenie nekünk
- rövid leírás: mi esett ki vagy tűnt fel, mióta?
- a rendszer típusa (saját szerver, tárhelycsomag, konténer) és a tárhelyszolgáltató
- a
php -vkimenete, az üzemmód és a webszerver, amennyiben ismert - hibaüzenetek vagy részletek a naplókból
- az utolsó PHP-frissítés és az utolsó módosítások időpontja
- olyan kapcsolattartó, aki dönthet 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. Állandó kapcsolattartóval beszél, jegykezelő rendszer helyett. Távolról dolgozunk, dokumentáljuk, mit látunk és teszünk, és nyíltan megmondjuk, mi bizonyított és mi nem. A réssel kapcsolatos akut esetekre ott a PHP2Shell azonnali segítség is.
Érintett? Hívjon minket. Segítünk.
Ha a PHP-szervere problémákat okoz, ne várjon a következő kiesésre. Hívjon minket, vagy írjon WhatsAppon. Az első üzenettől átvesszük az ügyet. Vészhelyzet bejelentése most.
Gyakori kérdések
A PHP-szerverem hirtelen lassú lett vagy összeomlik: ez támadás?
Nem feltétlenül. A kieséseknek gyakran banális okai vannak, például kevés memória, egy hibás frissítés vagy túlterhelés. A naplók és a folyamatok áttekintése mutatja meg, hogy támadás-e; figyelmeztető jel például a webszerver alatt futó shell-folyamat vagy az ismeretlen új PHP-fájlok.
Mit jelent a 137-es kilépési állapot a PHP-folyamatoknál?
A 137-es állapot egy azonnal leállított folyamatot jelent. A PHP-kézikönyv szerint egy folyamat 137-tel ér véget, ha túllépi az új memory_hard_limit_percent direktíva kemény memóriahatárát; de a rendszer memóriahiány miatt is leállíthatta. Az okot a naplók áttekintése tisztázza.
Beszélhetek telefonon egy szakértővel, mielőtt bármit megváltoztatnék?
Igen, pontosan erre való a vészhelyzeti segítség. Hívjon minket, vagy írjon WhatsAppon, és írja le, mi tűnt fel. Megmondjuk, mit hagyjon békén, és mit tehet kockázat nélkül.
Egyszerűen újra kell indítanom a PHP-szolgáltatást?
Az újraindítás megszüntethet egy kiesést, de törli a memóriában lévő nyomokat. Ha behatolás lehetséges, előtte mentse a naplókat, és kérjen tanácsot. Egy PHP-frissítés után ezzel szemben az újraindítás kötelező.
Dolgoznak akkor is, ha a szerverem egy tárhelyszolgáltatónál van?
Igen, távolról dolgozunk azzal a hozzáféréssel, amellyel Ön rendelkezik, és szükség esetén egyeztetünk a tárhelyszolgáltatójával. Hogy milyen vizsgálatok lehetségesek, az az Ön jogosultságaitól függ.