Jelszó nélkül hozzáférhettek a WordPress adatbázisához – azonnali frissítés szükséges
Jelszó nélkül hozzáférhettek a WordPress adatbázisához – azonnali frissítés szükséges
Nem egy kétes eredetű bővítmény hibájáról van szó. Nem kellett hozzá ellopott adminisztrátori jelszó, sikeres bejelentkezés vagy felhasználói közreműködés sem.
A WordPress központi rendszerében felfedezett sérülékenységek lehetővé tehették, hogy egy külső támadó hitelesítés nélkül manipuláljon adatbázis-lekérdezéseket. Az érintett WordPress-verziók egy részénél ezt egy másik hibával összekapcsolva távoli kódfuttatásig is tovább lehetett vinni.
A javítások 2026. július 17-én jelentek meg. Az érintett weboldalakat haladéktalanul frissíteni kell.
Amennyiben weboldalán WordPress 6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0 vagy 7.0.1 fut, a webhely sérülékeny verziót használ.
Ezúttal nem lehet a bővítményekre mutogatni
A WordPress-szel kapcsolatos biztonsági hírek jelentős része elavult vagy rosszul megírt bővítményekről és sablonokról szól. Emiatt könnyű abba a hamis biztonságérzetbe ringatni magunkat, hogy egy kevés bővítményt használó weboldal automatikusan biztonságos.
Most azonban a WordPress magjában, vagyis magában a központi tartalomkezelő rendszerben találtak két összekapcsolható hibát:
- CVE-2026-60137: SQL injection sérülékenység a WordPress 6.8-as és újabb érintett verzióiban;
- CVE-2026-63030: a REST API batch végpontjának útvonal-kezelési hibája, amely a fenti SQL injection hibával összekapcsolva hitelesítés nélküli támadást tett lehetővé a WordPress 6.9-es és 7.0-s érintett verzióiban.
A WordPress 6.9 2025. december 2-án jelent meg. A biztonsági javítás 2026. július 17-én érkezett meg. A súlyosabb támadási lánc alapjául szolgáló hiba tehát 227 napig volt jelen az éles WordPress-kiadásokban.
Mit jelent az SQL injection?
A weboldal működése közben a WordPress folyamatosan adatbázis-lekérdezéseket állít össze. Ezekkel keresi ki többek között a bejegyzéseket, felhasználókat, beállításokat és webáruházi adatokat.
A felhasználótól vagy egy külső kéréstől érkező adatokat ilyen lekérdezésekbe csak szigorú ellenőrzés és tisztítás után szabad beilleszteni. Ellenkező esetben a beküldött szöveg nem egyszerű adatként, hanem az adatbázisnak szóló parancs részeként viselkedhet.
Ez az SQL injection lényege.
A sérülékeny WordPress-kódrészlet az author__not_in paraméter értékeit illesztette be az adatbázis-lekérdezésbe:
$author__not_in = implode( ',', (array) $query_vars['author__not_in'] ); $where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";Az ellenőrzés nem minden lehetséges bemeneti formánál kényszerítette az értékeket egész számokká. Emiatt megfelelően kialakított bemenet kerülhetett közvetlenül az SQL-parancsba.
A javítás már minden beküldött értékből ellenőrzött számazonosító-listát készít:
$author__not_in_id_list = wp_parse_id_list( $query_vars['author__not_in'] );Technikailag egyetlen hiányzó adatellenőrzésről beszélünk. Üzletileg azonban arról, hogy illetéktelen személy hozzáférhetett a weboldal adatbázisában tárolt információkhoz.
A második hiba megkerülhette az útvonalak jogosultság-ellenőrzését
A WordPress REST API részeként 2020 decembere óta létezik egy batch végpont. Ennek segítségével a fejlesztők több API-kérést csomagolhatnak egyetlen kérésbe.
A végpont többek között az alábbi útvonalon érhető el:
/wp-json/batch/v1A batch feldolgozása során a WordPress külön listában tárolta:
- az egyes részfeladatokhoz tartozó útvonalkezelőket;
- valamint a részfeladatok ellenőrzési eredményeit.
A két lista csak akkor használható biztonságosan, ha mindig ugyanannyi elem található bennük, és az azonos sorszámú elemek valóban összetartoznak.
A sérülékeny verziókban ez nem minden esetben teljesült. Ha egy batch kérés egyik eleme nem megfelelő útvonalat tartalmazott, az egyik lista bővült, a másik azonban nem. Ettől kezdve a sorszámozás elcsúszhatott, és egy későbbi kérés ellenőrzése nem feltétlenül ahhoz az útvonalkezelőhöz tartozott, amely végül végrehajtotta.
Ez az úgynevezett route confusion, vagyis útvonal-összekeverési hiba.
A javítás ebben az esetben is feltűnően kicsi: a WordPress gondoskodik róla, hogy a két belső lista akkor is azonos hosszúságú maradjon, amikor valamelyik részfeladathoz nem talál használható útvonalat.
A hiba mérete azonban semmit nem mond a következmény méretéről.
Biztosan távoli kódfuttatást tett lehetővé?
A WordPress hivatalos közleménye, a hibát bejelentő Searchlight Cyber és a Cloudflare is távoli kódfuttatással járó sérülékenységi láncként írja le a problémát.
A nyilvános technikai közlések között azonban van egy fontos eltérés.
A Searchlight Cyber szerint a támadás egy alapértelmezett WordPress-telepítésen, bővítmények nélkül és különleges előfeltételek nélkül is végrehajtható volt. A Cloudflare ezzel szemben azt írja, hogy a távoli kódfuttatási útvonal akkor működik, amikor a weboldal nem használ tartós objektum-gyorsítótárat.
Ez a két megfogalmazás nem teljesen ugyanaz.
Ezért a jelenleg felelősen megfogalmazható következtetés a következő:
- a hitelesítés nélkül elérhető támadási útvonal valós;
- az SQL injection sérülékenység valós;
- az adatbázisban tárolt érzékeny információk veszélybe kerülhettek;
- a WordPress és több biztonsági vállalat szerint a lánc távoli kódfuttatáshoz is vezethetett;
- a kódfuttatási útvonal pontos technikai feltételeiről a nyilvános közlések nem teljesen egységesek.
A webhelytulajdonos szempontjából azonban ez nem változtat a teendőn. Nem érdemes arra fogadni, hogy az Ön tárhelyének beállítása talán megakadályozta a támadás legsúlyosabb változatát.
A nyilvános javítás egyben térkép a támadóknak
A WordPress nyílt forráskódú rendszer. Ez komoly előny: a kód ellenőrizhető, fejleszthető és független szakértők által vizsgálható.
A nyílt forráskódú javításnak azonban van egy elkerülhetetlen következménye is. Amikor megjelenik a biztonsági frissítés, bárki egymás mellé teheti a régi és az új kódot, majd megnézheti, mit változtattak meg.
Amennyiben három fájlban néhány sor módosul, a javításból sok esetben gyorsan visszafejthető a sérülékenység működése.
Nem szükséges hozzá belső információ vagy kiszivárogtatott dokumentáció. Elég elolvasni a javítást.
Ezért van rendkívül kevés idő a biztonsági frissítések telepítésére. A javítás közzététele után nem hetekben, hanem órákban mérhető az az idő, amíg megjelennek az első technikai elemzések, automatikus keresők és támadási kísérletek.
A WordPress már 2017-ben megtapasztalta ugyanezt
2017 januárjában szintén a WordPress REST API egyik hibája tette lehetővé, hogy bejelentkezés nélküli támadók módosítsák weboldalak tartalmát.
A WordPress akkor csendben adta ki a javítást, majd néhány nappal később hozta nyilvánosságra a sérülékenységet. A cél az volt, hogy az automatikus frissítések előbb eljussanak a weboldalakhoz.
A nyilvánosságra hozatal után a támadók gyorsan kihasználták a hibát. A Wordfence akkori mérése szerint rövid időn belül közel 1,9 millió megrongált vagy átírt weboldaloldalt indexelt a Google.
A tanulság nem az, hogy a WordPress biztonsági csapata ne publikálja a javításokat. A tanulság az, hogy a karbantartatlan weboldalak a javítás megjelenése után versenyt futnak az automatizált támadóeszközökkel.
Mely WordPress-verziók érintettek?
| WordPress-verzió | Érintettség | Biztonságos verzió |
|---|---|---|
| 6.8.0–6.8.5 | SQL injection sérülékenység | 6.8.6 |
| 6.9.0–6.9.4 | SQL injection és REST API route confusion | 6.9.5 |
| 7.0.0–7.0.1 | SQL injection és REST API route confusion | 7.0.2 |
| 6.8 előtti verziók | A két most javított sérülékenység nem érinti | Ennek ellenére az elavult főverziók használata nem javasolt |
A WordPress a probléma súlyossága miatt kényszerített automatikus frissítést is elindított az érintett weboldalakon. Ebből azonban nem szabad arra következtetni, hogy minden weboldal biztosan frissült.
Az automatikus háttérfrissítés sikertelen lehet például tárhelyhiba, fájljogosultsági probléma, egyedi konfiguráció vagy korábban letiltott frissítési mechanizmus miatt.
Mit tegyen most?
-
Ellenőrizze a WordPress verzióját.
Lépjen be az adminisztrációs felületre, majd nyissa meg a Vezérlőpult → Frissítések menüpontot.
-
Készítsen teljes biztonsági mentést.
A mentés tartalmazza az adatbázist és a weboldal teljes fájlállományát is. Ne elégedjen meg egy olyan mentéssel, amelynek a visszaállíthatóságát még soha nem ellenőrizték.
-
Frissítsen javított verzióra.
- 7.0-s ág: legalább 7.0.2;
- 6.9-es ág: legalább 6.9.5;
- 6.8-as ág: legalább 6.8.6.
-
Ellenőrizze a weboldal működését.
Vizsgálja meg a nyilvános oldalakat, az űrlapokat, a belépést, a webáruházi folyamatokat, a fizetési módokat és az időzített feladatokat.
-
Nézze át a felhasználókat és a telepített bővítményeket.
Keressen ismeretlen adminisztrátori fiókokat, váratlanul megjelent bővítményeket, sablonokat és fájlkezelő eszközöket.
-
Vizsgálja meg a szerver- és biztonsági naplókat.
Különösen a REST API batch végpontjára érkező kéréseket kell ellenőrizni.
Mit lehet tenni, ha a frissítés átmenetileg nem hajtható végre?
A frissítés elhalasztása nem jó megoldás. Amennyiben azonban valamilyen technikai okból néhány órán belül sem telepíthető, ideiglenesen blokkolni kell a batch API anonim elérését.
Mindkét elérési módot védeni kell:
/wp-json/batch/v1 ?rest_route=/batch/v1Csak az első útvonal letiltása nem elegendő, mert a második változat továbbra is elérhető maradhat.
A blokkolás elvégezhető webalkalmazás-tűzfalban vagy szerveroldali szabályokkal. A módosítás azonban működési zavart okozhat olyan weboldalakon, amelyek jogos célra használják a batch API-t, ezért ez csak átmeneti védekezés lehet.
A Cloudflare új WAF-szabályokat vezetett be a két sérülékenységhez, a díjmentes csomag felhasználói számára is. A Cloudflare-védelem azonban csak akkor érvényesül, ha a weboldal forgalma ténylegesen a Cloudflare proxyján és tűzfalán halad keresztül.
A tűzfalszabály nem helyettesíti a WordPress frissítését.
Mi a teendő, ha a weboldal sérülékeny verziót futtatott?
Egy sérülékeny verzió korábbi használata önmagában még nem bizonyítja, hogy a weboldalt feltörték. Azt viszont jelenti, hogy a lehetőséget nem szabad figyelmen kívül hagyni.
Üzletileg fontos weboldalnál legalább az alábbi lépések indokoltak:
- adminisztrátori jelszavak cseréje;
- a WordPress biztonsági kulcsainak és salt értékeinek cseréje, amivel az aktív munkamenetek érvényteleníthetők;
- ismeretlen felhasználók keresése;
- a fájlok változásainak és a telepített bővítményeknek az ellenőrzése;
- a hozzáférési és tűzfalnaplók átvizsgálása;
- webáruház vagy tagsági rendszer esetén az érintett személyes adatok körének felmérése;
- szükség esetén incidenskezelési és adatvédelmi szakértő bevonása.
A jelszavakat nem azért kell lecserélni, mert a WordPress olvasható formában tárolná őket. A rendszer jelszóhash-eket tárol, amelyek azonban egy támadó birtokában offline feltörési kísérletek alapjai lehetnek, különösen gyenge vagy máshol is használt jelszavaknál.
A valódi probléma a gazdátlanul hagyott weboldal
Könnyű legyinteni arra, hogy egy új biztonsági kiadás jelent meg. A kisvállalkozások valóságában azonban sok weboldal három vagy öt éve elkészült, a fejlesztő átadta, a tulajdonos pedig évente kétszer lép be megváltoztatni a nyitvatartást.
Az automatikus frissítést egyszer kikapcsolták egy kompatibilitási hiba miatt. A biztonsági mentés létezik valahol, de senki nem próbálta visszaállítani. A bővítmények frissítése piros számmal villog, de a weboldal látszólag működik.
Egészen addig, amíg már nem működik.
A WordPress weboldal nem egyszer elkészítendő prospektus, hanem folyamatosan működtetendő informatikai rendszer. Adatbázissal, felhasználókkal, jogosultságokkal, külső kapcsolatokkal és folyamatosan változó támadási környezettel.
A karbantartás elhagyása nem megtakarítás. Csupán annak elfogadása, hogy egy későbbi időpontban a frissítésnél lényegesen drágább helyreállítást, adatvesztést vagy üzleti leállást kell finanszírozni.
Összefoglalás
A most javított sérülékenység azért különösen súlyos, mert:
- nem bővítményben, hanem a WordPress központi rendszerében volt;
- a támadási útvonalhoz nem feltétlenül kellett bejelentkezés;
- az adatbázis-lekérdezések manipulálhatóvá válhattak;
- a WordPress 6.9-es és 7.0-s érintett verzióinál a hibát távoli kódfuttatáshoz vezető láncként értékelték;
- a nyilvános javításból gyorsan visszafejthető a sérülékenység működése;
- a gazdátlanul hagyott weboldalak tulajdonosai gyakran csak akkor értesülnek a problémáról, amikor a támadás már megtörtént.
Ellenőrizze még ma a WordPress verzióját. Ne abból induljon ki, hogy az automatikus frissítés biztosan sikerült.
Amennyiben nem tudja megállapítani, hogy weboldala érintett-e, vagy a frissítés után biztonsági ellenőrzésre van szüksége, a Webtérülő weboldal-javítási igényfelmérésén keresztül elküldheti a webhely adatait.
