Az esettanulmány valós incidensen alapul. Az ügyfél, a domain, a tárhelyszolgáltató, az IP-címek, a felhasználónevek és a tárhelyfiók azonosítására alkalmas adatok nem szerepelnek benne. Egyes elérési utak és parancsrészletek biztonsági okból rövidítve jelennek meg.
Röviden: mi történt?
2026 júliusának végén egy WordPress-weboldalon több kártékony PHP-fájl és egy támadói plugin jelent meg. A hozzáférési naplókból megállapítható volt, hogy a támadók a feltöltött webshell-eken keresztül parancsokat futtattak, feltérképezték a tárhelykörnyezetet, majd egy helyi jogosultságkiterjesztő exploit segítségével root, vagyis rendszergazdai hozzáférést próbáltak szerezni a tárhelyfiókban.
A weboldalon WordPress 7.0.1 futott. Ezt a verziót érintette a CVE-2026-60137 és CVE-2026-63030 sérülékenységekből felépülő, „wp2shell” néven ismert támadási lánc. A nyilvános sérülékenységi adatok, az incidens időpontja, a támadói fájlok és a naplókban látható műveletek alapján ezt a sérülékenységi láncot használták ki.
A helyreállítás és a tárhelyszolgáltató rendszerszintű vizsgálata végül azt mutatta, hogy:
– a WordPress-webhely kompromittálása sikeres volt;
– a webshell-eken keresztüli parancsfuttatás megtörtént;
– a szerver rendszergazdai jogosultságának megszerzésére irányuló kísérlet sikertelen maradt;
– a helyreállítás és biztonsági szigorítás után nem találtunk újabb sikeres behatolást vagy új fertőzött fájlt.
Mi az a wp2shell?
A wp2shell nem egyetlen programhiba, hanem két WordPress-maghibából felépülő sérülékenységi lánc.
Sérülékenység, leírása (Érintett WP verziók) [Javító verziók]
CVE-2026-60137: SQL injection a `WP_Query` `author__not_in` paraméterének kezelésében (6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1) [6.8.6, 6.9.5, 7.0.2]
CVE-2026-63030: Útvonal- és feldolgozási zavar a REST API batch végpontján (6.9.0–6.9.4, 7.0.0–7.0.1) [6.9.5, 7.0.2]
A CVE-2026-60137 önmagában egy adatbázis-lekérdezés manipulálását lehetővé tevő hiba. A CVE-2026-63030 segítségével azonban a támadó hitelesítés nélkül juttathatott jogosulatlan kéréseket a megfelelő WordPress-feldolgozóhoz. A két hiba összekapcsolásával létrehozható volt egy támadó által kezelt rendszergazdai fiók, majd rosszindulatú bővítmény vagy webshell telepítésével távoli kódfuttatás válhatott lehetővé.
Fontos, hogy ehhez a teljes támadási lánchoz nem kellett sebezhető bővítmény. A hiba a WordPress magjában volt, és alapértelmezett telepítésen is kihasználható lehetett. A WordPress biztonsági csapata ezért 2026. július 17-én kényszerített automatikus frissítést engedélyezett az érintett, automatikus háttérfrissítést támogató telepítéseken.
Milyen gyorsan kezdték kihasználni?
A javított WordPress-verziók 2026. július 17-én jelentek meg. A Patchstack az első valós támadási kísérleteket körülbelül 90 perccel a 7.0.2 kiadása után észlelte. A következő napokban több mint 65 000 próbálkozást blokkoltak, több mint 1500 különböző forrás-IP-ről. Ezek a kérések ténylegesen javítatlan WordPress-verziókat futtató webhelyeket céloztak.
A Wordfence saját védett ügyfélkörében július végéig már több mint 11 millió exploitkísérletet blokkolt. A tömeges támadások július 18-án, vagyis a javítás megjelenését követő napon indultak be igazán.
Ezek a számok nem 11 millió sikeresen feltört weboldalt jelentenek. Ugyanazt a webhelyet többször, akár több ezer alkalommal is támadhatták. Megbízható nyilvános összesítés jelenleg nincs a sikeresen kompromittált egyedi webhelyek teljes számáról. Több biztonsági vállalat ugyanakkor sikeres támadásokat, jogosulatlan adminisztrátori fiókokat, rosszindulatú pluginokat és tartós PHP-webshell-eket is megfigyelt.
Az incidens idővonala
Július 17.: megjelenik a javítás
A WordPress kiadta a 7.0.2, 6.9.5 és 6.8.6 biztonsági verziókat. A vizsgált webhelyen azonban továbbra is a teljes wp2shell lánccal érintett WordPress 7.0.1 futott.
Július 21.: megjelennek az első kártékony fájlok
A naplóadatok elemzése alapján július 21-én sikeres Batch kérések sora, majd sikeres WP-belépés történt végül elérhető lett az admin/pluginfeltöltő oldal.
Július 27: kártékony plugin feltöltése
Batch exploit → WP-admin → wp2shell-26a97f006dcc bővítmény sikeres feltöltése és aktiválása.
Július 31: ál-theme
A wp-content/themes/flavor_2d4e9ef4/cox_a4cfc709.php webshell elérhető volt. Sikeres POST és PUT kérések történtek.
Augusztus 1: webroot feletti rész megfertőzése
A tárhely webroot feletti cagefs/tmp mappájába kártékony fájlok feltöltése. Többségük obfuszkált PHP-fájlfeltöltő, de az egyik egy olyan python fájl volt, amelyik a CVE-2026-43503 Linux kernel-sérülékenységet próbálta kihasználni, hogy root-szintű jogosultságot szerezzen. A támadó által futtatott ellenőrző kérésekből látszott, hogy a támadó nem állt meg a WordPress feletti ellenőrzés megszerzésénél. Megpróbált a tárhelyfiók jogosultságából magasabb, szerveroldali jogosultságot szerezni, majd felmérni, hogy milyen további fiókok vagy webhelyek lehetnek elérhetők. Szerencsére a szerveren futó operációs rendszer és kernel naprakész védelmi javításokkal (patch) rendelkezett, így a támadók által futtatott exploit nem tudott sikeresen lefutni., a támadó nem tudott root-szintű jogosultságra szert tenni.
További támadói nyom a webgyökéren kívül
A tárhelyszolgáltató a helyreállítás előtti időszakból egy `getheader.alfa` nevű állományt is talált a tárhelyfiók `.cagefs/tmp/alfacgiapi` könyvtárában. A malware-ellenőrzés ismert AlfaShell/backdoor mintaként azonosította. A fájl shellkörnyezetben használható fordítókat, parancsértelmezőket, letöltőeszközöket és egyéb segédprogramokat keresett.
Mi volt bizonyítható, és mi nem?
Az incidens értékelésénél külön kellett választani a bizonyított eseményeket a valószínű következtetésektől.
Bizonyított események
– A WordPress-webhelyen több kártékony PHP-fájl és rosszindulatú plugin jelent meg.
– A támadók legalább egy webshellt sikeresen elértek és parancsfuttatásra használtak.
– A hozzáférési naplóban a webshell ellenőrzése és több rendszerparancs továbbítása is látható volt.
– Megpróbálták futtatni a `/tmp/dc.py` helyi jogosultságkiterjesztő exploitot.
– Ellenőrizték, hogy létrejött-e a `firefart` nevű root-rendszerfelhasználó.
– A tárhelykörnyezet és további fiókok feltérképezésére utaló parancsokat adtak ki.
Nagy valószínűséggel megállapítható
– A kezdeti behatolás a WordPress 7.0.1-et érintő wp2shell sérülékenységi lánchoz kapcsolódott.
– Az incidens egy automatizált vagy részben automatizált, széles körű kampány része volt, nem pedig kifejezetten az adott webhely ellen előkészített célzott támadás.
A helyreállítás lépései
Az oldal azonnali elkülönítése
A webhely hozzáférését `.htaccess` szabállyal ideiglenesen egy megbízható IP-címre korlátoztuk. Ez megakadályozta, hogy a helyreállítás alatt a támadók vagy a nyilvánosság elérjék az oldalt.
Bizonyítékmegőrzés
A törlés előtt teljes mentés készült a fertőzött állapotról és megőriztük a hozzáférési naplókat. Erre azért volt szükség, hogy később rekonstruálható legyen a támadói tevékenység, és ellenőrizhető legyen, milyen tartalmi változások vesznének el egy korábbi mentés visszaállításával.
Visszaállítás fertőzés előtti mentésből
A WordPress-fájlokat és az adatbázist egy július 16-i, vagyis a dokumentált fertőzés és a wp2shell nyilvánosságra hozatala előtti mentésből állítottuk vissza. A visszaállítás önmagában nem lett volna elegendő, mert ebben a mentésben még a sérülékeny WordPress-verzió szerepelt.
Azonnali frissítés
Közvetlenül a visszaállítás után megtörtént a WordPress frissítése 7.0.2-re, majd valamennyi telepített bővítmény frissítése. A már nem használt vagy szükségtelen komponenseket külön is ellenőriztük.
Hozzáférések cseréje
Megváltoztattuk:
– a WordPress adminisztrátori jelszavakat;
– az FTP-hozzáférés jelszavát;
– az adatbázis-felhasználó jelszavát;
– a WordPress hitelesítési kulcsait és SALT-értékeit.
A jelszócsere mellett kétfaktoros hitelesítést is bevezettünk az adminisztrátori hozzáféréshez.
WordPress-szintű szigorítás
A helyreállítás részeként:
– letiltottuk az XML-RPC hozzáférést, mert az oldal működéséhez nem volt szükséges;
– korlátoztuk a WordPress-felhasználók REST API-n keresztüli felsorolását;
– letiltottuk az `?author=1` jellegű szerzőfelderítést;
– ellenőriztük az adminisztrátorokat, a pluginokat, a témákat és az ütemezett feladatokat;
– újabb teljes malware-ellenőrzést végeztünk.
Ezek a szigorítások nem helyettesítik a biztonsági frissítést, de csökkentik a feleslegesen elérhető támadási felületet.
Utólagos naplóellenőrzés
A helyreállítást követő napokban a HTTP- és HTTPS-naplókat külön is átvizsgáltuk. További automatizált bejelentkezési és sérülékenységkereső próbálkozások érkeztek, de a rendelkezésre álló naplókban nem találtunk újabb sikeres fájlfeltöltést, webshell-elérést, támadói parancsfuttatást vagy jogosulatlan adminisztrátori hozzáférést.
Mit vizsgált meg a tárhelyszolgáltató?
A weboldal helyreállítása csak a tárhelyfiók szintjét fedhette le. Mivel a naplókban helyi jogosultságkiterjesztési kísérlet szerepelt, a tárhelyszolgáltató központi rendszergazdái szerver- és rendszerszintű ellenőrzést végeztek.
A szolgáltatói vizsgálat az alábbi eredményre jutott:
– a szerver operációs rendszere és kernelje rendelkezett a szükséges biztonsági javításokkal;
– a `dc.py` fájl (szerver root-hozzáférési jogosultság szerzési) exploit nem tudott sikeresen lefutni;
– nem jött létre jogosulatlan rendszerfelhasználó;
– az audit- és hitelesítési naplókban nem volt sikeres rendszergazdai jogosultságszerzés;
– nem keletkezett illetéktelen SSH-kulcs;
– nem jött létre támadói rendszercron;
– nem módosult rendszerfájl;
– a `/tmp`, `/var/tmp` és `/dev/shm` könyvtárakban nem maradt további kártékony fájl;
– a kompromittálás a tárhelyfiók és a WordPress jogosultsági szintjén maradt.
Az ellenőrzés azt is megerősítette, hogy a biztonsági szigorítások óta nem történt újabb sikeres bejutás, és nem jelent meg új fertőzött fájl a tárhelyen.
Miért nem volt elég egy víruskeresés?
Egy fájlszintű malware-ellenőrzés meg tudja találni az ismert kártékony állományok egy részét, de önmagában nem válaszol minden fontos kérdésre:
– Hogyan jutott be a támadó?
– Használta-e ténylegesen a webshellt?
– Milyen parancsokat futtatott?
– Megpróbált-e magasabb jogosultságot szerezni?
– Sikerült-e kijutnia a tárhelyfiók korlátozott környezetéből?
– Maradt-e rendszeroldali perzisztencia?
Ebben az esetben a fájlok, a webes hozzáférési naplók és a szolgáltatói audit együtt adtak értékelhető képet. A kártékony PHP-fájl bizonyította a fertőzést, a HTTP 200 válaszok és a parancsparaméterek az aktív használatot, a rendszernaplók pedig azt, hogy a root szintű kísérlet nem járt sikerrel.
A legfontosabb tanulságok
A WordPress-mag frissítése ugyanolyan fontos, mint a pluginoké
A wp2shell esetében nem egy elhanyagolt harmadik féltől származó bővítmény volt a feltétel. A teljes támadási lánc a WordPress magjában működött. Egy alaptelepítés is érintett lehetett.
Kritikus frissítésnél az órák is számítanak
A Patchstack körülbelül 90 perccel a biztonsági kiadás után már támadási kísérleteket látott. A „majd a következő karbantartáskor frissítjük” megközelítés ilyen helyzetben napok helyett is túl lassú lehet.
A visszaállítás után azonnal javítani kell a behatolási utat
Egy tiszta, de sérülékeny mentés visszaállítása újra megnyitja ugyanazt a támadási lehetőséget. Ezért a korábbi mentésből való helyreállítást közvetlenül követte a WordPress 7.0.2-re frissítése.
A teljes kivizsgálás több jogosultsági szintet érinthet
A webfejlesztő vagy webhely-üzemeltető a WordPress-, adatbázis- és tárhelyfiók-szintű nyomokat tudja megvizsgálni. A kernel-, audit-, hitelesítési és más rendszernaplókhoz viszont csak a tárhelyszolgáltató fér hozzá. A szolgáltató együttműködése ebben az esetben döntő volt a root kompromittálás kizárásához.
Hogyan ellenőrizhető egy érintett WordPress-webhely?
Ha egy weboldalon 2026. július 17. után is WordPress 6.9.0–6.9.4 vagy 7.0.0–7.0.1 futott, nem elegendő csak most frissíteni. Érdemes visszamenőleg is ellenőrizni:
– az ismeretlen vagy új adminisztrátori felhasználókat;
– a nem várt pluginokat és MU-pluginokat;
– az `uploads`, `plugins`, `.well-known` és webgyökér könyvtárak PHP-fájljait;
– a július 17. óta módosult fájlokat;
– a REST batch végpontra érkező POST-kéréseket;
– az `author_exclude`, `author__not_in`, `UNION`, `SLEEP` vagy gyanúsan egymásba ágyazott `requests` paramétereket;
– a `/wp/v2/users` és `/wp/v2/plugins` végpontokra irányuló batch alkéréseket;
– a véletlenszerű nevű PHP-fájlokra irányuló HTTP 200 válaszokat;
– a rendszerparancsokat tartalmazó URL-paramétereket;
– az ismeretlen cronfeladatokat, SSH-kulcsokat és ideiglenes fájlokat.
A Patchstack megfigyelése szerint a kizárólag URL-alapú WAF-szabály megkerülhető lehetett, mert a `rest_route=/batch/v1` érték a POST-törzsben is továbbítható. Emiatt a végpont blokkolása csak átmeneti kiegészítő védelem; az érintett WordPress-verzió frissítése az elsődleges intézkedés.
Összegzés
Ebben az incidensben a támadók sikeresen kompromittáltak egy WordPress-webhelyet, webshell-eket telepítettek, parancsokat futtattak, majd szerveroldali rendszergazdai jogosultság megszerzésével is próbálkoztak. A root exploitkísérlet azonban a szolgáltatói vizsgálat szerint sikertelen maradt, és a fertőzés nem jutott túl a tárhelyfiók jogosultsági szintjén.
A fertőzés előtti mentés visszaállítása, az azonnali WordPress-frissítés, a hozzáférések cseréje, a kétfaktoros hitelesítés, a WordPress-szintű szigorítás, a naplók utólagos ellenőrzése és a tárhelyszolgáltató rendszerszintű auditja együtt tette lehetővé az incidens lezárását.
A történet legfontosabb tanulsága nem pusztán az, hogy rendszeresen frissíteni kell. Hanem az is, hogy egy már megtörtént fertőzés után a „frissítettük és lefuttattunk egy víruskeresőt” nem feltétlenül ad választ arra, mit csinált a támadó, meddig jutott el, és maradt-e tartós hozzáférése.
Ha WordPress- vagy Joomla-weboldalán fertőzésre, ismeretlen fájlokra vagy jogosulatlan hozzáférésre utaló jeleket találtál, a web-coder helyreállítás szolgáltatása segít Önnek is.