PHP2Shell: 22,6 millió potenciálisan érintett rendszer? Kinek kell most lépnie

A szám sokkoló – de mit jelent valójában?

A PHP2Shell neve az elmúlt napokban úgy terjedt, mintha minden PHP-s weboldalt már fel is törtek volna. A valóság pontosabb és a védekezés szempontjából hasznosabb: a PHP projekt két kritikus, távoli kódfuttatást lehetővé tevő hibát javított 2026. október 21-én. A Palo Alto Networks Unit 42 saját telemetriája alapján több mint 22,6 millió nyilvánosan elérhető, potenciálisan sérülékeny példányt azonosított. Ez nem 22,6 millió igazolt kompromittálódás, és nem egyenlő 22,6 millió egyedi vállalkozással.

Az AWS MadPot érzékelői október 17-re visszamenőleg támadási kísérletet láttak, vagyis a nyilvános javítás előtt is volt gyanús aktivitás. Az AWS ugyanakkor kifejezetten jelezte: a korai kísérletekről nem tudni, hogy valós rendszereken sikerrel jártak volna. Ezért a helyes reakció a gyors frissítés és a naplók vizsgálata, nem a tömeges feltörés automatikus feltételezése.

Mi a PHP2Shell, és miért súlyos?

A PHP2Shell a CVE-2026-109618 és CVE-2026-109619 sérülékenységek közös neve. Mindkettő a PHP futtatókörnyezetének memóriakezeléséhez kapcsolódik; sikeres kihasználás esetén egy hitelesítés nélküli támadó a webes PHP-folyamat jogosultságaival futtathat kódot. A két hivatalos PHP-tanácsadó különböző technikai előfeltételeket ír le. A közös üzleti következmény a webhely vagy szerver feletti részleges vagy teljes kontroll, az adatokhoz való hozzáférés és a szolgáltatás kiesése lehet.

A hiba a PHP rétegében van. Egy WordPress-mag, téma vagy bővítmény frissítése fontos, de önmagában nem cseréli le a sebezhető PHP-binárist. Fordítva is igaz: a WordPress név nem bizonyítja, hogy egy konkrét webhely érintett; a ténylegesen futó, szolgáltató által telepített PHP-verziót kell megállapítani.

WordPress, webshop, Laravel, Plesk: kinél mekkora a kitettség?

A legnagyobb prioritás az internet felől elérhető, javítatlan PHP-val kiszolgált alkalmazásoké. Ide tartozhat WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel, Symfony, egyedi PHP-s API vagy adminfelület. A keretrendszer neve csak segít megtalálni a PHP-t; a kockázatot nem egyetlen CMS-verzió határozza meg. A PHP projekt az Apache mod_php útvonalát különösen kockázatosnak írja le, mert bizonyos feldolgozás már az alkalmazáskód előtt történhet.

A PHP-FPM-et sem lehet automatikusan biztonságosnak nevezni. A hivatalos leírás szerint az egyik útvonalon mások az előfeltételek, a másik hibánál pedig validált FPM-kihasználási út is szerepel. A Plesk külön figyelmeztetett arra, hogy az általa szállított PHP-verziókat és bizonyos panelkomponenseket is ellenőrizni kell. Ugyanez igaz a konténerképekbe, NAS-okba és egyéb készülékekbe csomagolt PHP-ra.

Mit veszíthet egy webhely tulajdonosa?

Sikeres kódfuttatás esetén a támadó a PHP-folyamat jogosultságait kapja, nem automatikusan rendszergazdai vagy root jogot. Ebből mégis súlyos incidens lehet: a webroothoz írási joga esetén módosíthat oldalakat, rosszindulatú kódot vagy átirányítást helyezhet el; olvashat alkalmazáskonfigurációt és elérhető titkokat; a webhelyen keresztül hozzáférhető adatokhoz is közelebb kerülhet. A tényleges hatást a jogosultságok, a hálózati elkülönítés és az alkalmazás konfigurációja határozza meg.

Egy webshopnál ez kiesést, hamis tartalom megjelenését vagy adatvédelmi vizsgálatot vonhat maga után. Több ügyfelet kiszolgáló tárhelyen a szolgáltatónak a közös futtatókörnyezetet és az elkülönítést is értékelnie kell. Fontos: a sérülékeny verzió önmagában nem bizonyít adatszivárgást; erre naplók, fájlváltozások és más incidensbizonyítékok alapján lehet következtetni.

Láttak valódi támadást? Igen. Igazolt tömeges feltörést? Nem ez következik az adatokból.

Az AWS a saját csapdarendszerén október 17-i próbálkozást és később szélesebb körű kihasználási kísérleteket dokumentált. A Cloudflare a saját ügyfeleinél célzott forgalmat és változó támadási mintákat látott, ezért védelmi szabályokat vezetett be. Ezek a megfigyelések valós támadói érdeklődést mutatnak, de egy blokkolt kérés vagy csapdarendszerbe küldött payload nem egyenlő egy sikeresen kompromittált vállalati webhellyel.

A Unit 42 október 25-én visszavont egy korábbi állítást: egy európai kormányzati szervezetnél látott incidens kezdeti bejutását nem tudták e két konkrét CVE-hez kötni. Ez jó példa arra, miért kell egy hírben a megerősített tényeket és a feltételezéseket elválasztani.

Melyik PHP-verziótól javított?

A PHP projekt 2026. október 21-én a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 kiadásokban javította mindkét hibát. A régebbi, támogatásból kikerült ágakhoz disztribúciós vagy fizetős LTS-gyártói backport is készülhet; ilyen esetben a puszta verziószám helyett a csomag gyártójának CVE-szintű javítási közleményét kell ellenőrizni. A Plesk egyes régi ágainál azonos verziószámon, eltérő builddátummal adott ki javított csomagot.

A Cloudflare WAF-szabályai és egyes konfigurációs szűrések csökkenthetik az átmeneti kitettséget, de a PHP saját tanácsadói szerint csak a javított futtatókörnyezet teljes megoldás. A beállítás módosítása után a PHP-workereket is újra kell indítani; egy régi folyamat továbbra is régi kódot futtathat.

Három kérdés, amit ma érdemes feltenni a szolgáltatónak

Ha saját VPS-t vagy konténert üzemeltetsz, ellenőrizd az összes éles PHP-FPM poolt, az Apache modulját, a konténerekbe csomagolt binárist és a vezérlőpultot is. A terminálban kiadott `php -v` gyakran csak a CLI-verziót mutatja, amely eltérhet a webhelyet kiszolgáló PHP-tól. Megosztott tárhelynél a szolgáltató tudja hitelesen megmondani, melyik PHP-build fut az adott domain alatt.

Kérdezd meg: (1) melyik javított PHP-build szolgálja ki az oldalamat, (2) mikor cserélték le és indították újra az összes workert, (3) megnézték-e az október 17. óta keletkezett releváns naplókat és fájlváltozásokat? Ha nincs világos válasz, kérj írásos javítási igazolást és időpontot. Saját rendszeren készíts mentést, frissíts, indítsd újra a folyamatokat, ellenőrizd a tényleges éles verziót, majd vizsgáld a gyanús jeleket.

• Nem PHP-s statikus oldal: a közvetlen PHP2Shell-érintettség csak akkor merül fel, ha külön PHP-s komponens is fut.
• WordPress és WooCommerce: a tárhelyen futó PHP-verziót ellenőrizd; egy pluginfrissítés nem helyettesíti.
• Menedzselt tárhely: a szolgáltatótól kérj konkrét buildet és javítási visszaigazolást.
• Saját VPS vagy konténer: minden példányt, image-et és futó workert ellenőrizz, ne csak az alapértelmezett CLI-t.

Hogyan készült ez az összefoglaló?

A cikket 2026. október 29-én a PHP projekt hivatalos tanácsadói, az AWS és a Cloudflare saját megfigyelései, a Unit 42 kitettségi közlése és helyesbítése, valamint a Plesk gyártói táblázata alapján állítottuk össze. Nem végeztünk saját internetes mérést, nem vizsgáltuk a Montavio ügyfeleinek rendszereit e cikk elkészítéséhez, és nem állítunk saját incidensészlelést. A kockázati csoportok a forrásokból levezetett üzemeltetési prioritások, nem távoli diagnózisok.

Biztonsági helyzetben a publikált számok és gyártói állapotok változhatnak. A saját környezetre vonatkozó döntéshez a futó PHP-buildet, a webkiszolgálási módot, az elérhetőséget és a gyártói javítási közleményt együtt kell ellenőrizni. Részletes, lépésenkénti javítási útmutatónkat a cikk alatti hivatkozásban találod.