# A tárhelyszolgáltató PHP-frissítési igazolása: így kérdezzen rá a javítási állapotra

> Így kérhet a tárhelyszolgáltatótól megbízható igazolást a PHP-frissítésről a PHP2Shell után: mely adatok számítanak, másolható minta, a válasz értékelése.

Forrás: https://phpsos.de/hu/ratgeber/hoster-patch-status-erfragen/  
Á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 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

2026. 10. 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](https://phpsos.de/hu/php2shell/php-version-pruefen/) 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.enabled` a 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.

```text
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:

```bash
# 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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) 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ó](https://phpsos.de/hu/server/shared-hosting/) oldal magyarázza; gondozott szerverekhez a [Menedzselt szerver: a felelősség tisztázása](https://phpsos.de/hu/server/managed-server/) segít.

> **Tipp:**
> 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](https://phpsos.de/hu/leistungen/php-patch-service/) í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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik (a német Szövetségi Információbiztonsági Hivatal)](https://www.bsi.bund.de/)