Röviden: Hogy érinti-e Önt a PHP2Shell, három dologtól függ: a PHP-verziótól, az üzemmódtól, és attól, hogy történt-e javítás, és hogyan. Ha bizonytalan, jelentkezzen most. Érintett? Hívjon minket. Segítünk. Távolról, magán a szerveren tisztázzuk, nem érzés alapján, és lezárjuk a rést, ha nyitva van.
Most ne töröljön semmit, és ne telepítsen újra semmit. Akkor is, ha csak azt szeretné tisztázni, érintett-e: ha a szervert esetleg már megtámadták, a fájlokra és a naplókra változatlan állapotban van szükségünk. Vészhelyzet bejelentése, és közösen végigmegyünk az ellenőrzésen.
Érintett? Ezeket az eseteket kell felvenni az ellenőrzőlistára
A PHP2Shell két kritikus rést jelent magában a PHP-ban (CVE-2026-109618 és CVE-2026-109619, mindkettő a CVSS v4.0 szerinti legmagasabb, 9,2 értékű minősítéssel). Bejelentkezés nélkül, távolról teszik lehetővé kártékony kód futtatását. Minden üzemmód érintett lehet: PHP-FPM, Apache mod_php-vel, php-cgi, FrankenPHP és LiteSpeed. Vizsgálja meg mindegyik rendszert:
- saját szerverek, vServerek és root szerverek PHP-val
- tárhelycsomagok és menedzselt szerverek, akkor is, ha nincs hozzáférése a konfigurációhoz
- konténerek és platformszolgáltatások, amelyek PHP-image-et hoznak magukkal
- tesztrendszerek, staging környezetek és elfeledett régi rendszerek, amelyek az internetről elérhetők
- NAS-ok, appliance-ek vagy szolgáltatók szoftverei, amelyek belül PHP-t használnak
Éppen az elfeledett rendszerek jelentik a kockázatot. A Unit 42 szerint több mint 22,6 millió nyilvánosan elérhető, potenciálisan sebezhető példány létezik, a BSI pedig gyors, nagy léptékű kihasználással számolt.
Mit tegyen azonnal
- Készítsen leltárt. Írja fel az összes szervert, domaint és tárhelyszerződést, amelyen PHP fut, és azt, hogy ki felel értük.
- Állapítsa meg a PHP-verziót rendszerenként. Szervereken a
php -vparanccsal. Vegye figyelembe, hogy a parancssor más verziót használhat, mint a webszerver. - Tisztázza az üzemmódot. A PHP PHP-FPM-ként, mod_php-ként vagy LiteSpeeden keresztül fut? A mod_php esetében a PHP-csapat a legmagasabbra értékeli a kockázatot.
- Kérdezze meg a tárhelyszolgáltatót és a szolgáltatókat. Írásban: melyik verzió fut, telepítették-e a javítást, újraindították-e az összes folyamatot?
- Őrizze meg a naplókat. A szakmai sajtó azt javasolja, hogy a naplókat 2026. október 20-tól őrizzék meg.
- Ne várjon sokáig. Ha egy rendszer nyitva van, és a javítás nem lehetséges azonnal, a BSI azt javasolja, hogy a webszervert átmenetileg le kell választani a hálózatról.
Hogyan segít konkrétan a PHP SOS?
Az érintettséget távolról és igazolásokkal tisztázzuk.
- Helyzetfelmérés: Elmondatjuk Önnel a leltárát, és a rendszereket elérhetőség és kockázat szerint rendezzük.
- Mentés és lezárás: Ahol nyitva van, először mentjük az állapotot, majd a rést frissítéssel és újraindítással zárjuk le. Ahol ez nem megy azonnal, átmeneti intézkedéseket állítunk be, amelyek nem jelentenek teljes védelmet.
- Vizsgálat és tisztítás: Megvizsgáljuk, hogy a rést kihasználták-e a javítás előtt, és szükség esetén megtisztítjuk a rendszert. Hogy egy szerver érintett-e, és esetleg már megtámadták-e, azt világosan elválasztjuk.
- Keményítés és jelentés: Rendszerenkénti listát kap: verzió, üzemmód, a javítás igazolása, nyitott pontok.
Hogyan igazolható az érintettség
Egy verziószám önmagában nem elég, mert a szolgáltatók visszaportolják a javításokat. Az Ubuntu 24.04 például beszámolók szerint a frissítés után is továbbra is a 8.3.6-ot mutatja. Három út megbízható:
| Út | Mit mutat | Korlát |
|---|---|---|
| A verzió összevetése a javított állapotokkal | a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35, illetve magasabb javított | csak az eredeti verziókra érvényes, a backportokra nem |
Teszt a memory_hard_limit_percent direktívára |
a bool(false) azt jelenti: a direktíva ismeretlen, tehát érintett |
verziónként és üzemmódonként külön kell lefuttatni |
| A csomag changelogjának átkutatása CVE-számokra | igazolja a backportokat a disztribúcióknál | a forrás a szolgáltató biztonsági archívuma |
A teszt így néz ki:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Hogyan ellenőrizheti tisztán a verziót és a javítási állapotot, azt a PHP-verzió és javítási állapot helyes ellenőrzése oldalon találja. Az ágak áttekintését a Mely PHP-verziókat érinti? oldal adja. Hogy a kijelzés javítás ellenére miért tűnhet régebbinek, azt a A php -v régi számot mutat cikk magyarázza.
Érintett és már nem javítható: PHP 8.1 és régebbi
A PHP 8.1-hez és a régebbiekhez a PHP-projekt már nem ad hivatalos frissítést, csak minimális forráskód-backportokat a 7.4, 8.0 és 8.1 verzióhoz. Aki ilyen verziót használ, annak többnyire két útja van: egy igazolt backportot kínáló szolgáltató, vagy a migráció egy karbantartott verzióra. Léteznek kereskedelmi hosszú távú támogatási ajánlatok, de hogy fedik-e a PHP2Shellt, és mikortól, azt a szolgáltatónak írásban kell megerősítenie. Segítünk a besorolásban a PHP 8.1 és régebbi: mi érvényes most oldalon, és a megvalósításban a PHP-javítási szolgáltatásban.
Mit érdemes elküldenie nekünk
- A szerverek, domainek és tárhelyszolgáltatók listája
- A PHP-verzió rendszerenként, amennyiben ismert
- Az üzemmód és a webszerver, amennyiben ismert
- Annak megadása, hogy előtte van-e Cloudflare vagy más védelem, és hogy az origin szerver közvetlenül elérhető-e
- A tárhelyszolgáltató válaszai, ha már megkérdezte
- Olyan kapcsolattartó, aki jóváhagyásokat és újraindításokat engedélyezhet
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ót kap, aki végigmegy a leltárán, és minden állítást igazol, ahelyett hogy csak verziószámokat olvasna le. Távolról dolgozunk, kiszállás nélkül, és dokumentáljuk, mit vizsgáltunk meg. Az olyan kijelentést, mint a „biztonságos”, csak annyiban tesszük meg, amennyire igazolható. Nagyobb környezetekhez a PHP2Shell azonnali segítség jöhet szóba.
Érintett? Hívjon minket. Segítünk.
Ha nem tudja, érintett-e, az elég ok arra, hogy most jelentkezzen. Hívjon minket, vagy írjon WhatsAppon. Az első üzenettől átvesszük az ügyet, és Önnel együtt tisztázzuk a szerveren. Vészhelyzet bejelentése most.
Gyakori kérdések
Érint a PHP2Shell, ha csak WordPresst vagy webshopot használok?
Lehetséges, hogy igen. A rések a PHP-ban vannak, nem a CMS-ben. Az dönt, hogy Önnél tényleg melyik PHP-verzió és üzemmód szolgálja ki az oldalt; egy WordPress-frissítés ezen nem változtat.
Elég a verziószám ahhoz, hogy tudjam, javítva van-e a rendszerem?
Nem mindig. A disztribúciók és a tárhelyszolgáltatók a javításokat részben backportként telepítik, és ilyenkor a szám ugyanaz marad. Megbízható a csomag changelogja a CVE-számokkal, vagy a szolgáltató írásos megerősítése.
Van gyors teszt arra, hogy a PHP-verziómban benne van-e a javítás?
A PHP-kézikönyv szerint érintett az a verzió, amely nem ismeri a memory_hard_limit_percent direktívát. A tesztet minden PHP-verzióra és üzemmódra külön kell lefuttatni, mert a parancssor más verziót használhat, mint a webszerver.
Érintettek a régebbi PHP-verziók, például a 7.4 vagy a 8.0 is?
A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg. A 8.1-hez és a régebbiekhez a PHP-projekt már nem ad hivatalos frissítést, csak minimális forráskód-backportokat. Hogy egy szolgáltató telepítette-e ezeket, azt neki kell megerősítenie.
Véd a Cloudflare, ha érintett vagyok?
Részben. A Cloudflare védelmi szabályokat vezetett be, de maga is figyelmeztet, hogy ezek nem pótolják a frissítést. Ha az origin szerver közvetlenül elérhető, a védelmet megkerülik.