Röviden: A WordPress PHP-biztonsági rése, amelyről jelenleg beszámolnak, nem a WordPressben van, hanem az alatta lévő szerver PHP-jában. Egy WordPress-frissítés ezért nem zárja le a PHP2Shellt. A döntő a PHP javítási állapota, az összes PHP-folyamat újraindítása és a tipikus rejtekhelyek, például a wp-content/uploads és a mu-plugins ellenőrzése.
Miért nem szünteti meg a WordPress-frissítés a PHP2Shellt
A WordPress PHP-ban írt alkalmazás. A CVE-2026-109618 és a CVE-2026-109619 rések egy szinttel lejjebb, magában a PHP-értelmezőben vannak. A PHP-csapat szerint lehetővé teszik kártékony kód távoli futtatását bejelentkezés nélkül. Apache és mod_php esetén már azelőtt bemutattak egy exploitot, hogy bármilyen WordPress-kód futna.
Egy naprakész maggal, naprakész bővítményekkel és erős jelszavakkal rendelkező weboldal tehát mégis támadható lehet, ha az alatta lévő PHP régi. Fordítva, egy javított PHP nem bizonyítja, hogy korábban nem történt semmi. A háttérről a Mi az a PHP2Shell? oldalon írunk.
| Szint | Ki frissít | Lezárja a PHP2Shellt? |
|---|---|---|
| WordPress-mag | Ön vagy az ügynöksége | Nem |
| Bővítmények és témák | Ön vagy az ügynöksége | Nem |
| PHP a szerveren | Tárhelyszolgáltató vagy szerver-rendszergazda | Igen, az összes PHP-folyamat újraindításával együtt |
WordPress PHP biztonsági rés: a PHP-verzió ellenőrzése
A vezérlőpulton az Eszközök > Webhely állapota > Információ alatt, a „Szerver” szakaszban látja azt a PHP-verziót, amellyel a weboldala ténylegesen fut. Ez többet mond, mint a php -v a parancssorban, mert a parancssor gyakran más PHP-telepítést használ, mint a webszerver.
A megjelenített szám önmagában mégsem elég. A javított upstream verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. Sok tárhelyszolgáltató azonban backportként juttatja be a javításokat; ilyenkor továbbra is régebbi szám áll ott, noha a javítás megtörtént. A valós állapot megállapításáról a A PHP-verzió és a javítási állapot helyes ellenőrzése oldalon olvashat. Hogy a WordPress-verziója mely PHP-verziókat támogatja, azt a rendszerkövetelmények szerint a wordpress.org oldalon ellenőrizheti.
Hol szeret elrejtőzni a kártékony kód a WordPressben
Egy sikeres támadás után az elkövetők többnyire hátsó ajtót hagynak, hogy a javítás után is visszatérhessenek. A WordPressnek erre ismert helyei vannak:
- wp-content/uploads/: képeknek és PDF-eknek való, nem PHP-fájloknak.
- wp-content/mu-plugins/: a „Must-use” bővítmények automatikusan betöltődnek, és a vezérlőpulton nem kapcsolhatók ki.
- wp-config.php: az adatbázis-hozzáférést és a biztonsági kulcsokat tartalmazza; egy beszúrt sor itt alig tűnik fel.
- .htaccess a főkönyvtárban és az almappákban: csak a keresőmotoroknak szóló átirányítások vagy szokatlan fájlkiterjesztések futtatása.
- Témák, főleg a
functions.php, valamint a kikapcsolt, elfelejtett bővítmények. - Adatbázis: új adminisztrátorok a
wp_userstáblában, idegen JavaScript awp_optionstáblában vagy a bejegyzésekben.
Veszélytelen első ellenőrzések a WP-CLI-vel és a beépített eszközökkel:
# A mag fájljainak összevetése a hivatalos ellenőrző összegekkel
wp core verify-checksums
# A wordpress.org jegyzékéből származó bővítmények ellenőrzése
wp plugin verify-checksums --all
# A feltöltési mappában lévő PHP-fájlok felsorolása
find wp-content/uploads -type f -name "*.php"
# Az összes adminisztrátor megjelenítése
wp user list --role=administrator
Egy találat alapos vizsgálat oka, még nem bizonyíték. A kereskedelmi bővítmények így nem ellenőrizhetők. A részletes folytatás a Hátsó ajtók keresése a WordPressben útmutatóban található.
Ne törölje elhamarkodva a gyanús fájlokat. Először mentse a fájlokat, az adatbázist és a szerver naplóit 2026. 10. 20-tól. E nyomok nélkül később nem tisztázható, hogy elszivárogtak-e adatok.
Bővítmények, témák és admin-hozzáférések mint további kockázat
A PHP2Shellhez nincs szükség bővítményrésre. A mindennapokban azonban a bővítmények és témák maradnak a WordPress-weboldalak leggyakoribb belépési pontjai. Minden bővítmény saját kódot, saját feltöltési funkciókat és saját frissítési ciklust hoz magával. A nem használt bővítményeket töröljék, ne csak kapcsolják ki, mert a kikapcsolt fájlok tovább a szerveren maradnak.
A wp-login.php-ra és a wp-admin-ra az érvényes: kevés adminisztrátor, személyes fiókok megosztott hozzáférések helyett, és kétfaktoros bejelentkezés. Ha nincs szüksége az XML-RPC-re, le lehet tiltani. Gyanú esetén az összes jelszót és a wp-config.php biztonsági kulcsait meg kell újítani. A vezérlőpult fájlszerkesztőjét szintén itt kapcsolhatja ki:
define( 'DISALLOW_FILE_EDIT', true );
Mit tegyenek most a WordPress-üzemeltetők
- Kérje meg a tárhelyszolgáltatót, hogy írásban erősítse meg a PHP javítási állapotát és az összes PHP-folyamat újraindítását.
- Őriztesse meg a szerver naplóit 2026. 10. 20-tól.
- Végezze el vagy végeztesse el a fenti ellenőrzéseket.
- Frissítse a WordPress-t, a bővítményeket és a témákat. Ez helyes, de nem pótolja az 1. lépést.
- Rendellenességek esetén ne üzemeltesse tovább egyszerűen a weboldalt, hanem tisztíttassa meg.
Egy platformfrissítés lezárhatja a WordPress és a bővítmények ismert réseit. A PHP-t nem tudja megjavítani, és nem távolítja el azokat a bejuttatott fájlokat sem, amelyek nem tartoznak a maghoz.
Hogyan segít konkrétan a PHP SOS?
- Önnel vagy a tárhelyszolgáltatójával tisztázzuk a WordPress-weboldala tényleges PHP-állapotát, a backportokat és az újraindítást is beleértve.
- Mentjük a naplókat, a fájlokat és az adatbázist, mielőtt bármit megváltoztatnánk.
- Ellenőrizzük a magot, a bővítményeket, a feltöltéseket, a mu-plugineket, a
.htaccess-t és a felhasználói fiókokat hátsó ajtók szempontjából. - Találat esetén a kártevő-eltávolítási szolgáltatásunk végzi a tisztítást az incidens lezárásáig és dokumentálásáig; találat nélkül a PHP2Shell azonnali segítség keretében megerősítjük a telepítést.
Gyakori kérdések
Frissítenem kell a WordPress-t a PHP2Shell miatt?
A naprakész WordPress mindig ésszerű, de a PHP2Shellt nem zárja le. A rés a szerver PHP-értelmezőjében van. Ehhez PHP-frissítés vagy a tárhelyszolgáltató megerősített backportja, valamint az összes PHP-folyamat újraindítása kell.
Véd egy biztonsági bővítmény a PHP2Shell ellen?
Csak nagyon korlátozottan. A bővítmény maga is PHP-kódként fut a WordPressen belül. A mod_php esetében már azelőtt bemutattak egy exploitot, hogy az alkalmazáskód egyáltalán elindulna; így egy bővítmény a támadást akár észre sem veszi.
Miért mutat a WordPress még régi PHP-verziót, pedig a tárhelyszolgáltató javított?
Sok tárhelyszolgáltató és Linux-disztribúció a javításokat backportként juttatja be a meglévő verzióba. A verziószám ilyenkor ugyanaz marad. Kérje meg a tárhelyszolgáltatót, hogy a javítási állapotot írásban erősítse meg.
Lehet PHP-fájl a wp-content/uploads mappában?
Normál esetben nem. A feltöltési mappa médiafájloknak való. Az ott talált PHP-fájl egyértelmű figyelmeztető jel, és törlés előtt le kell menteni, majd szakszerűen megvizsgálni.