A PHP2Shell a 2026. október 21-én nyilvánosságra hozott kritikus PHP-sérülékenységek elnevezése. Ha weboldala PHP-t használ, elsőként azt kell tisztázni, hogy a látogatókat kiszolgáló futtatókörnyezet megkapta-e a biztonsági javításokat. Egy frissített bővítmény vagy egy zöld tűzfal-irányítópult erre nem ad választ.
A PHP2Shell a weboldalak alatt működő PHP-futtatókörnyezetet érinti, és hitelesítés nélküli távoli kódfuttatást tehet lehetővé. A PHP kiadta a javításokat a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókban, ezért a tényleges webes kiszolgálási környezetben kell igazolni egy javított kiadás vagy dokumentált szállítói visszaportolás használatát. Tartsa bekapcsolva a védelmi intézkedéseket, de a WAF-ot és az ideiglenes konfigurációmódosítást ne tekintse a javítás helyettesítőjének.
Ellenőrzött állapot: 2026. október 21., 17:15 UTC. Az útmutató a közzétett javításokra épül, nem arra a korábbi közleményre, amely szerint a kiadás még várat magára. Módosítás előtt ismét ellenőrizze a hivatkozott közleményeket, mert a szállítói csomagok és a válaszlépésekre vonatkozó ajánlások gyorsan változhatnak.
PHP2Shell: mit erősítettek meg ténylegesen?
A PHP biztonsági csapata két olyan hibát azonosít, amely bejelentkezés nélküli távoli kódfuttatást tehet lehetővé. A hivatalos közlemény szerint a webes kéréseket kiszolgáló PHP-telepítések veszélyeztetettek, és a mod_php-t használó Apache-konfiguráció hordozza a legnagyobb kockázatot. A kihasználhatóságot a futtatókörnyezet, a build és a kérések feldolgozási környezete is befolyásolja.
| Azonosító | A PHP leírása | Gyakorlati kockázat |
|---|---|---|
| CVE-2026-109618 | Memóriahiány miatti sérülés a kérés lezárása során | A PHP érvénytelen kérésállapotot használhat memóriafoglalási hiba kezelésekor |
| CVE-2026-109619 | Elavult, kéréshez tartozó globális állapot | Ugyanazon munkafolyamat egy későbbi kérése már felszabadított memóriára mutató hivatkozásokkal találkozhat |
Mindkét közleményben a CVSS v4.0 pontszám 9.2. Olvassa el a CVE-2026-109618 és a CVE-2026-109619 elsődleges jelentését, ne csupán egy közösségi bejegyzésben javasolt kerülőmegoldásra támaszkodjon.
Mindez gyors intézkedést indokol, de nem bizonyítja, hogy már minden PHP-weboldalt feltörtek. A kritikus sérülékenység, a támadási kísérlet és az igazolt behatolás különböző megállapítás. A válaszlépéseknek azt kell tisztázniuk, ezek közül melyik érinti saját rendszereit.
Mely PHP-verziók javítják a PHP2Shell hibáit?
A támogatott ágak ma közzétett biztonsági kiadásai az alábbi táblázatban szerepelnek. A verziótáblázat az eredeti PHP-kiadást használó telepítés ellenőrzésének kiindulópontja. A disztribúciós csomagok más csomagrevízió alatt is tartalmazhatják a javításokat.
| PHP-ág | Mindkét sérülékenységet javító biztonsági kiadás |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Ezeket a kiadásokat a PHP kiadási közleményei erősítik meg. Ha a disztribúció vagy a tárhelyszolgáltató visszaportolt javításokat alkalmaz, kérje el a biztonsági közleményt és a telepített csomag pontos revízióját. Pusztán a verziószám alapján tévesen minősíthető egy javított szállítói csomag vagy egy elavult, beágyazott futtatókörnyezet.
A PHP 8.1 és korábbi verziók már nem kapnak szokásos frissítéseket az eredeti projekttől. A PHP minimális forráskódszintű visszaportolásokat is biztosított a 7.4, 8.0 és 8.1 verziókhoz, de ez nem állítja vissza a folyamatos támogatást. Gondoskodjon egy felelős szállító által támogatott javításról vagy egy verzióváltási tervről. A PHP támogatási táblázata ismerteti az ágak aktuális támogatását.
Külön ellenőrizze a konténereket, a beágyazott PHP-telepítéseket és a kész alkalmazáseszközöket. Az NCSC-NL üzemeltetési útmutatója kifejezetten figyelmeztet arra, hogy a gazdagép PHP-jának frissítése ezeket a futtatókörnyezeteket nem feltétlenül frissíti.
Érintettek a WordPress-, Laravel- és más PHP-weboldalak?
Kezdje az alkalmazást végrehajtó értelmezővel. Egy WordPress-oldal, egy Laravel-alkalmazás és egy egyedi PHP-portál ugyanazt az elavult futtatókörnyezetet használhatja, miközben az alkalmazáskódjuk teljesen különböző. A legújabb sablon, bővítmény vagy keretrendszer telepítése nem telepíti a PHP-futtatókörnyezet biztonsági javítását.
Menedzselt tárhely esetén kérdezze meg, hogy az egyes oldalakat mely PHP-verzió vagy javított csomag szolgálja ki, minden csomópontra eljutott-e a változás, és ahol szükséges, újraindították-e a munkafolyamatokat. A tárhelyplatformtól kérjen bizonyítékot, ne egy alkalmazásfrissítési értesítést tekintsen igazolásnak.
Saját kezelésű rendszereknél a másodlagos oldalakat, adminisztrációs felületeket, régi virtuális hosztokat és előnézeti környezeteket is vegye fel a leltárba. Előfordulhat, hogy az éles alkalmazás már frissült, miközben ugyanazon infrastruktúrán egy régebbi oldal továbbra is nyilvánosan elérhető. Minden kitett környezethez rögzítsen felelőst és javítási döntést.
Egy nem használt feltöltési űrlapból ne következtessen a telepítés biztonságára. A PHP közleményei a futtatókörnyezet kérésfeldolgozási útvonalait írják le. A látogató által látható alkalmazásfunkciók nem jelentenek teljes kitettségvizsgálatot.
A látogatókat kiszolgáló futtatókörnyezet javítása és ellenőrzése
Állapítsa meg, mi fut ténylegesen
Azonosítsa a webszerver-integrációt, a futtatókörnyezeti csomagot vagy konténerképet, a konfiguráció forrását és a szolgáltatás felelősét. Kapcsolja ezt a leltárt az ügyfelek által használt gépnévhez. A rossz gépet ellenőrző mérnök meggyőző, de a helyzet szempontjából lényegtelen verziójelentést készíthet.
Az alábbi, csak olvasó parancsok a parancssori telepítést és annak konfigurációját azonosítják:
1php -v
2php --ini
Nem bizonyítják, hogy a PHP-FPM, az Apache vagy más webes kiszolgáló-integráció mit futtat. A kiszolgáló futtatókörnyezet megállapításához használjon hitelesített tárhelyadatokat vagy ellenőrzött adminisztrátori vizsgálatot. Ne hagyjon nyilvánosan elérhető diagnosztikai oldalt, amely konfigurációs és környezeti adatokat fed fel.
Konténeres telepítésnél a forgalmat ténylegesen fogadó képet és alkalmazáspéldányt ellenőrizze, ne csupán a képtárban tárolt csereképet. A módosítási nyilvántartásba minden, terheléselosztó mögötti példányt és különálló munkafolyamat-szolgáltatást is vegyen fel.
Alkalmazza a támogatott javítást, majd tesztelje az alkalmazást
Kövesse a karbantartott csomagforrás vagy a konténerkép szállítójának dokumentált frissítési eljárását. Rögzítse a telepített revíziót és a mindkét CVE-re kiterjedő szállítói közleményt. A szolgáltatások újraindítását vagy a példányok cseréjét a telepítéshez igazítsa, ne feltételezze, hogy egy csomag letöltése megváltoztatja a futó folyamatokat.
A szolgáltatást megzavaró módosítások előtt őrizze meg a releváns naplókat. Legyen ellenőrzött biztonsági mentés és helyreállítási terv, majd a frissítés után teszteljen jellemző alkalmazásfolyamatokat. A bejelentkezés, a munkamenetek, a fizetés, a feltöltés és a háttérfeldolgozás hasznos jelöltek, ha az alkalmazás használja őket.
A módosítást a kiszolgáló futtatókörnyezet újbóli ellenőrzésével zárja le. Őrizze meg, mely példányokat frissítették, mikor irányították át a forgalmat, és ki fogadta el az alkalmazásellenőrzéseket. A sikeresként jelölt telepítési feladat hasznos bizonyíték, de nem a teljes ellenőrzés.
Véd a Cloudflare WAF a PHP2Shell ellen?
A Cloudflare beszámolt a PHP2Shell elleni WAF-védelem bevezetéséről az ingyenes és fizetős WAF-ügyfelek számára, valamint támadási forgalom megfigyeléséről. Közleménye olyan védelmet ír le, amely a kérések és válaszok adatait is figyelembe veszi. Kifejezetten javasolja a PHP javítását e védelem mellett is.
Egy adott weboldalnál ellenőrizze, hogy az érintett forgalom valóban a védett szolgáltatáson halad-e át, és a megfelelő szabályok aktívak-e. Vizsgálja meg a kivételeket, a védelmet megkerülő szabályokat és a külön elérhető eredeti kiszolgálót. Ezek telepítési ellenőrzések, nem annak állítása, hogy a Cloudflare közleménye minden lehetséges hozzáférési útvonal védelmét garantálja.
A vizsgálathoz őrizze meg a WAF eseményadatait. Egy blokkolt kérés azt igazolhatja, hogy arra a kérésre egy szabály illeszkedett. Nem bizonyítja, hogy az eredeti kiszolgálót soha nem érték el más úton, vagy hogy korábban nem történt behatolás.
A WAF-ot kiegészítő védelmi rétegként használja a futtatókörnyezet frissítése közben. Ne halassza a PHP-javítást pusztán azért, mert az irányítópult blokkolt próbálkozásokat mutat.
Az ideiglenes intézkedések nem javítják teljesen a PHP2Shell hibáit
Ha a javítás átmenetileg akadályba ütközik, a rendszerért felelős mérnökkel vagy szolgáltatóval kövesse a PHP aktuális közleményeit. Az elavult állapotról szóló közlemény
elmagyarázza, hogy a session.upload_progress.enabled kikapcsolásának miért kell a kéréselemzés előtt megtörténnie, és miért szükséges minden munkafolyamat újraindítása. Kifejezetten figyelmeztet, hogy erre ne az ini_set() vagy az FPM .user.ini beállítására támaszkodjon.
Ez a változtatás az igazolt, munkamenethez kötődő útvonalakat blokkolja, nem minden változatot. A PHP 8.5 esetén a fatal_error_backtraces beállításra külön útmutatás vonatkozik. Egy fórumról átmásolt rövid konfigurációrészlet nem bizonyítja, hogy mindkét sérülékenységet kezelték.
A memóriahiányról szóló közlemény eltérő védelmeket ír le, köztük kéréskorlátokat és a memóriakorlátok kezelésének módosításait. Ezek erőforrás- és rendelkezésre állási következményekkel járnak. A teljes, adott telepítésre vonatkozó utasításokat tekintse át, ne távolítson el könnyelműen memóriakorlátokat egy éles szerveren.
Ha a kitettség a javítás előtt nem csökkenthető elfogadható szintre, egyeztessen az érintett alkalmazás nyilvános elérésének korlátozásáról. Dokumentálja az ideiglenes intézkedést, annak korlátait, felelősét és a tervezett végleges javítást. Egy kerülőmegoldáshoz eltávolítási vagy felülvizsgálati feltétel szükséges, különben dokumentálatlan, állandó beállítássá válhat.
Mit figyeljen a kitettség ellenőrzése után?
Induljon egy alapállapotból, és őrizze meg a lényeges időablak adatait. A webes kéréseket kapcsolja össze a PHP, a webszerver és a gazdagép eseményeivel, ne tekintsen egyetlen szokatlan kérést teljes diagnózisnak. Ha naplók hiányoznak, ezt a korlátot kifejezetten rögzítse.
| Megfigyelés | Vizsgálati kérdés |
|---|---|
| Váratlan PHP-munkafolyamat-leállások vagy memóriahibák | Változott az alkalmazás viselkedése, és milyen kéréseket dolgozott fel a közelben? |
| Új vagy módosult végrehajtható fájlok | Jóváhagyott telepítés történt, vagy megmagyarázatlan írás? |
| Váratlan gyermekfolyamatok vagy kimenő kapcsolatok | Van a webes munkafolyamatnak jogos oka erre a tevékenységre? |
| WAF-találatok és az eredeti kiszolgáló hozzáférési naplói | Mely kéréseket blokkolták, és mely útvonalak érték el az eredeti kiszolgálót? |
| Fiókok, ütemezett feladatok vagy titkok változásai | Minden módosítás összeköthető egy felhatalmazott üzemeltetővel? |
Ezek vizsgálati szempontok, nem PHP2Shell-specifikus indikátorok vagy a kompromittálódás bizonyítékai. A normál üzemeltetés is eredményezhet hasonló tüneteket. Ugyanígy a riasztások hiánya nem bizonyítja, hogy egy javítatlan rendszer biztonságos volt.
Ha a bizonyítékok behatolásra utalnak, őrizze meg őket, és a javítással párhuzamosan szervezze meg az incidenskezelést. Az értelmező frissítése nem szünteti meg a támadó tartós jelenlétét, nem teszi semmissé a hitelesítő adatok ellopását, és nem állapítja meg, milyen adatokhoz fértek hozzá. Ezeket a választervben külön kérdésként kezelje.
Gyakran ismételt kérdések
Mi a PHP2Shell exploit? A PHP2Shell a CVE-2026-109618 és CVE-2026-109619 azonosítójú PHP-sérülékenységeket jelöli. A futtatókörnyezet memóriakezelését érintik, és hitelesítés nélküli távoli kódfuttatást tehetnek lehetővé. Nem egyszerűen egy WordPress-bővítmény hibájáról van szó.
Mely verziókat ellenőrizzem a PHP2Shell-javításhoz? A támogatott ágak 2026. október 21-én kiadott javításai a PHP 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziói. Disztribúciós visszaportolásnál szerezze be a szállítói közleményt, és ellenőrizze a kiszolgáló környezetbe telepített javított csomag pontos revízióját.
A WordPress frissítése javítja a PHP2Shell hibáit? A WordPress frissítése önmagában nem frissíti az alatta működő PHP-értelmezőt. Tartsa naprakészen az alkalmazást, de a tárhelyszolgáltatóval vagy a szerverért felelős mérnökkel külön ellenőrizze a PHP-futtatókörnyezet biztonsági javítását.
Automatikusan biztonságos egy Cloudflare mögötti oldal? A Cloudflare WAF-védelemről számolt be, de a forgalom útvonalát, az alkalmazandó szabályokat és az eredeti kiszolgáló kitettségét továbbra is ellenőrizni kell. Tartsa aktívan a védelmet, és javítsa a PHP-t. Egy tűzfal-irányítópult nem bizonyítja a futtatókörnyezet javítását vagy egy korábbi kompromittálódás hiányát.
Elég kikapcsolni a munkamenet feltöltési folyamatjelzését? Nem. A PHP szerint ez az intézkedés az igazolt, munkamenethez kapcsolódó útvonalakat blokkolja, nem minden változatot. A megfelelő konfigurációs rétegben kell alkalmazni, a munkafolyamatok újraindításával. Továbbra is szükséges egy javított futtatókörnyezet vagy ellenőrzött szállítói visszaportolás.
Kipróbálhatok egy nyilvános exploitot az éles weboldalamon? Elsőként a verzióra, csomagra és konfigurációra vonatkozó bizonyítékokat részesítse előnyben. Ha az ellenőrzés kihasználási tesztet igényel, azt kifejezett engedéllyel, ellenőrzött környezetben, elkülönítéssel, megfigyeléssel és helyreállítási tervvel szervezze meg. Ne futtasson átvizsgálatlan exploit-szkripteket éles rendszeren.
A javítás telepítése bizonyítja, hogy a szervert nem törték fel? Nem. A javítás a futtatókörnyezet hibáit kezeli, míg az incidensvizsgálat a korábbi tevékenységet, a tartós jelenlétet, a hitelesítő adatokat és az esetleges adathozzáférést elemzi. Kapcsolja össze ezeket a munkafolyamatokat, és rögzítse a rendelkezésre álló bizonyítékok korlátait.
Segítség kell PHP-oldala ellenőrzéséhez, figyeléséhez vagy javításához?
Segítünk megállapítani, mely PHP-futtatókörnyezetek szolgálják ki weboldalait, felmérjük a kitettséget, áttekintjük az elérhető naplókat és védelmi beállításokat, valamint megtervezzük a szükséges javítást vagy támogatott verzióváltást. Ha a környezet folyamatos megfigyelést igényel, megállapodhatunk a megfigyelés hatóköréről, a riasztások felelőseiről és az azonosított kockázatokhoz igazodó eszkalációs folyamatról.
Az alkalmazásbiztonsági szolgáltatásunk a felmérést és a vizsgálatot támogatja, míg a szerverbiztonsági szolgáltatásunk a tárhely és a konfiguráció területét fedi le. A tárhelyszolgáltatójával együtt ellenőrizhetjük a szállítói javításokat, összehangolhatjuk a módosításokat, és dokumentálhatjuk a frissítés utáni alkalmazásellenőrzéseket.
Hasznos eredmény egy világos nyilvántartás arról, mit ellenőriztünk és javítottunk, mi maradt bizonytalan, és ki felel a további lépésekért. Nem ígérünk teljes biztonságot egy verziószám vagy egyetlen vizsgálat alapján. A hatókört és a rendelkezésre állást a munka megkezdése előtt egyeztetjük.
Keressen minket PHP2Shell-kitettségvizsgálatért, biztonsági megfigyelésért vagy javítási segítségért . Írja meg a tárhely kialakítását, az érintett domaineket, az ismert PHP-verziókat és a változtatások jóváhagyására jogosult személyt. Az első megkeresésben ne küldjön jelszavakat vagy hozzáférési tokeneket.