Röviden: A PHP2Shell két kritikus rés magában a PHP-ban, amelyeken keresztül a támadók bejelentkezés nélkül futtathatnak kártékony kódot. Ha gyorsan segítségre van szüksége ennél a PHP-sebezhetőségnél, távolról átvesszük az állapotfelmérést, a javítást vagy egy átmeneti intézkedést, az összes PHP-folyamat újraindítását és egy első nyomkeresést. A végén írásos igazolást kap az állapotról.
Segítség a PHP-sebezhetőségnél: miért kell most cselekedni
-
- 21-én, német idő szerint 16 órakor a PHP-projekt közzétette a CVE-2026-109618 és a CVE-2026-109619 javításait. Mindkét rést CVSS v4.0 9,2 értékkel minősítették, és lehetővé teszik kártékony kód távoli futtatását anélkül, hogy bárkinek be kellene jelentkeznie. Az elterjedt üzemmódok érintettek: PHP-FPM, Apache mod_php-val, php-cgi, FrankenPHP és LiteSpeed.
A BSI a 3. riasztási szintet (narancs) hirdette ki. Azonnali frissítést ajánl, és ha az nem megy azonnal, a webszerverek átmeneti levételét a hálózatról. A Palo Alto Networks (Unit 42) több mint 22,6 millió kitett, potenciálisan sebezhető példányt számolt össze. A BSI szerint kezdetben nem volt ismert széles körben megerősített sikeres támadás, a Cloudflare azonban már támadási kísérletekről számolt be.
A vezetés és a tulajdonosok számára ez azt jelenti: minden nyilvánosan elérhető PHP-szerver gyanús, amíg az ellenkezője be nem bizonyosodik. A résről érthető magyarázatot talál a Mi az a PHP2Shell? oldalon.
Kinek szól a PHP2Shell azonnali segítség?
Azoknak a vállalkozásoknak, ügynökségeknek és közintézményeknek, amelyek PHP-alkalmazásokat üzemeltetnek, és a helyzetet egyedül nem tudják vagy nem akarják a szükséges mélységben feldolgozni. Ez érinti a saját root szervereket és vServereket éppúgy, mint a Plesk vagy cPanel szervereket, a konténeres környezeteket és azokat a menedzselt szervereket, ahol a felelősség nem tisztázott.
Tárhelyszolgáltatóval rendelkezőknek is gyakran van szükségük támogatásra. Sok szolgáltató backportokat telepít; ilyenkor a Plesk például továbbra is 8.2.34-et mutat, noha a csomagállapot javított. Fordítva, új verziószám is megjelenhet, miközben a régi PHP-folyamatok még a memóriában futnak. Hogy mely állapotok számítanak javítottnak, azt a Mely PHP-verziókat érinti? oldal sorolja fel.
Hogyan segít konkrétan a PHP SOS?
- Állapotfelmérés: Felmérjük a szervereiken lévő összes PHP-telepítést, üzemmódot és verziót, a csomagállapotot és a futó folyamatokat is beleértve. Az eredmény egy lista arról, mely rendszerek érintettek, javítottak vagy tisztázatlanok.
- Javítás vagy átmeneti intézkedés: Ahol lehet, telepítjük a javított verziókat (8.5.12, 8.4.27, 8.3.36, 8.2.35) vagy a disztribúciója csomagjait. Ha ez nem megy azonnal, végrehajtjuk a php.net szerinti átmeneti intézkedéseket, és nyíltan megmondjuk, hogy azok nem nyújtanak teljes védelmet.
- Újraindítás és ellenőrzés: Újraindítjuk az összes PHP-workert és -folyamatot, majd ellenőrizzük, hogy nem fut-e még régi folyamat. Az új fájlok önmagukban nem zárják le a rést.
- Első nyomkeresés: Mentjük a szervernaplókat 10. 20-tól, és olyan feltűnő jeleket keresünk, mint új PHP-fájlok, ismeretlen cron-feladatok vagy szokatlan folyamatok. Mivel nincsenek közzétett, megerősített Indicators of Compromise, ez az ellenőrzés viselkedéselemzésen alapul.
- Igazolás és következő lépések: Írásos jelentést kap. Feltört rendszer gyanúja esetén javasoljuk a megfelelő folytatást, például a kártevő-eltávolítást vagy egy forenzikai vizsgálatot.
A javítás 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. Ezért az azonnali segítséghez mindig hozzátartozik a 2026. 10. 17. óta eltelt időszak áttekintése.
Mit kap tőlünk
- áttekintés az összes ellenőrzött szerverről a PHP-verzióval, csomagállapottal, üzemmóddal és javítási állapottal
- a telepített frissítések vagy a beállított átmeneti intézkedések dokumentációja
- igazolás arról, hogy minden PHP-folyamatot újraindítottak
- a nyomkeresés értékelése, megkülönböztetve a bizonyítottat, a valószínűt és az ismeretlent
- a nyitott pontok listája, például a PHP 8.1-es vagy régebbi verziót futtató rendszerek
Ezt a jelentést továbbadhatja a vezetésnek, az adatvédelmi felelősöknek vagy a biztosítónak. Jogi értékelést nem helyettesít.
Mire van szükségünk Öntől
- Hozzáférés: SSH- vagy panel-hozzáférés megfelelő jogokkal, vagy alternatívaként az Ön hozzájárulása ahhoz, hogy a tárhelyszolgáltatója tájékoztatást adjon nekünk
- Kapcsolattartó: egy személy, aki döntéseket hozhat, például egy rövid offline üzemről vagy egy újraindításról
- Áttekintés: mely weboldalak, webshopok és alkalmazások futnak mely szervereken
- Karbantartási időablak: az Ön előírásai arról, mikor végezhetők újraindítások
- Mentések: tájékoztatás arról, hol vannak az aktuális mentések
Azoknak az adminisztrátoroknak, akik előzetesen maguk szeretnének ellenőrizni, gyakran elég ez a veszélytelen pillantás az állapotra:
php -v
# Debian/Ubuntu: telepített PHP-csomagok verzióval
dpkg -l | grep -i php
# futó PHP-folyamatok és indulási idejük
ps -eo pid,lstart,cmd | grep -i php
Amit nem ígérünk
Nem ígérünk abszolút biztonságot, és nem állítjuk, hogy a szervert soha nem támadták meg, ha a bizonyítékok ezt nem támasztják alá. Addig dolgozunk az incidensen, amíg le nem zárul és dokumentálva nincs. Hogy a GDPR szerinti bejelentési kötelezettség fennáll-e, vagy értesítenie kell-e a biztosítóját, azt kérjük, tisztázza az adatvédelmi felelőssel, ügyvéddel vagy a biztosítóval. Ehhez mi szolgáltatjuk a technikai tényeket. Ez nem jogi tanácsadás.
Ha csak a frissítésre van szüksége igazolással, hozzá a PHP-javítási szolgáltatásunk illik. Ha már vannak támadásra utaló jelek, a feltört weboldal esetén nyújtott vészhelyzeti segítség a megfelelő kiindulópont.
Gyakori kérdések
Elég, ha a tárhelyszolgáltatóm frissítette a PHP-t?
Elég lehet, ha a tárhelyszolgáltató írásban megerősíti a csomagállapotot, és minden PHP-folyamatot újraindítottak. A kijelzett verziószám önmagában nem bizonyíték, mert a disztribúciók backportokat telepítenek. Azt pedig, hogy a szervert korábban megtámadták-e, a javítás úgysem dönti el.
Offline kell-e lennie a weboldalamnak az azonnali segítség idejére?
Nem feltétlenül. A BSI (a német Szövetségi Információbiztonsági Hivatal) azt ajánlja, hogy a webszervereket átmenetileg vegyék le a hálózatról, ha a frissítés nem lehetséges azonnal. Hogy ez Önnél szükséges-e, az állapotfelmérés után közösen döntjük el.
Véd-e a WordPress- vagy Shopware-frissítés a PHP2Shell ellen?
Nem. A PHP2Shell magában a PHP-ban van, nem a CMS-ben. A CMS-frissítés továbbra is hasznos, de ezt a rést nem zárja le.
Mi a helyzet a PHP 8.1 vagy régebbi verziókkal?
Ezekhez a verziókhoz a PHP-projekttől már nincs hivatalos frissítés, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz. A szervert átmenetileg biztosítjuk, és Önnel együtt megtervezzük az átállást egy támogatott verzióra.