Röviden: A PHP2Shell után a kijelzett PHP-verzió önmagában keveset bizonyít, mert a tárhelyszolgáltatók a javításokat gyakran backportként telepítik. Ezért kérjen írásos igazolást a tárhelyszolgáltatótól a PHP-frissítésről: a csomagállapotot PHP-águnként, a telepítés időpontját és az összes PHP-folyamat újraindítását. Másolható mintát lent talál.
Miért számít éppen most az írásos igazolás
-
- 21-én a PHP-projekt kiadta a javításokat két kritikus résre, amelyek PHP2Shell néven ismertek. Mindkettő lehetővé teszi kártékony kód távoli futtatását bejelentkezés nélkül. A BSI (a német Szövetségi Információbiztonsági Hivatal) 3. riasztási szintet (narancs) hirdetett, és azonnali frissítést javasol.
Aki a weboldalát tárhelyszolgáltatónál üzemelteti, a frissítést gyakran nem tudja maga telepíteni. Ugyanakkor üzemeltetőként Ön viseli a felelősséget az ügyfelei adataiért. A tárhelyszolgáltató írásos, konkrét igazolása ezért több puszta formaságnál. A dokumentációja egyik építőeleme, például az adatvédelmi felelősök, a biztosítók vagy a vezetőség felé.
Ehhez jön még: a javítás nem távolítja el a korábban bejuttatott kártékony szoftvert. Médiabeszámolók szerint már 10. 17-én megfigyeltek egy első támadási kísérletet. Az a pontos időpont, amikortól a szervere védett volt, ezért fontos annak eldöntéséhez, hogy tovább kell-e vizsgálódnia.
Miért nem elég a kijelzett PHP-verzió
Javítva van a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. Sok disztribúció és tárhelyszolgáltató azonban backportként a saját csomagjába veszi át a javítást. Ilyenkor egy olyan felület, mint a Plesk, továbbra is 8.2.34-et mutat, noha a szerver javítva van.
Fordítva is megtévesztő lehet egy helyes verziószám. Az új fájlok önmagukban nem védenek, amíg régi PHP-folyamatok futnak a memóriában. Csak az összes worker újraindítása után él az új állapot. Erről többet a A PHP-verzió és a javítási állapot helyes ellenőrzése cikkben talál.
| A tárhelyszolgáltató állítása | Mit bizonyít | Mi hiányzik még |
|---|---|---|
| „Minden rendszer naprakész.“ | keveset | verzió vagy csomagállapot, dátum, újraindítás |
| „A PHP 8.3.36 telepítve van.“ | a verziót | dátum, újraindítás, érintett szerverek |
| „Backport az xy csomagban, újraindítás ekkor: …“ | a javítást és az aktiválását | adott esetben adatok a PHP 8.1-ről és régebbiről |
Milyen adatokra van szüksége a tárhelyszolgáltatótól
Kérjen választ ezekre a pontokra, lehetőleg weboldalanként vagy szerződésenként:
- Mely PHP-ágak és verziók aktívak a weboldalaihoz, a régebbiek is, amelyek csak egyes könyvtárakhoz futnak?
- Tartalmazzák-e a CVE-2026-109618 és a CVE-2026-109619 javításait, hivatalos verzióként vagy backportként?
- Mikor telepítették a frissítést, és mikor indították újra az összes PHP-folyamatot (FPM-poolok, Apache, LiteSpeed)?
- Ki van-e kapcsolva a
session.upload_progress.enableda CVE-2026-115560 miatt? - Melyik üzemmódot használja a csomagja, például PHP-FPM-et vagy Apache-ot mod_php-val? A mod_php esetében látja a PHP-csapat a legnagyobb kockázatot.
- Mely hozzáférési és hibanaplókat őrzik meg 2026. 10. 20-tól, és hogyan kaphatja meg őket?
Ha egy weboldal még PHP 8.1-en vagy régebbin fut, erről kérdezzen külön. Ezekhez az ágakhoz már nincsenek hivatalos frissítések, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz.
Minta: a tárhelyszolgáltató PHP-frissítési igazolásának kérése
Másolja a szöveget egy támogatási jegybe vagy a tárhelyszolgáltatójának küldött e-mailbe. A szögletes zárójelben lévő adatokat egészítse ki.
Tárgy: Kérés a PHP-javítások állapotának megerősítésére (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Tisztelt Hölgyem/Uram!
Önöknél a következő weboldalakat / szerződéseket üzemeltetjük:
[ügyfélszám, szerződés, domainek]
A CVE-2026-109618 és CVE-2026-109619 PHP-sebezhetőségekkel
(PHP2Shell, 2026. 10. 21-i javítások), valamint a CVE-2026-115560-ra
vonatkozó, 2026. 10. 23-i figyelmeztetéssel kapcsolatban írásbeli
megerősítést kérünk a következő pontokra:
1. Mely PHP-verziók, illetve csomagállapotok aktívak a weboldalainkhoz?
2. Tartalmazzák-e a javításokat (hivatalos verzió vagy backport)?
3. A telepítés dátuma és időpontja.
4. Az összes PHP-folyamat (FPM, Apache,
LiteSpeed stb.) újraindításának dátuma és időpontja.
5. Ki van-e kapcsolva a session.upload_progress.enabled a szerver oldalán?
6. Milyen PHP-üzemmódot használnak (pl. PHP-FPM, mod_php)?
7. Megőrzik-e a hozzáférési és hibanaplókat 2026. 10. 20-tól, és
hogyan kaphatjuk meg őket?
8. Ha egy weboldal még PHP 8.1-et vagy régebbit használ: Milyen védelem
van ott, és milyen átállást javasolnak?
Az adatokra a belső dokumentációnkhoz van szükségünk.
Köszönettel és üdvözlettel
[név, cég, beosztás]
A válasz helyes értékelése és saját ellenőrzés
Egy jó válasz konkrét állapotokat, dátumokat és időpontokat nevez meg. Az olyan általános megfogalmazások, mint a „reagáltunk“, nem elegendők az iratanyagához. Ilyenkor kérdezzen rá udvariasan a hiányzó pontokra.
Ha a csomagja megengedi, ellenőrizzen Ön is. SSH-hozzáféréssel többnyire elegendők ezek a parancsok:
# A parancssor verziója (eltérhet a webes verziótól)
php -v
# Csomagállapot Debian/Ubuntu alatt
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Csomagállapot RHEL, Alma, Rocky alatt
rpm -qa | grep -i php
# Mióta futnak a PHP-FPM-folyamatok?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ha a PHP-folyamatok indulási időpontja a megerősített telepítési dátum előtt van, az újraindítás nem volt teljes.
Ha a tárhelyszolgáltató nem vagy csak kitérően válaszol
Ha elmarad a válasz, vagy hiányoznak a döntő adatok, ne tekintse tisztázottnak a helyzetet. A BSI azt javasolja, hogy a webszervereket átmenetileg vegyék le a hálózatról, ha a frissítés nem lehetséges azonnal. Hogy ez arányos-e az Ön weboldalára nézve, azt a vezetőség dönti el, ideális esetben írásban és dátummal.
Közben érdemes megnézni egy támadás lehetséges nyomait, mert a javítás időpontja nyitott marad. Támpontokat ad a Már feltörték a rendszeremet? cikk. SSH-hozzáférés nélkül az írásos igazolás marad a legfontosabb bizonyítéka. Hogy mely kötelezettségek terhelik a tárhelyszolgáltatót, és melyek Önt, azt a Megosztott tárhely: mit tesz a tárhelyszolgáltató oldal magyarázza; gondozott szerverekhez a Menedzselt szerver: a felelősség tisztázása segít.
Tegye el a kérést, a választ és a saját ellenőrzési eredményeit dátummal egy mappába. Ez az iratanyag később segít a biztosítók vagy az adatvédelmi felelősök kérdéseinél.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt megfogalmazzuk a tárhelyszolgáltatónak szóló kérést, és szakmailag értékeljük a választ.
- Ahol van hozzáférés, magunk ellenőrizzük a csomagállapotot, az aktív üzemmódot és a PHP-folyamatok újraindítását.
- Ha hiányosságok maradnak, átmeneti intézkedéseket vezetünk be, vagy megtervezzük az átállást egy támogatott verzióra.
- Az eredményt és az időpontokat olyan igazolásban rögzítjük, amelyet belsőleg továbbadhat.
Hogyan zajlik a frissítés újraindítással és igazolással, azt a PHP-javítási szolgáltatásunk írja le.
Gyakori kérdések
Elég, ha a tárhelyszolgáltatóm azt írja, hogy minden naprakész?
A dokumentációjához inkább nem. Kérjen konkrét adatokat: csomagállapotot vagy verziót PHP-águnként, a telepítés dátumát és az összes PHP-folyamat újraindításának dátumát. Csak ezekkel tudja behatárolni a sebezhetőség időablakát.
Miért mutat a tárhelyfelületem még mindig PHP 8.2.34-et?
A disztribúciók és a tárhelyszolgáltatók a biztonsági javításokat részben backportként telepítik, a verziószám megváltoztatása nélkül. A Plesk ilyenkor tovább mutathatja a 8.2.34-et, noha a szerver javítva van. Tisztázni csak a szolgáltató csomagállapotról szóló igazolása tud.
Mit tegyek, ha a tárhelyszolgáltató nem válaszol?
Dokumentálja a kérését dátummal, és megfelelő idő elteltével kérdezzen rá újra. Közben ellenőrizze, hogy az átmeneti intézkedéseket be tudja-e állítani Ön is, és egyeztessen a vezetőséggel arról, hogy a weboldal a tisztázásig lekerüljön-e a hálózatról, ahogy a BSI (a német Szövetségi Információbiztonsági Hivatal) a nem javított szerverekre javasolja.
A WordPress- vagy webshop-frissítés is lezárja a rést?
Nem. A PHP2Shell magában a PHP-ban van. A CMS vagy a webshop-szoftver frissítése nem változtat a szerveren futó PHP-értelmezőn.