Röviden: Aki a PHP2Shell PHP-rést még ma le akarja záratni, négy dologra van szüksége: a megfelelő frissítésre, az összes PHP-folyamat újraindítására, a már bejuttatott kártékony kód ellenőrzésére és egy igazolásra. Érintett? Hívjon minket. Segítünk. Ezt távolról, az első üzenettől átvesszük.
Most ne töröljön semmit, és ne telepítsen újra semmit. A javításnál is érvényes: először mentés, aztán módosítás. Ha már bejutott valami, szükségünk van a fájlok és a naplók állapotára. Vészhelyzet bejelentése, és Önnel együtt tisztázzuk a sorrendet.
Miért nem várhat a rés
A két rés, a CVE-2026-109618 és a CVE-2026-109619 magában a PHP-ban van, és bejelentkezés nélkül, távolról teszi lehetővé kártékony kód futtatását. A BSI kihirdette a 3. riasztási szintet (narancs), és azonnali frissítést javasol. Ha ez nem azonnal lehetséges, a webszervereket átmenetileg le kell választani a hálózatról. Médiabeszámolók szerint már a javítások 2026. október 21-i közzététele előtt voltak az első megfigyelt támadási kísérletek. A Cloudflare megfigyelt kísérleteket, és védelmi szabályokat vezetett be, de figyelmeztet, hogy a pusztán a kérésadatok alapján felállított szabályok nem elegendők.
Fontos az üzemeltetőknek: egy CMS-frissítés nem zárja le a PHP-rést. Beszámolók szerint a WordPress.org sem tervez ellene frissítést, mert a rés az értelmezőben van. Csak a PHP szintjén zárható le, vagyis azon, amit a szerver ténylegesen végrehajt.
Mit tegyen azonnal
- Ismerje a célverziót. Javított a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A PHP 8.2 2026. december 31-én éri el a támogatás végét, ezt számolja bele a tervbe.
- Vegye számba az összes rendszert. A tesztszervereket, a konténer-image-eket és az internetről elérhető régi rendszereket is.
- Tisztázza a felelősséget. Tárhelycsomagoknál és menedzselt szervereknél a szolgáltató telepít. Írásban kérdezze meg a verziót és az újraindítást.
- Őrizze meg a naplókat. 2026. október 20-tól, a szakmai sajtó szerint.
- Egyeztessen időablakot. Az újraindítás rövid időre megszakítja a folyamatban lévő kéréseket. Határozzon meg egy időpontot, amikor valaki döntéseket tud hozni.
- Ne várjon, ha nyitva van. Ha nem lehet azonnal javítani, velünk együtt vizsgálja meg az elszigetelést vagy az átmeneti intézkedéseket.
Hogyan segít konkrétan a PHP SOS?
- Helyzetfelmérés: Felmérjük a rendszereket, a PHP-verziókat, az üzemmódokat, a tárhelyszolgáltatókat és az elérhetőséget, és meghatározzuk a sorrendet: először a legjobban kitett rendszerek.
- Mentés és lezárás: Mentjük a pillanatnyi állapotot, telepítjük a frissítést, vagy a tárhelyet az igazoltan javított állapotra hozzuk, és újraindítjuk az összes folyamatot. Konténereknél újraépítjük az image-et, és kihelyezzük.
- Vizsgálat és tisztítás: Mivel a javítás nem távolítja el a kártékony kódot, megvizsgáljuk, vannak-e egy korábbi behatolás jelei, és szükség esetén megtisztítunk.
- Keményítés és jelentés: Rendszerenként írásos igazolást és ajánlásokat kap, hogy a következő frissítés gyorsabban menjen. A szolgáltatási kört a PHP-javítási szolgáltatás írja le.
Frissítés, újraindítás, igazolás: mi számít
A leggyakoribb hiba a frissítés újraindítás nélkül. Amíg régi folyamatok futnak a memóriában, a sebezhető kód aktív marad, még ha a fájlok újak is. Az útmutató az A PHP-FPM és az összes worker újraindítása oldalon áll. A második hiba az, ha hiszünk a kijelzésnek: a disztribúciók és a tárhelyszolgáltatók gyakran backportokat szállítanak, és ilyenkor a verziószám ugyanaz marad. Megbízható a csomag changelogja a CVE-számokkal, a Debian-családban az apt-get changelog <paket> paranccsal.
Ezenkívül a PHP-kézikönyv szerint a biztonsági kiadások óta az új memory_hard_limit_percent direktíva érvényes. Ha egy PHP-verzió nem ismeri, érintett. A teszt rövid:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Verziónként és üzemmódonként le kell futtatni, mert a parancssor más PHP-verziót használhat, mint a webszerver. Végül rögzítjük az eredményt, hogy megmutathassa a tárhelyszolgáltatójának, a biztosítójának vagy a megrendelőjének.
Ha a frissítés nem lehetséges azonnal
Vannak okok, amiért a frissítés ma nem megy: egy régi alkalmazás, amely újabb PHP-verziókon nem fut, egy tárhelyszolgáltató jóváhagyás nélkül, egy konténer-image egy rögzített pipeline-ban. Ezekre az esetekre a php.net átmeneti intézkedéseket nevez meg, amelyek kifejezetten nem jelentenek teljes védelmet: a memory_limit=-1 beállítása úgy, hogy az alkalmazások ne írhassák felül, a post_max_size korlátozása, a session.upload_progress.enabled=0, valamint PHP 8.5-ön a fatal_error_backtraces=0, mindegyik újraindítással. Ehhez jönnek a peremen lévő védelmi szabályok, amelyek nem pótolják a frissítést. Egy keringő tanácsot, amely szerint az összes PHPSESSID-t tartalmazó kérést blokkolni kell, a szakírók kifejezetten elutasítják.
Hogy mely intézkedések illenek az Ön rendszeréhez, és mit törhetnek el, azt előtte megbeszéljük. Többet erről a Azonnali intézkedések, ha még nem tud javítani oldalon és a WAF és virtuális javítás témánál olvashat. A PHP 8.1-re és a régebbiekre külön helyzet érvényes, amelyet a PHP 8.1 és régebbi: mi érvényes most oldal ír le.
Mit érdemes elküldenie nekünk
- A szerverek és tárhelyszolgáltatók listája, amennyiben van
- A
php -vkimenete rendszerenként és az üzemmódra vonatkozó megjegyzés - Annak megadása, hogy konténer, Plesk, cPanel vagy menedzselt ajánlat van-e használatban
- Kívánt időablak és kapcsolattartó az újraindításokhoz
- Megjegyzések a 2026. október 17. óta észlelt feltűnő jelenségekrő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. Egy kapcsolattartója van, aki kíséri a frissítést, ellenőrzi az újraindítást, és átadja az igazolást. Távolról dolgozunk, kiszállás nélkül, és minden lépést dokumentálunk. Nem ígérünk csodákat: a javítás lezárja a rést, de nem bizonyítja, hogy korábban nem történt semmi, és ezt így is mondjuk meg Önnek.
Érintett? Hívjon minket. Segítünk.
Ne hagyja tovább nyitva a rést. 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
Lezárhatom magam a PHP-sebezhetőséget, vagy segítségre van szükségem?
A frissítés egy rendszergazdának megoldható, de hibára hajlamos: annak a verziónak kell érvényesnek lennie, amelyik ténylegesen kiszolgál, és az összes folyamatnak újra kell indulnia. Aki több szerverrel, konténer-image-ekkel vagy sajátosságokkal rendelkező tárhelyszolgáltatóval dolgozik, támogatással időt és hibákat spórol.
Újra kell indítani a PHP-t a frissítés után?
Igen. Az új fájlok önmagukban nem elegendők, amíg régi PHP-folyamatok futnak a memóriában. Az összes workert, illetve folyamatot újra kell indítani, mod_php esetén a webszervert.
Mit tegyek, ha még nincs frissítés a PHP-verziómhoz?
A PHP 8.1-hez és a régebbiekhez a PHP-projekt már nem ad hivatalos frissítést. Ilyenkor a szolgáltató igazoltan javított backportja, a migráció egy karbantartott verzióra, vagy átmeneti intézkedések szükségesek, amelyek azonban nem nyújtanak teljes védelmet.
Elég a session.upload_progress.enabled beállítást 0-ra állítani?
Nem. A szakmai beszámolók szerint a beállítás önmagában nem zárja le mindkét rést, a PHP-frissítés kötelező marad. Csak a php.ini-ben, az FPM-poolban vagy a szerverkonfigurációban állítsa be, ne az ini_set()-tel vagy a .user.ini-ben.
Honnan tudom, hogy a rés utána tényleg le van zárva?
A futó rendszeren végzett igazolásból: verzió vagy a csomag changelogja, a memory_hard_limit_percent új direktívára végzett teszt, és annak megerősítése, hogy a frissítés után az összes folyamat újraindult.