Röviden: A PHP2Shell igazolt tényei közé tartozik a két CVE-szám, a CVSS v4.0 szerinti 9,2-es értékelés, a javított PHP-verziók és a php.net átmeneti intézkedései. Szintén igazolt a BSI narancs riasztási szintje. Nem igazolt a CVSS 10-es értékelés, a széles körben megerősített sikeres támadások és a felismerési jegyek listája. Aki szétválasztja ezt a három szintet, jobb döntéseket hoz.
Miért van szükség tényellenőrzésre a PHP2Shellről
Az utóbbi évek biztonsági rései közül alig volt olyan, amelyik ilyen gyorsan ennyi főcímet generált. Még mielőtt a PHP-csapat 2026. október 21-én közzétette a frissítéseket, beszámolók szerint fórumbejegyzések, képernyőképek és állítólagos részletek keringtek. Ezután hatósági figyelmeztetések, gyártói blogok, a kitett szerverek összeszámlálása és a tanácsok áradata következett.
Az üzemeltetők számára ez azt jelenti: nem minden szám és nem minden tanács azonos minőségű. Egy részük elsődleges forrásból származik, egy részük megbízható tudósításból, egy részük találgatás. Ez a cikk rendszerezi, mit használhat biztos alapként a döntéseihez. Magának a résnek az alapjait a Mi a PHP2Shell? oldal magyarázza.
Melyik forrásnak mekkora a súlya
Egy egyszerű rangsor segít minden közlemény olvasásánál:
- php.net: A PHP-projekt az elsődleges forrás a CVE-számokhoz, az értékelésekhez, az érintett üzemmódokhoz, a javított verziókhoz és az átmeneti intézkedésekhez. Hogyan kezeli a projekt alapvetően a biztonsági közleményeket, azt a PHP biztonsági folyamatról szóló írásunk mutatja be.
- Hatóságok: A BSI (a német szövetségi információbiztonsági hivatal) adja a németországi helyzet besorolását és a cselekvési javaslatokat, a CERT-EU és a CERT-Bund (a német kormányzati CERT) kiegészíti ezeket.
- Disztribúciók és szolgáltatók: A Debian, az Ubuntu, a Red Hat, a tárhelyszolgáltatók és a platformszolgáltatások kötelező érvénnyel csak a saját csomagjaikról és szolgáltatásaikról mondanak valamit.
- Biztonsági cégek: A Cloudflare, a Unit 42, a CybelAngel és mások saját méréseikből számolnak be. Értékes, de mindegyik saját módszerrel készül.
- Média és közösségi hálózatok: Jók a gyorsaságra, gyengék a részletekben. Az innen származó állításokhoz feljebb lévő megerősítés kell.
Igazolt, beszámolókból származó, nem igazolt: az áttekintés
Az alábbi táblázat a leggyakoribb állításokat sorolja be. Az „igazolt” elsődleges forrást vagy hatóságot jelent. A „beszámolók szerint” médiából vagy gyártói közlésekből származik, függetlenül nem megerősítve.
| Állítás | Besorolás | Alap |
|---|---|---|
| Két rés, CVE-2026-109618 és CVE-2026-109619 | igazolt | php.net |
| CVSS v4.0 szerinti 9,2-es értékelés, kritikus | igazolt | php.net |
| CVSS 10-es értékelés | tarthatatlan | beszámolók szerint a közlemény előtti fórumbejegyzésből |
| Javítva: 8.5.12, 8.4.27, 8.3.36, 8.2.35 | igazolt | php.net |
| mod_php a legmagasabb kockázattal, az exploitot az alkalmazáskód előtt mutatták be | igazolt | php.net |
| A PHP 5.4-ig szinte minden verzió érintett | beszámolók szerint | szaksajtó |
| Az első támadási kísérlet október 17-én | beszámolók szerint | médiabeszámolók az Amazonra hivatkozva |
| Több mint 22,6 millió kitett példány | beszámolók szerint | Unit 42, a TechTarget szerint |
| Sikeres támadások széles körben | nem igazolt | a BSI szerint kezdetben nem ismertek |
| Megerősített Indicators of Compromise | nincsenek | nincs közzététel |
| Az átmeneti intézkedések teljesen védenek | hamis | a php.net kifejezetten hiányosnak nevezi őket |
Feltűnő, milyen korán önállósulnak a számok. A fórumbejegyzésből származó 10,0-s értékelés napokkal később is felbukkant cikkekben, pedig a PHP-csapat már régen a 9,2-t tette közzé.
Hol van valójában a bizonytalanság
A legnagyobb nyitott kérdés nem műszaki, hanem időbeli: mi történt az első beszámolók szerinti támadási kísérlet és az egyes szervereken végzett javítás között? Erre nincs általános válasz. A Cloudflare és a Patchstack támadási kísérletekről számolt be, a watchTowr saját közlése szerint reprodukálta a CVE-2026-109618-at. A Huntress viszont a közleménye idején nem látott támadásokat a partnerkörnyezetekben.
Ezek az állítások nem mondanak ellent egymásnak. Különböző szeletet írnak le: egy nagy proxyszolgáltatót, egy bővítmény-biztonsági céget, egy kutatócsapatot és egy saját ügyfélkörrel rendelkező vállalatot. Ebből nem rajzolódik ki teljes kép.
Hasonló a helyzet az érintett verziók kérdésénél. A 8.2-től 8.5-ig a helyzet egyértelmű. A régebbi ágakhoz a 7.4, a 8.0 és a 8.1 esetében minimális forrásszintű backportok léteznek, hivatalos kiadások nem. Ami ezek előtt van, az a szaksajtó szerint szinte teljes egészében érintett. A tervezés szempontjából ez alig számít: a PHP 8.1-es vagy régebbi verziót futtató, megerősített backport nélküli szervert veszélyeztetettként kell kezelni.
A támadásokra utaló bizonyítékok hiánya nem a biztonság bizonyítéka. Mivel nincsenek megerősített felismerési jegyek, egy egyes szerver elleni támadás csak a viselkedés vizsgálatával becsülhető meg, listával nem.
Mit következtethet ebből a szervereire
Az igazolt tényekből néhány világos lépés következik. A nem igazoltakból főleg óvatosság.
- Ellenőrizze a javítási állapotot: javított verzió vagy a szolgáltató által megerősített backport. A kijelzett verziószám önmagában nem elég.
- Indítsa újra az összes PHP-folyamatot: Az új fájlok csak akkor hatnak, ha már nem fut régi folyamat.
- Mentse a naplókat október 20-tól: A szaksajtó ezt javasolja, hogy a későbbi vizsgálat lehetséges maradjon.
- Keressen nyomokat: új PHP-fájlok a feltöltési mappákban, ismeretlen cron-feladatok, shellt indító webszerver-folyamatok. A Feltörték már a rendszeremet? oldal végigvezeti az ellenőrzésen.
- Ellenőrizze a tanácsokat: A fórumokról és közösségi hálózatokról származó tippeket csak akkor hajtsa végre, ha visszavezethetők a php.net-re vagy egy hatóságra. Hogy mely ajánlások ártanak éppen, azt a Veszélyes téves tippek a PHP2Shellről írás gyűjti.
A belső kommunikációban ugyanez a szétválasztás segít. Aki a vezetőségnek külön mutatja be az „igazoltat”, a „beszámolók szerintit” és a „nyitottat”, elkerüli mind a pánikkeltést, mind a téves riadó-lefújást.
Hogyan segít konkrétan a PHP SOS?
- Helyzetkép a rendszereire: Az igazolt tényeket átvisszük az Ön szervereire, és a dokumentációban szétválasztjuk, mi mért, mi beszámolókból származó és mi nyitott.
- Javítás és igazolás: Ellenőrizzük a csomagállapotot és minden PHP-szolgáltatás újraindítását, és ezt írásban rögzítjük.
- Nyomkeresés: Október 20-tól mentjük a naplókat, és viselkedési furcsaságokat keresünk, amíg az incidens le nem zárul és nincs dokumentálva.
- Folyamatos besorolás: Az új közleményeket besoroljuk Önnek, mielőtt azokból intézkedések lennének.
A folyamatot a PHP2Shell azonnali segítség írja le.
Összegzés
A PHP2Shell komoly, és ez jól igazolt. Éppen ezért megéri a józan szemlélet: az elsődleges források minden fontos döntéshez elegendők. Ami ezen túl kering, az gyakran gyorsabb, mint amilyen pontos. Javítani, újraindítani, naplókat menteni és nyomokat keresni marad a válasz, függetlenül attól, hogy éppen melyik szám járja körbe.
Gyakori kérdések
Kapott a PHP2Shell CVSS 10-es értékelést?
Nem. A 10-es szám beszámolók szerint egy fórumbejegyzésből származik, amely a hivatalos közlemény előtt terjedt. A PHP-csapat mindkét résre CVSS v4.0 szerinti 9,2-es értékelést adott. Ez továbbra is a kritikus kategória.
Van lista a PHP2Shell-támadások felismerési jegyeiről?
Eddig nincs. Nincsenek közzétett, megerősített Indicators of Compromise. Aki ellenőrizni szeretné, érintett volt-e egy szerver, a viselkedési furcsaságokra figyeljen, például olyan webszerver-folyamatokra, amelyek shellt indítanak, vagy új PHP-fájlokra a feltöltési mappákban.
Melyik forrás a legmegbízhatóbb a PHP2Shell esetében?
A műszaki tényekhez a php.net közleményei, a németországi helyzetértékeléshez a BSI (a német szövetségi információbiztonsági hivatal). A médiabeszámolók és a gyártói blogok kiegészítik a képet, de beszámolóként kell jelölni őket, és az elsődleges forrás ellenében kell olvasni őket.
Valóban minden PHP-verzió érintett a PHP 5-től kezdve?
A helyzet a 8.2-től 8.5-ig terjedő ágakra igazolt, amelyekhez van frissítés. A szaksajtó szerint a PHP 5.4-ig szinte minden verzió érintett; a CERT-EU beszámolók szerint a PHP 5-től felfelé tartotta lehetségesnek az érintettséget. A régebbi verziókhoz nincsenek hivatalos frissítések, ezért mindenképp veszélyeztetettként kezelje őket.