Egyetlen hét kellett hozzá. Július közepén nyilvánosságra hozták a wp2shell nevű sebezhetőséget, és mire másnap reggel felébredtél, a WordPress-t használó szervezetek 60%-ánál volt legalább egy érintett telepítés.Nem kellett jelszó, nem kellett előfizetői fiók, nem kellett semmi. Egy jól összerakott kérés a szervernek, és a támadó már adminként sétált be az oldaladra.
A neve játékos wp2shell (WordPress to shell), de a hatása egyáltalán nem az. Két, önmagában talán kezelhető hibát láncoltak össze úgy, hogy a végén teljes szerverirányítást kaptak a támadók, adatbázis-hozzáféréstől kezdve fájlfeltöltésig. A CISA, az amerikai kiberbiztonsági hatóság, négy nappal a nyilvánosságra hozatal után már a kritikus, aktívan kihasznált sebezhetőségek listáján tartotta.
Ha most azt gondolod, „ez engem nem érint, rég frissítettem”, jó eséllyel igazad van. Ha viszont bizonytalan vagy, vagy pont most jut eszedbe, mikor is futott le utoljára az automatikus frissítés,ez a cikk pontosan elmondja, mit csinálj most, és mit érdemes átgondolnod, hogy legközelebb ne érjen felkészületlenül egy hasonló hiba.
Mi az a wp2shell, és miért érdekel ez akkor is, ha nem vagy fejlesztő?
A wp2shell két WordPress-hibát kapcsol össze (CVE-2026-63030 és CVE-2026-60137)úgy, hogy egy támadó bejelentkezés nélkül, pár másodperc alatt admin jogot szerezhet az oldaladon. Nem kell ismernie egyetlen jelszavadat sem ahhoz, hogy átvegye az irányítást.
Normál esetben egy WordPress oldal feltöréséhez kell valami: ellopott jelszó, gyenge plugin, egy jól időzített adathalász email. A wp2shellnél semmi ilyesmire nincs szükség, mert maga a WordPress motorja hibázik. Ez nem egy „megint egy plugin sebezhetőség” sztori, hanem core probléma, ami minden érintett verziójú telepítést fenyeget, függetlenül attól, milyen témát vagy pluginokat használsz.
Hogyan törnek be vele – egyszerűen elmagyarázva
A WordPress REST API-jának van egy „batch” funkciója, ami egyszerre több apró kérést tud feldolgozni. Ebben egy hiba miatt a rendszer összekeveri, ki küldte az adott kérést, és ezt kihasználva a támadó bejelentkezés nélkül tud olyan parancsokat futtatni, amikhez normál esetben admin jog kellene.
1. lépés: kicselezik a bejelentkezést
A batch endpoint arra való, hogy egyszerre több apró kérést lehessen elküldeni a szervernek, mondjuk öt beállítást egyszerre menteni. A hiba miatta WordPress rosszul dolgozza fel ezt a köteget, és egy speciálisan összeállított kéréssel a rendszer azt hiszi, jogosult felhasználó parancsát hajtja végre. Ez maga a CVE-2026-63030, az auth bypass.
2. lépés: befészkelik magukat az adatbázisba
Miután bejutottak, egy másik hibát használnak ki (CVE-2026-60137), ami egy rosszul megszűrt keresési paraméterben rejlik a WordPress lekérdezőrendszerében.Ezzel közvetlenül az adatbázisból tudnak adatot kiolvasni, vagy akár bele is írni. Ez a klasszikus SQL injection, csak épp úgy, hogy hozzá se kell férned semmihez előtte.
3. lépés: kaput nyitnak maguknak a jövőre is
Innentől a megfigyelt esetek szerint a támadók admin fiókot hoznak létre, kártevő pluginokat töltenek fel, és van, aki egy 150 KB-os webshellt csempészett be, ami egy CMSmap nevű biztonsági bővítménynek álcázta magát. Gondolj bele, épp azt a réteget hazudják el, ami miatt bíznál a saját oldaladban. Volt, ahol egy Overlord nevű távoli hozzáférést adó kártevőt is telepítettek, hogy a javítás után is vissza tudjanak jutni.
A számok, amik miatt ez nem egy szokásos biztonsági hír
A Wiz biztonsági kutatói szerint a nyilvánosságra hozatal pillanatában a WordPress-t használó szervezetek 60%-ánál volt legalább egy sebezhető telepítés, ebből 25%-uk nyíltan elérhető volt az internetről.
| Időpont | Sebezhető szervezetek | Nyilvánosan elérhető |
|---|---|---|
| Publikáláskor | 60% | 25% |
| 24 óra múlva | 50% | 10% |
Ez pontosan annyit jelent, hogy 24 óra elteltével is még mindig minden második érintett szervezet nyitva hagyta az ajtót, miközben a javítás már elérhető volt. Százezres nagyságrendű kihasználási kísérletet regisztráltak, és több mint 100 backdoor admin fiókot azonosítottak a megfigyelt támadásokban.
Érintett-e a te WordPress-oldalad?
Ha 6.9.5 vagy 7.0.2 alatti core verziót futtatsz, jó eséllyel érintett vagy. Az SQL injection önmagában már a 6.8-as ágtól jelen van, a teljes, jelszó nélküli feltörési lánc pedig a 6.9-es és 7.0-s ágakat érinti.
Az érintett verziók listája
| Ág | Érintett | Javított |
|---|---|---|
| 6.8.x (csak SQLi) | 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | 7.0.0–7.0.1 | 7.0.2 |
| 7.1 (beta) | korábbi bétaverziók | 7.1 Beta 2 |
Hogyan ellenőrizd 2 perc alatt a saját verziódat
Jelentkezz be az admin felületre, és nézd meg az Irányítópult alján vagy a Frissítések menüpontban a core verziószámot. Ha a tárhelyeden van saját WordPress kezelőfelület, ott is látod egy pillantással, és onnan frissíthetsz is, anélkül hogy külön be kellene jelentkezned a WP adminba.
Mit csinálj, ha még nem frissítettél, vagy nem vagy benne biztos
Frissíts azonnal a legújabb core verzióra, aztán nézd át az admin fiókokat és a fájlrendszert gyanús nyomokért. A frissítés önmagában nem távolítja el azt, amit egy esetleges korábbi támadó már beültetett.
Frissíts azonnal, de előtte nézd meg ezt
Mielőtt frissítesz, csinálj egy friss mentést. Ha valami rossz irányba menne el a frissítés közben, legalább van hova visszaállni. Ha ezt eddig sosem csináltad automatikusan, ez a sebezhetőség pont egy jó indok arra, hogy most bekapcsold.
Ellenőrizd az admin fiókokat
Nézd át a felhasználói listát, és keress ismeretlen admin fiókokat, vagy olyanokat, amiket nem te hoztál létre. Ha találsz egyet, ne csak töröld, hanem ellenőrizd azt is, mikor jött létre, mert az segít behatárolni, mióta lehet a rendszered kompromittálva. Ha a jelszavaidban is bizonytalan vagy,ez alapján érdemes új, erős jelszót választanod.
Keress gyanús fájlokat a cache mappában
A megfigyelt támadásokban a webshellt gyakran awp-content/cache mappába írták, furcsa, véletlenszerű nevű PHP fájlokként. Ha ilyet találsz egy olyan mappában, ahol elvileg csak gyorsítótárazott fájloknak kéne lenniük, az önmagában gyanús jel.
Mikor van szükség mentésből való helyreállításra
Ha gyanús admin fiókot vagy fájlt találsz, jobb egy tiszta, a probléma előtti mentésből visszaállni, mint fájlonként vadászni a kártevő után. Egy backdoor pont attól backdoor, hogy nem biztos, hogy mindet megtalálod elsőre.
A valódi tanulság: mi véd meg a következő hasonló sebezhetőségtől
Az automatikus frissítés, a rendszeres mentés és a minimális admin fiókszám hármasa az, ami tényleg megvéd, nem az, hogy milyen gyorsan reagálsz egy hírre.
Az automatikus frissítést a józan ész diktálja
Sokan kikapcsolják az automatikus frissítést, mert félnek, hogy egy plugin elszáll tőle. Érthető félelem, csak közben pont ez a döntés hagyta nyitva a szervezetek felét 24 órával a javítás megjelenése után is. Ha a frissítés miatti kockázatot mérlegeled, tedd hozzá a másik oldalra is a tétet: jelszó nélküli, teljes admin hozzáférés bárkinek, aki tudja, hova kell küldeni egy kérést.Ha a teljes biztonsági alapokat is átnéznéd, itt egy jó kiindulópont.
A mentés az, ami tényleg megment, nem a frissítés sebessége
Ha az oldaladat már kompromittálták a javítás előtt, maga a frissítés nem törli ki a becsempészett backdoort. A frissítés a bejárati ajtót zárja be, de ha közben már bent volt valaki, és hagyott magának egy másik kulcsot, azt külön kell megkeresni, vagy egyszerűen visszaállni egy olyan mentésből, ahol biztosan még nem volt ott.
Amit tárhely szinten érdemes ellenőrizni
Egy jó tűzfal vagy webalkalmazás-védelem (WAF) blokkolhatja a gyanús REST API kéréseket még azelőtt, hogy elérnék a WordPress-t. Az admin bejelentkezési felület elrejtése vagy korlátozása pedig eggyel nehezebbé teszi a dolgát bárkinek, aki automatikusan próbálkozik.Itt egy útmutató arról, hogyan rejtsd el a WordPress admin bejelentkezési oldaladat.
Gyakori kérdések a wp2shell sebezhetőségről
Mi az a wp2shell?
Két összekapcsolt WordPress core hiba (CVE-2026-63030 és CVE-2026-60137), amivel egy támadó bejelentkezés nélkül, jelszó ismerete nélkül admin jogot szerezhet egy WordPress oldalon, és onnan teljes szerverirányítást is elérhet.
Kell-e félned, ha eddig nem hallottál róla?
Ha a WordPress core verziód 6.9.5, 7.0.2 vagy újabb, nem vagy érintett. Ha nem vagy biztos benne, ellenőrizd az admin felületen a verziószámot, és frissíts, ha szükséges.
Honnan tudom, hogy feltörték az oldalamat?
Nézd át a felhasználói listát ismeretlen admin fiókokért, ellenőrizd awp-content/cache mappát furcsa nevű PHP fájlokért, és nézd meg, telepítve van-e olyan plugin, amit nem te tettél fel.
Elég, ha csak a pluginjaimat frissítem?
Nem. Ez a hiba a WordPress core-ban van, nem egy pluginban. Bármilyen naprakész pluginkészlet mellett is sebezhető maradsz, ha a core verziód érintett.
Mennyi idő alatt lehet kihasználni ezt a sebezhetőséget?
Pár másodperc alatt, egyetlen jól összeállított kéréssel. Nincs szükség próbálkozásra vagy időigényes feltörésre, ezért terjedt ilyen gyorsan a kihasználása a nyilvánosságra hozatal után.
Mi történik, ha nem frissítek?
Jelszó nélkül hozzáférhet valaki az admin felületedhez, kártevő pluginokat tölthet fel, backdoor fiókot hozhat létre, és akár távoli hozzáférést biztosító kártevőt is telepíthet, ami a frissítés után is bent maradhat, ha addig nem távolítod el.
Összefoglalás
A wp2shell nem egy futótűzként elhaló hír volt, hanem egy jó példa arra, mi történik, ha egy alapvetően megbízhatónak hitt rendszer, maga a WordPress core, hibázik. A technikai részletek bonyolultnak tűnhetnek, de a teendő egyszerű: naprakész core verzió, átnézett admin fiókok, és egy mentés, amire tényleg számíthatsz, ha valami mégis történik.
Ha ezt az utolsó pontot még nem oldottad meg rendesen, most van itt az ideje. Nézd át, hogyan állsz a WordPress alapvető biztonsági beállításaival, és ha bizonytalan vagy a jelszavaid erősségében, azon is érdemes most változtatni, mielőtt a következő ehhez hasonló sebezhetőség megjelenik.
Források:
- https://thehackernews.com/2026/07/wordpress-wp2shell-exploitation-grows.html
- https://www.rapid7.com/blog/post/etr-cve-2026-63030-wp2shell-a-critical-remote-code-execution-vulnerability-in-wordpress-core/
- https://www.wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137
- https://isc.sans.edu/diary/WordPress+Exploitation+Underway+CVE202663030/33168
