# Miért nem segít a WordPress-frissítés a PHP2Shell ellen

> Miért nem segít a WordPress-frissítés a PHP2Shell PHP-rés ellen, melyik réteg számít valóban, és mit ellenőrizzenek helyette a WordPress-üzemeltetők.

Forrás: https://phpsos.de/hu/blog/warum-wordpress-update-nicht-hilft/  
Á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 WordPress-frissítés nem segít a PHP2Shell PHP-rés ellen, mert a hiba nem a WordPressben van, hanem a PHP-ban, abban a szoftverben a szerveren, amely a WordPresst futtatja. A Dr. Web szerint a WordPress.org ezért saját frissítést sem tervez. Védeni csak a szerveren végzett PHP-frissítés tud az összes PHP-folyamat újraindításával. Ezt általában a tárhelyszolgáltatója vagy a szerverüzemeltetője telepíti.

## A kiindulópont: „Hiszen mindent frissítettünk”

A PHP2Shellről szóló első főcímek után sok üzemeltető azt tette, ami kézenfekvő: megnyitotta a WordPress vezérlőpultját, rákattintott a „Frissítés most” gombra, a bővítményekkel és a témákkal együtt. Utána minden zöld, és az érzés azt súgja: kész.

Ennél a résnél az érzés csal. Ez nem a WordPress miatt van, hanem azért, hogy hol van a hiba. A Cloudflare is rámutat a közleményében, hogy az alkalmazáskód vagy a bővítmények frissítése nem szünteti meg a réseket.

## WordPress-frissítés és PHP-rés: a rétegmodell

Egy WordPress-weboldal több, egymásra épülő rétegből áll. Minden rétegnek saját frissítései és gyakran saját felelősei vannak:

| Réteg | Példa | Ki frissíti jellemzően | Érinti a PHP2Shell? |
|---|---|---|---|
| Operációs rendszer | Debian, Ubuntu, AlmaLinux | tárhelyszolgáltató vagy szerveradmin | nem, de gyakran ez szállítja a PHP-csomagot |
| Webszerver | Apache, Nginx, LiteSpeed | tárhelyszolgáltató vagy szerveradmin | az üzemmód befolyásolja a kockázatot |
| PHP-futtatókörnyezet | PHP-FPM, mod_php | tárhelyszolgáltató vagy szerveradmin | igen, itt van a rés |
| WordPress-mag | WordPress | üzemeltető vagy ügynökség | nem |
| Bővítmények és témák | WooCommerce, page builder | üzemeltető vagy ügynökség | nem |

A vezérlőpulton lévő frissítés gomb csak a két alsó sort éri el. A PHP-futtatókörnyezet alattuk van, és a WordPress számára láthatatlan. Hogyan épülnek más rendszerek a PHP-ra, azt a [CMS-ek és webshopok PHP-n](https://phpsos.de/hu/php/cms-und-shops-auf-php/) írás írja le.

## Miért nem tudja a WordPress bezárni a rést

Azt gondolhatná az ember, hogy a WordPress „körülprogramozhatja”. Ez a PHP2Shell esetében két okból nem működik.

Először: mindkét hiba abban rejlik, ahogyan a PHP a kéréseket feldolgozza és utána takarít. Ez attól függetlenül történik, hogy melyik program fut a PHP-ban. Másodszor: a PHP-csapat az Apache és mod_php esetében olyan exploitot mutatott be, amely azelőtt hat, hogy egyáltalán alkalmazáskód futna. A WordPress, a bővítményei és bármely biztonsági bővítmény ilyenkor egyáltalán nem kerül sorra.

Ugyanezért nem segít semmilyen „keményítő bővítmény” sem, amely beállításokat módosít `ini_set()`-tel. A php.net kifejezetten ellenzi, hogy az átmeneti intézkedéseket ezen az úton állítsák be.

### És menedzselt WordPressnél?

Menedzselt WordPress-ajánlatoknál a szolgáltató gyakran nemcsak a WordPress-frissítésekkel, hanem az alatta lévő szerverrel is foglalkozik. Ez a PHP2Shell esetében előny, de nem automatizmus. Kérdezzen rá konkrétan, hogy a PHP-frissítést telepítették-e, és az összes PHP-folyamatot újraindították-e. A „Naprakészen tartjuk a WordPressét” kijelentés nem válaszol erre a kérdésre.

### Sok weboldal, egy PHP-telepítés

Az ügynökségeknek és a több weboldallal rendelkező vállalatoknak ismerniük kell egy sajátosságot: egy szerveren gyakran sok WordPress-telepítés osztozik ugyanazon a PHP-verzión. Ha ez javítatlan, mind érintett, függetlenül attól, milyen jól gondozott az egyes weboldal. Fordítva, egy PHP-frissítés egyszerre védi az összes telepítést, feltéve hogy utána az összes hozzá tartozó PHP-folyamatot újraindítják. Aki több PHP-verziót üzemeltet párhuzamosan, mindegyiket külön kell frissítenie.

> **Fontos:**
> Egy zöld WordPress-vezérlőpult semmit sem mond a PHP2Shellről. A döntő a PHP javítási állapota a szerveren és az összes PHP-folyamat újraindítása.

## A PHP-verzió helyes olvasása a WordPressben

A WordPress megjeleníti a PHP-verziót: a vezérlőpulton az Eszközök, Weboldal állapota alatt, a Jelentés részben a Szerver szakasznál. Ez jó első jelzés, de nem bizonyíték.

Ha ott egy 8.1-es vagy régebbi ág áll, az egyértelmű figyelmeztető jel, mert ahhoz már nincsenek hivatalos frissítések. Ha ott 8.2.35, 8.3.36, 8.4.27 vagy 8.5.12 áll, a javított állapot telepítve van. Ha egy támogatott ág régebbi száma áll ott, backport ettől még telepítve lehet. A disztribúciók és a tárhelyszolgáltatók ilyenkor gyakran nem változtatják meg a számot. Egyértelműséget csak a tárhelyszolgáltató megerősítése vagy egy pillantás a csomag changelogjába ad. Hogyan megy ez, azt a [PHP-verzió és javítási állapot ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/) tartalmazza.

## Mit tegyenek helyette a WordPress-üzemeltetők

1. **Kérdezze meg a tárhelyszolgáltatót vagy a szerverüzemeltetőt:** Javított-e a PHP, mikor, és újraindították-e az összes PHP-folyamatot? A válasz írásban.
2. **Ellenőrizze a PHP-ágat:** Ha a weboldal 8.1-en vagy régebbin fut, tervezze meg az átállást egy támogatott ágra. Hogy a WordPress-verziója melyik verziót támogatja, azt a wordpress.org rendszerkövetelményei között találja. Az átállást az ügyfélmenüben a [PHP-verzió módosítása a tárhely ügyfélterületén](https://phpsos.de/hu/blog/php-version-hosting-aendern/) írja le.
3. **Nyomok ellenőrzése:** új PHP-fájlok a `wp-content/uploads` mappában, ismeretlen rendszergazdai fiókok, idegen bejegyzések a `mu-plugins` mappában. A tipikus rejtekhelyeket a [WordPress és PHP2Shell](https://phpsos.de/hu/plattformen/wordpress/) oldal írja le.
4. **A WordPresst mégis tartsa naprakészen:** A mag, a bővítmények és a témák más réseket zárnak be. Ez továbbra is kötelező, csak más.
5. **Tisztázza a felelősséget:** Ha egy ügynökség gondozza a weboldalt, rögzítse, hogy a PHP-ért is felel-e, vagy csak a WordPressért.

Éppen az utolsó pont okoz gyakran réseket. Az ügynökség a WordPresst gondozza, a tárhelyszolgáltató a szervert, és mindenki azt hiszi, hogy a másik tartja szemmel a PHP2Shellt.

## Hogyan segít konkrétan a PHP SOS?

- **A rétegek tisztázása:** Megállapítjuk, hogy a WordPress-weboldalánál ki melyik rétegért felel.
- **A PHP frissítése:** Saját vagy menedzselt szervereken telepítjük a PHP-frissítést, és újraindítunk minden folyamatot.
- **A WordPress ellenőrzése:** Egy támadás nyomait keressük fájlokban, adatbázisban és fiókokban.
- **Igazolás:** A javítási állapotot írásban megkapja, az ügynökségnek vagy az ügyfeleknek való továbbadáshoz is.

A folyamatot a [PHP-javítási szolgáltatás](https://phpsos.de/hu/leistungen/php-patch-service/) írja le.

## Összegzés

A WordPress-frissítés jó karbantartás, de a PHP2Shell ellen rossz réteg. A rés egy emelettel lejjebb van, a szerveren lévő PHP-ban. Aki ezt érti, a megfelelő kérdést teszi fel a megfelelő helyen: javított-e a PHP, újraindították-e, és igazolt-e?


## Gyakori kérdések

**Hoz a WordPress biztonsági frissítést a PHP2Shell ellen?**  
A Dr. Web szerint a WordPress.org nem tervez frissítést a PHP2Shell ellen, mert a rés a szerveren lévő PHP-értelmezőben van. Megoldást csak a tárhelyszolgáltató vagy a szerverüzemeltető által végzett PHP-frissítés hoz.

**Hol látom a WordPressben a PHP-verziót?**  
A vezérlőpulton az Eszközök, Weboldal állapota alatt, a Jelentés részben a Szerver szakasznál. A kijelzett szám azonban nem mondja meg biztosan, hogy a javítás telepítve van-e, mert a tárhelyszolgáltatók a javításokat gyakran új verziószám nélküli backportként építik be.

**Véd egy biztonsági bővítmény a PHP2Shell ellen?**  
Csak nagyon korlátozottan. Egy bővítmény maga is PHP-ban fut, és csak akkor lesz aktív, ha a WordPress betöltődött. Apache és mod_php esetében a PHP-csapat szerint azelőtt mutattak be egy exploitot, hogy egyáltalán alkalmazáskód futna. Ott egy bővítmény nem tud beavatkozni.

**Frissítsem mégis a WordPresst?**  
Igen. A WordPress, a témák és a bővítmények aktuális verziói más réseket zárnak be, és a jó karbantartás részei. Csak a PHP2Shell problémáját nem oldják meg.

## Források

- [Dr. Web: PHP2Shell, PHP-verziók frissítése](https://www.drweb.de/php2shell-update-php-versionen/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [WordPress.org](https://wordpress.org/)
- [Cloudflare-blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
