# WordPress backdoor keresése: a hátsó ajtók módszeres felderítése

> WordPress backdoor keresése: mag és bővítmények ellenőrzése WP-CLI-vel, adminok, mu-plugins, feltöltések és adatbázis átnézése, hátsó ajtók lezárása.

Forrás: https://phpsos.de/hu/ratgeber/backdoor-wordpress-finden/  
Á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 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](https://phpsos.de/hu/plattformen/wordpress/) 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.

```bash
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ábbi `include` vagy `require` sorok az elején vagy a végén.
- `.htaccess` és `.user.ini` a 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á.

```bash
# 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](https://phpsos.de/hu/ratgeber/webshell-erkennen/) ú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.

```bash
# 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.

> **Fontos:**
> 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:

1. Mentse a nyomokat: naplókat, gyanús fájlokat és egy adatbázis-exportot dátummal.
2. Vigye a PHP-t javított állapotba, és indítsa újra az összes PHP-folyamatot.
3. A WordPress magját, a bővítményeket és a témákat telepítse frissen az eredeti forrásokból.
4. 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.
5. 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:

```nginx
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](https://phpsos.de/hu/ratgeber/dateirechte-webserver/) ú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](https://phpsos.de/hu/leistungen/malware-entfernung/) 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.

## Források

- [WordPress.org](https://wordpress.org/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)