Röviden: A WordPress backdoort úgy találja meg a leggyorsabban, ha a magot és a bővítményeket WP-CLI-vel összeveti a hivatalos ellenőrző összegekkel, majd célzottan átnézi az mu-plugins mappát, a feltöltéseket, a wp-config.php-t, a rendszergazdai fiókokat és az adatbázist. Fontos a PHP2Shell után: egy WordPress-frissítés nem zárja le a PHP-rést, és nem távolít el meglévő hátsó ajtót.
Miért érdemes a WordPress-üzemeltetőknek most alaposabban körülnézniük
A PHP2Shell révén 2026 októberében vált ismertté két kritikus rés magában a PHP-ban, a CVE-2026-109618 és a CVE-2026-109619. Lehetővé teszik kártékony kód futtatását bejelentkezés nélkül, függetlenül attól, mennyire gondozott a WordPress-telepítése. Javítások 2026. 10. 21. óta érhetők el, médiabeszámolók szerint azonban az első támadási kísérletet már 10. 17-én megfigyelték.
Akinek a rendszere ebben az időszakban sebezhető volt, annak nyomokat kell keresnie. A WordPress ilyenkor tipikus célpont, mert sok telepítés hasonlóan épül fel, és a támadók ismerik a rejtekhelyeket. Hogy mit kell az üzemeltetőknek általában tenniük a PHP2Shell kapcsán, azt a WordPress és a PHP2Shell oldal írja le.
A következő vizsgálatokat lehetőleg egy másolaton vagy mentés után végezze el. A parancsok csak olvasnak, és nem változtatnak semmin.
Miről veheti észre a backdoort a mindennapokban
A hátsó ajtót úgy tervezik, hogy feltűnésmentes maradjon. Mégis vannak jelek, amelyek technikai tudás nélkül is szembetűnnek. Ide tartoznak az idegen oldalakra irányuló átirányítások, amelyek csak a Google-keresésből érkező látogatóknál vagy csak mobileszközökön jelentkeznek. Ugyanígy gyanúsak a gyógyszerek, szerencsejáték vagy márkás termékek másolatainak hirdetésével készült új oldalak, amelyek megjelennek a keresőindexben, de a WordPress admin felületén nem.
További jelek: a Google vagy a böngésző figyelmeztetései, ügyfelek panaszai a domainjéről érkező spamlevelek miatt, a tárhelyszolgáltatónál hirtelen jelentősen megnövekedett számítási idő, vagy olyan rendszergazdák, akiket a csapatban senki sem ismer. E jelek egyike sem bizonyít önmagában backdoort. Ha többször együtt jelentkeznek, ne halogassa a következő vizsgálatokat.
Fordítva is igaz: ha ezek közül semmi sem tűnik fel, az nem jelenti, hogy a telepítés tiszta. Éppen a csak egy későbbi hozzáféréshez létrehozott hátsó ajtók kifelé gyakran semmilyen hatást nem mutatnak.
WordPress backdoor keresése: a mag és a bővítmények ellenőrzése
A WP-CLI a WordPress magjának és a bővítményeknek a fájljait össze tudja vetni a hivatalos jegyzékből származó, közzétett ellenőrző összegekkel. Minden eltérés konkrét vizsgálati feladat.
cd /var/www/meine-seite
# Alapfájlok a hivatalos ellenőrző összegekkel szemben
wp core verify-checksums
# A hivatalos jegyzékből származó bővítmények
wp plugin verify-checksums --all
# Telepített verziók és állapot
wp plugin list
wp theme list
A kereskedelmi bővítményeket és témákat így nem lehet ellenőrizni. Náluk csak egy frissen letöltött, a szolgáltató eredeti csomagjával való összevetés segít. Az ismeretlen bővítmények, amelyeket senki sem telepített a csapatból, mindig gyanúsak, még ha le is vannak tiltva.
Tipikus rejtekhelyek a fájlrendszerben
Néhány hely újra és újra felbukkan a feltört WordPress-telepítéseknél:
wp-content/mu-plugins/: automatikusan betöltődik, és nem jelenik meg a szokásos bővítménylistában.wp-content/uploads/: oda képek és dokumentumok valók, nem PHP-fájlok.wp-config.php: továbbiincludevagyrequiresorok az elején vagy a végén..htaccessés.user.inia webkönyvtárban és az almappákban: váratlan átirányítások vagy automatikusan előre betöltött fájlok.- A főkönyvtárban lévő fájlok, amelyek neve a WordPress alapfájljaira emlékeztet, de nem tartoznak hozzá.
# PHP-fájlok a feltöltési mappában
find wp-content/uploads -type f -name "*.php*"
# A must-use bővítmények tartalma
ls -la wp-content/mu-plugins/
# Az összes .htaccess és .user.ini fájl módosítási dátummal
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Nemrég módosított PHP-fájlok
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Az elfedett kód általános keresési mintáit a Webshellek felismerése és eltávolítása útmutató írja le.
Felhasználók, adatbázis és ütemezett feladatok ellenőrzése
Sok hátsó ajtó egyáltalán nem a fájlrendszerben van. Egy további rendszergazdai fiók a támadóknak gyakran elég ahhoz, hogy később visszatérjenek.
# Az összes rendszergazda regisztrációs dátummal
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Ütemezett feladatok a WordPressben
wp cron event list
# Az oldal címe (a manipulációk átirányításokhoz vezetnek)
wp option get siteurl
wp option get home
# Beágyazott szkripteket tartalmazó bejegyzések
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Ellenőrizze a szokatlanul nagy tartalmú opciókat és az idegen kódot tartalmazó widgeteket is. A találatok nem jelentenek automatikusan támadást, mert a követőkódok vagy a beágyazott térképek szintén szkripteket használnak. A döntő az, hogy ismeri-e valaki a csapatból a tartalmat.
Egy lelet után cserélje le az összes jelszót és a wp-config.php-ben lévő biztonsági kulcsokat. Különben a támadók meglévő bejelentkezései érvényben maradnak.
Hátsó ajtók lezárása és az újbóli megjelenés megakadályozása
Ha backdoort talált, az újratelepítés többnyire biztonságosabb, mint egyes fájlok javítgatása. Ez a sorrend vált be:
- Mentse a nyomokat: naplókat, gyanús fájlokat és egy adatbázis-exportot dátummal.
- Vigye a PHP-t javított állapotba, és indítsa újra az összes PHP-folyamatot.
- A WordPress magját, a bővítményeket és a témákat telepítse frissen az eredeti forrásokból.
- A feltöltéseket és az adatbázist ellenőrzötten vegye át, törölje az idegen fiókokat, cserélje le az összes hozzáférést.
- Tiltsa a PHP-végrehajtást a feltöltési mappában a szerver szintjén.
Nginx esetén ehhez elég egy blokk a szerverkonfigurációban:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Apache alatt ugyanezt a szerverkonfigurációban a feltöltési mappára vonatkozó szabállyal éri el. Magában a feltöltési mappában lévő .htaccess gyengébb, mert az írási joggal rendelkező támadó ismét megváltoztathatja.
A megtisztítás után tervezzen be néhány hétnyi szorosabb megfigyelést. Az új rendszergazdáknak, az új PHP-fájloknak és a wp-config.php változásainak ebben az időszakban azonnal fel kell tűnniük, például WP-CLI-vel végzett rendszeres ellenőrzéssel vagy a szerveren futó fájlfelügyelettel.
Hogyan állítsa be utána a fájljogokat úgy, hogy a WordPress csak ott írhasson, ahol szükséges, azt a Fájljogosultságok a webszerveren útmutató mutatja meg.
Hogyan segít konkrétan a PHP SOS?
- Lementjük a telepítés állapotát, mielőtt bármit megváltoztatnánk.
- Hátsó ajtók szempontjából ellenőrizzük a magot, a bővítményeket, a témákat, az adatbázist, a fiókokat és a szerverkonfigurációt.
- A WordPresst tiszta forrásokból újra felállítjuk, és csak ellenőrzött tartalmakat veszünk át.
- Megerősítjük a szervert és a telepítést, és dokumentáljuk, mit találtunk és mit hárítottunk el.
A megtisztítás menetét a Kártevők és webshellek eltávolíttatása szolgáltatás írja le.
Gyakori kérdések
Lezárja egy WordPress-frissítés a PHP2Shell rést?
Nem. A PHP2Shell a PHP-értelmezőben van, nem a WordPressben. A WordPress, a témák vagy a bővítmények frissítése ezen nem változtat; a döntő a szerver PHP-állapota és az összes PHP-folyamat újraindítása.
Megtalál egy biztonsági bővítmény minden backdoort?
Nem megbízhatóan. A bővítmény a feltört telepítésen belül fut, és maga is manipulált lehet. Egészítse ki kívülről végzett ellenőrzésekkel, például WP-CLI-s ellenőrző összegekkel és a tiszta eredeti fájlokkal való összevetéssel.
Mik azok az mu-plugins, és miért gyanúsak?
A wp-content/mu-plugins mappában lévő must-use bővítmények automatikusan betöltődnek, és nem jelennek meg a szokásos bővítménylistában. A támadók szívesen használják ezt, mert az üzemeltetők ritkán nézik meg ezt a mappát.
Lehet a backdoor az adatbázisban is?
Igen. A kártékony kódot vagy átirányításokat gyakran az opciókban, a bejegyzésekben vagy a widgetekben helyezik el. A támadók ezen felül gyakran saját rendszergazdai fiókokat hoznak létre, amelyeket a felhasználói táblában talál meg.