Egy névtelen HTTP-kérés is képes kódot futtatni egy WordPress oldalon. A hiba a core-ban van, ezért egy teljesen alap, plugin nélküli telepítés is kihasználható. Minden 6.9-es és 7.0-s oldal érintett volt péntekig, amikor a WordPress kiadta a 6.9.5-öt és a 7.0.2-t, és bekapcsolta az úgynevezett kényszerített frissítéseket az automatikus frissítési rendszerén keresztül.

A wp2shell valójában két hiba, nem egy, és mindkettőhöz tartozik már CVE-azonosító. A CVE-2026-63030 a REST API batch-route zavarára vonatkozik, a CVE-2026-60137 pedig egy SQL injection a WordPress core-ban. Összefűzve a kettő egy névtelen kéréstől egészen a kódfuttatásig vezet.

Péntek óta nyilvános a teljes mechanizmus, és felkerült egy működő proof-of-concept is a GitHub oldalra.

Adam Kues, az Assetnote-tól, a Searchlight Cyber támadási felületet vizsgáló részlegétől találta meg a batch-route hibát, és a WordPress HackerOne programján keresztül jelentette.

A wp2shell néven közzétett részletes leírás szerint a támadásnak „nincs előfeltétele, és egy névtelen felhasználó is ki tudja használni”. Az SQL injectiont külön jelentette TF1T, dtro és haongo.

A Searchlight továbbra is visszatartja a saját technikai leírását, és az üzemeltetőket a wp2shell.com ellenőrzőjére irányítja. Ez a visszafogottság mára lényegtelen: a javítócsomag nyilvános, más kutatók pedig már átnézték.

A két hiba nem ugyanazokat a verziókat érinti, és ez dönti el, hogy ki mire sebezhető. Az injection egészen 6.8-ig nyúlik vissza. A batch-route zavar, vagyis az a rész, amely egy korlátozott injectiont hitelesítetlen RCE-vé alakít, csak 6.9-től létezik.

Így alakulnak a tartományok:

• 6.8.0–6.8.5: csak SQL injection, javítva a 6.8.6-ban
• 6.9.0–6.9.4: teljes RCE-lánc, javítva a 6.9.5-ben
• 7.0.0–7.0.1: teljes RCE-lánc, javítva a 7.0.2-ben

A 7.1 beta2 már mindkét javítást tartalmazza. Egy 6.8-as oldal ezen a láncon keresztül nem használható ki RCE-re, ezért a 6.8.6 csak az injectiont javítja.

A WordPress nem közölte, hogy a kényszerített frissítés eléri-e azokat az oldalakat is, ahol az automatikus frissítéseket kikapcsolták. Ne feltételezd, hogy megérkezett a frissítés: ellenőrizd, pontosan mit futtatsz.

A Searchlight bejegyzése szerint több mint 500 millió weboldal fut WordPressen. Ez a szám a teljes telepített bázist jelenti, nem az összes érintett oldalt: az RCE-lánc csak 6.9-től létezik, amelyet 2025. december 2-án adtak ki. Így minden olyan oldal, amely ki van téve a kódfuttatási láncnak, nyolc hónapnál nem régebbi kiadást futtat, de arról egyik figyelmeztetés sem szól, pontosan mennyi ilyen oldal van.

A lánc két apró hibára épül. Az injekció a WP_Query author__not_in paraméterében él: ha tömb helyett karakterláncot kap, az a vizsgálat, amely tömböt vár, egyszerűen kimarad, és a nyers érték bekerül az SQL-lekérdezésbe.

A paraméter eléréséhez bejelentkezés nélkül a batch endpointot használják. A WordPress /wp-json/batch/v1 útvonala egy hívásban több al-kérést futtat, és ezeket két párhuzamos tömbben követi. Ha az egyik al-kérés hibára fut, a két tömb egy elemmel elcsúszik egymáshoz képest, így egy kérés egy másik kérés handlerét kapja meg.

Beágyazott hívásoknál ez a zavar megkerüli az endpoint allow-listjét, és a támadó bemenetét hitelesítés nélkül a sebezhető lekérdezésbe juttatja. A batch endpoint már a 5.6-os, 2020-as kiadás óta része a WordPressnek; az a zavar, amely most kihasználja, csak a 6.9-ben jelent meg.

Érdemes alaposan megnézni a pontszámokat. A WordPress saját figyelmeztetése Kritikus besorolást ad az RCE-láncnak. A hozzá tartozó CVE-rekord 7,5 pontot ad, ami csak High, és a hatásmutatók kizárólag az adatokhoz való hozzáférést veszik figyelembe, nem az integritás- vagy rendelkezésreállás-vesztést, ami kódfuttatásnál elvárható lenne. Az injekció a 9,1 fölötti, Kritikus pontszámokra épít.

Az a hiba, amelyet mindenki kritikus RCE-ként emleget, a saját pontszáma alapján a kettő közül a kisebb, mert a pontozás az injekció közvetlen adatbázis-elérését jutalmazza, és az útvonal-összekeveredést önmagában csak elemzési/parsing hibaként kezeli. Mindkét CVE-t kövesd, ne csak a rájuk aggatott címkéket.

Egy feltétel szűkíti a pusztítási kört. A kódfuttatási útvonal csak akkor működik, ha az oldal nem használ persistent object cache-t – derül ki a Cloudflare anyagából, amely a nyilvánosságra hozatallal együtt WAF-szabályokat is kiadott. Egy alapértelmezett telepítésben nincs ilyen cache, tehát az alaptelepítés továbbra is ki van téve a támadásnak.

Ha egy WordPress elé Redis vagy Memcached kerül persistent object cache-ként, az oldal kikerülhet ebből a konkrét kódfuttatási útvonalból, de ez csak mellékhatás, nem javítás, és az SQL-injekció ellen nem véd.

A CVE-azonosítók kiosztása után a szkennerek is látják a hibát: a Rapid7 szerint az InsightVM és a Nexpose hitelesített vizsgálatai július 20-án válnak elérhetővé. A sebezhetőség nincs rajta a CISA KEV-katalógusában, amelyhez igazolt kihasználás kell, és július 18-ig nem jelentettek ilyet. Ez a megnyugtató körülmény jóval törékenyebb, mint amilyennek elsőre tűnik.

A WordPress tömeges támadása ma már iparág. Mielőtt júniusban kiszivárgott volna a szerverük, egyetlen cache-bővítmény hibájával a WP-SHELLSTORM csoport saját beszámolója szerint több mint 17 000 oldalra jutott be. Úgy, hogy a hibát már korábban nyilvánosságra hozták, már volt rá javítócsomag, és csak egy nem alapértelmezett beállítás mellett működött. A mostani hiba nyilvános, van rá javítócsomag, és alapértelmezett beállítással is kihasználható.

Ha ma nem tudsz frissíteni

A Searchlight minden kerülőmegoldása arra épül, hogy az anonim hívásokat távol tartsa a batch végponttól. Ezek mind csak ideiglenes megoldások a frissítésig, és mind tönkretehetnek legitim integrációkat:

• WAF előtt tiltsd a /wp-json/batch/v1 és a rest_route=/batch/v1 elérést is. Mindkettőt le kell zárni, mert ha a szabály csak a /wp-json útvonalra vonatkozik, a query stringes elérés nyitva marad. A Cloudflare szerint a menedzselt WAF-je most már blokkolja a teljes támadási láncot a mögötte lévő oldalakon.
• Kapcsold ki a WP REST API-t, ami teljesen letiltja a hitelesítetlen REST-hozzáférést.
• Használd a Searchlight által kiadott rövid drop-in bővítményt, amely a rest_pre_dispatch ponton elutasítja az anonim /batch/v1 kéréseket.

A WordPress core nyílt forráskódú, a kiadás pedig név szerint felsorolja a módosított fájlokat. Ez önmagában is elég volt. A Searchlight visszatartotta a részletes leírást; egy napon belül más kutatók elolvasták a javítócsomagot, közzétették a mechanizmust, és felkerült a kihasználás a GitHub oldalra – pontosan ez az a forgatókönyv, amivel a felelős nyilvánosságra hozatal versenyt futott.

A javítást nem lehet úgy kiadni, hogy ne adjuk mellé a hiba térképét is. Egyetlen dolog marad: milyen gyorsan jut el a javítócsomag az oldalakra, mielőtt valaki elolvassa. A WordPress pénteken ezen a ponton próbált a lehető leggyorsabb lenni.

Most már nyilvános a kihasználás, miközben a frissítés még mindig terjed. A WordPress verzióstatisztikái megmutatják, hány oldal telepítette a javítócsomagot; a batch/v1 elleni szkennelési forgalom pedig azt, hány támadó kereste a hibát. Az, hogy melyik görbe meredekebb, eldönti, hogyan emlékezünk majd erre az esetre.