# PHP2Shell: mi igazolt és mi nem

> PHP2Shell tényellenőrzés: mit igazol a php.net, a BSI és a gyártók, mi származik csak beszámolókból, és mely híresztelésekkel nem kell foglalkoznia.

Forrás: https://phpsos.de/hu/blog/php2shell-was-belegt-ist/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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?](https://phpsos.de/hu/php2shell/was-ist-php2shell/) oldal magyarázza.

## Melyik forrásnak mekkora a súlya

Egy egyszerű rangsor segít minden közlemény olvasásánál:

1. **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](https://phpsos.de/hu/php/php-sicherheitsprozess/) szóló írásunk mutatja be.
2. **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.
3. **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.
4. **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.
5. **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.

> **Fontos:**
> 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.

1. **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.
2. **Indítsa újra az összes PHP-folyamatot:** Az új fájlok csak akkor hatnak, ha már nem fut régi folyamat.
3. **Mentse a naplókat október 20-tól:** A szaksajtó ezt javasolja, hogy a későbbi vizsgálat lehetséges maradjon.
4. **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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal végigvezeti az ellenőrzésen.
5. **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](https://phpsos.de/hu/blog/gefaehrliche-falschtipps/) í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](https://phpsos.de/hu/leistungen/php2shell-soforthilfe/) í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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)