A PHP2Shell néven ismert CVE-2026-109618 és CVE-2026-109619 a PHP futtatókörnyezetét érinti. Hitelesítés nélküli távoli kódfuttatást tehetnek lehetővé; az alkalmazás vagy a WordPress frissítése önmagában nem javítja a PHP-t.
Ez az útmutató segít azonosítani a webes PHP-futtatót, kiválasztani a megfelelő javítást, újraindítani a workereket és ellenőrizni az eredményt. A konkrét panel- és csomagnevek szolgáltatónként eltérhetnek.
1. Értsd meg a kockázatot
A két PHP-hiba webes kérésből érhető el, és sikeres kihasználás esetén a PHP worker jogosultságaival történő kódfuttatáshoz vezethet. A következmény fájlmódosítás, adat- vagy kulcsszivárgás, illetve kiesés lehet. A PHP projekt szerint minden webes PHP-telepítés vizsgálandó, mod_php esetén különösen sürgősen.
Kép megnyitása teljes méretben 2. Azonosítsd a tényleges webes PHP-t
- Írd össze az összes webhelyet, aldomaint, PHP-FPM pool-t, Apache mod_php kiszolgálót, konténert és külön szolgáltatói PHP-kezelőt.
- A tárhelykezelőben nézd meg a domainhez választott PHP-ágat és kezelőt. VPS-en olvasd ki a futó PHP-FPM/Apache szolgáltatások és csomagok verzióját.
- A `php -v` eredményét csak a CLI ellenőrzéseként kezeld. A webes SAPI eltérhet; ha diagnosztikai fájllal ellenőrzöd, csak jogosult belső hozzáféréssel tedd, és azonnal töröld.
- Jegyezd fel a csomag forrását, builddátumát és a két CVE-re vonatkozó gyártói közleményt. Régebbi verziószám mellett is lehet javított visszaportolt csomag.
php -v
php --ini
systemctl list-units 'php*-fpm.service' --all3. Válaszd a javított verziót
A PHP 8.1 és régebbi ágak normál upstream frissítést már nem kapnak. A PHP projekt kivételes forráskód-visszaportolást adott 7.4/8.0/8.1-hez, de ez nem jelenti a támogatás visszaállítását. Disztribúciós csomagnál a verziószám mellett a biztonsági változásnaplót nézd.
| PHP-ág | Első javított upstream verzió |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 és korábbi | Támogatott ágra váltás vagy igazolt gyártói visszaportolás |
4. Készíts mentést, majd frissíts
- Készíts ellenőrzött mentést a webhely fájljairól, adatbázisáról és a releváns konfigurációról; rögzíts rövid visszaállási tervet.
- Teszteld a kiválasztott PHP-ágat az alkalmazásoddal és a szükséges kiterjesztésekkel, majd telepítsd a javított upstream vagy igazolt gyártói csomagot.
- Konténernél építs új képet javított alapképből, és cseréld le a futó példányokat. Plesknél frissítsd a webhelyek PHP-kezelőit és a Plesk saját `sw-engine`/`plesk-engine` összetevőjét is.
- Indítsd újra vagy cseréld le az összes érintett PHP workert. Csak telepített csomag mellett a régi processzek még sérülékeny kódot futtathatnak.
5. Ellenőrizd a működő webhelyet
- A frissítés után az érintett domaineknél ellenőrizd a tényleges webes PHP-ágat és a szolgáltatói javítás státuszát; ne csak a CLI verziót.
- Teszteld a főoldalt, belépést, űrlapokat, fájlfeltöltést, fizetési folyamatot és az ütemezett feladatokat, ha használod őket.
- Ellenőrizd, hogy minden FPM pool, Apache worker vagy konténer lecserélődött, és nézd meg a frissítés utáni hibanaplót.
- Rögzítsd a verziót, csomagkiadást, ellenőrzés időpontját és az ellenőrzött domaineket. Ha több webhely van, mindegyiket pipáld végig külön.
6. Ha a frissítés átmenetileg nem lehetséges
- A PHP közlemény szerint a `session.upload_progress.enabled=0` a megerősített session útvonalak egy részét blokkolhatja; ezt a kérés feldolgozása előtt alkalmazott szerver- vagy poolbeállításban kell megadni, utána minden workert újraindítani.
- A `memory_limit=-1` a PHP-határból eredő egyik kiváltó okot szüntetheti meg, de növeli az erőforrás-kimerülés kockázatát, és nem teljes javítás. Csak üzemeltetői mérlegeléssel és elkülönített erőforráskorláttal használd.
- Korlátozd a feltöltési és kérésméreteket az alkalmazás igénye szerint; a PHP hivatalos példái 8 MB illetve szükséges feltöltésnél 32 MB `post_max_size` értéket adnak.
- Ha nem tudod igazolni a javítást, az érintett szolgáltatás ideiglenes korlátozása vagy leállítása is szükséges lehet.
7. Ha kompromittálódásra gyanakszol
- Őrizd meg a webes, PHP- és rendszer naplókat, az időpontokat és a futó szolgáltatások állapotát; ne törölj bizonyítékot találomra.
- Különítsd el az érintett rendszert a további hozzáféréstől, és kérj incidenskezelői segítséget.
- Vizsgáld meg a módosított fájlokat, új felhasználókat, gyanús folyamatokat és kimenő kapcsolatokat. A javítás nem távolítja el a már elhelyezett rosszindulatú kódot.
- A vizsgálat alapján cseréld az érintett jelszavakat, tokeneket és kulcsokat; szükség esetén tiszta mentésből állíts vissza, majd ellenőrizd újra a javítást.
