A WordPress sürgős biztonsági frissítést adott ki egy kritikus sérülékenységhez, amely lehetővé teheti a támadók számára, hogy a weboldal témakönyvtárain kívül található PHP-fájlokat töltsenek be. Meghatározott feltételek teljesülése esetén a hiba bejelentkezés nélküli rosszindulatú kódfuttatáshoz is vezethet.
A javítás a 2026. szeptember 22-én megjelent WordPress 7.1.2 kiadásban vált elérhetővé. A fejlesztők azonnali frissítésre kérték az üzemeltetőket, és megköszönték Robert Ressl biztonsági kutatónak a sérülékenység bizalmas bejelentését. A kiadás részleteit a WordPress hivatalos közleménye ismerteti.
A CVE-2026-87902 azonosítójú sérülékenység a CVSS 4.0 értékelési rendszerben 9,2 pontos, kritikus besorolást kapott. A hivatalos biztonsági tájékoztató szerint az oldalsablon kiválasztásában található, hitelesítés nélkül kihasználható könyvtárbejárási hibáról van szó.
A támadáshoz nincs szükség meglévő felhasználói fiókra vagy egy jogosult felhasználó közreműködésére. A legsúlyosabb következmény azonban a weboldal témájának könyvtárszerkezetétől és a kiszolgálókörnyezet beállításaitól is függ.
A sérülékenység tehát nem jelenti azt, hogy minden érintett WordPress-oldal azonnal teljesen átvehető. Olyan támadási lehetőséget teremt, amelyen keresztül egy névtelen kérés olyan helyi PHP-kód betöltését idézheti elő, amelyet a WordPressnek nem lenne szabad oldalsablonként használnia.
Hogyan működik a WordPress sérülékenység?
Az érintett funkció dönti el, hogy a WordPress melyik sablonnal jelenítse meg a lekért oldalt. A Patchstack technikai elemzése szerint a rendszer a kérésből származó oldalnév alapján állított össze egy lehetséges sablonfájlnevet, de nem alkalmazta azt a könyvtárbejárást ellenőrző vizsgálatot, amely egy közeli kódágban már rendelkezésre állt.
Az így létrehozott fájlnév rögzített page- előtagot és .php kiterjesztést kap. Ezek a megkötések meghatározzák a kihasználás feltételeit: az aktív témának tartalmaznia kell egy megfelelő, legfelső szintű, page- kezdetű könyvtárat, a célpontnak pedig egy olvasható PHP-fájlnak kell lennie.
Ha a szükséges feltételek teljesülnek, a könyvtárbejárás révén a sablonkiválasztás kiléphet az eredetileg engedélyezett könyvtárból.
A Patchstack szerint a frissítés ellenőrzést vezet be az érintett, dekódolt oldalnév feldolgozásánál, és további vizsgálatokkal szűri a könyvtárbejárási elemeket tartalmazó sablonútvonalakat. Ezek a módosítások az alapvető útvonalkezelési hibát javítják.
A kiszolgáló konfigurációjának ellenőrzése segíthet megállapítani a kitettséget, de nem helyettesíti a javított WordPress-verzió telepítését.
A témák könyvtárszerkezete is számít
A témák szerepe azért jelentős, mert egy teljesen szabályos, hétköznapi könyvtárszerkezet is teljesítheti a támadás egyik előfeltételét. A WordPress témafejlesztési dokumentációja bemutatja, hogyan szabályozzák az egyedi oldalsablonok az egyes oldalak megjelenését, és miként rendezhetők ezek alkönyvtárakba.
Egy sablonok rendszerezésére használt mappa így a platform egy másik részében található sérülékenység szempontjából válhat fontossá. A jelenléte nem jelenti azt, hogy a téma fejlesztője okozta a WordPress alaprendszerének hibáját, és önmagában nem bizonyítja egy teljes kódfuttatási támadási lánc elérhetőségét.
A hivatalos tájékoztató a megfelelő könyvtárszerkezet példáiként említi a régebbi Twenty Twelve és Twenty Fourteen témákat, valamint a külső fejlesztőktől származó Neve, Hestia és Sydney témákat. Az aktív szülőtémát és gyermektémát egyaránt figyelembe kell venni.
A közlemény a dokumentált kódfuttatási lehetőség szempontjából a hivatalos PHP Docker-lemezképeket, valamint a PHP 8.5-nél korábbi verzióját használó alapértelmezett cPanel-konfigurációkat is érintettként nevezi meg. A feltételeket a WordPress hivatalos biztonsági tájékoztatója részletezi.
Mikor vezethet a fájlbetöltés tetszőleges kódfuttatáshoz?
A helyi fájlbetöltéstől a támadó által meghatározott kód futtatásáig további feltételnek is teljesülnie kell. Egy meglévő PHP-fájl betöltése annak programlogikáját hajtja végre, de önmagában nem biztosít a támadónak ellenőrzést afelett, hogy ez a logika mit tesz.
Robert Ressl a kutatási beszámolójában a tesztkörnyezetében már jelen lévő PEAR-összetevőkre épülő módszert mutatott be. A PEAR nem a WordPress függősége. A bemutatott támadási lánchoz a következőkre volt szükség:
- egy olvasható PEAR-belépési pontra;
- a webes kéréseket kiszolgáló PHP-környezetben bekapcsolt
register_argc_argvbeállításra; - egy olyan célhelyre, ahová a folyamat írhatott.
Ressl elkülönített laboratóriumi környezetekben tesztelte a WordPress 7.0.2 verzióját, és a javítás bejelentésével együtt közzétette a kihasználhatóságot igazoló demonstrációt.
A kód a PHP-t, illetve a webkiszolgálót futtató fiók jogosultságaival hajtódott végre. A tesztek nem igazoltak rootjogosultság megszerzését, a gazdagépre való kitörést vagy éles weboldal elleni támadást. A kutató azt sem mérte fel, hogy az összes szükséges előfeltétel milyen gyakran áll fenn a működő weboldalakon.
E korlátok mellett is jelentős lehet a lehetséges hatás. Ressl szerint a szolgáltatásfiók jogosultságai elegendők lehetnek konfigurációs adatok és adatbázis-hozzáférési adatok eléréséhez, a weboldal adatainak módosításához, az írható alkalmazásfájlok megváltoztatásához vagy a működés megzavarásához.
A szervezetek tényleges kitettségét ezért a sérülékeny alkalmazás mellett az azt futtató folyamat jogosultságai is meghatározzák.
A webes PHP-környezet tényleges beállításait kell ellenőrizni
A kitettség felmérésekor külön figyelmet érdemel a PHP konfigurációja. A PHP kézikönyve szerint a register_argc_argv beállítás szabályozza az argumentumváltozók létrehozását. A dokumentáció azt is rögzíti, hogy a PHP 8.5 elavultnak jelölte e változók lekérdezési karakterláncból történő előállítását a parancssori környezeten kívül.
Az üzemeltetőknek a webes kérések kiszolgálásakor ténylegesen érvényes konfigurációt kell ellenőrizniük. Egy parancssorból végzett PHP-ellenőrzés más futtatókörnyezet beállításait mutathatja. Önmagában a verziószám sem bizonyítja, hogy egy adott beállítás ki van kapcsolva.
Ressl kiegészítő védelmi intézkedésként javasolja a webes kérésekhez szükségtelen argumentumregisztráció kikapcsolását és a webes futtatókörnyezet számára olvasható, használaton kívüli PEAR-belépési pontok eltávolítását.
Ezek az intézkedések megszakíthatják a bemutatott kódfuttatási láncot, de a WordPress fájlbetöltési hibáját nem javítják ki.
Mely WordPress-verziók tartalmazzák a javítást?
Azoknak a szervezeteknek is foglalkozniuk kell a frissítéssel, amelyek nemrég már telepítettek biztonsági javításokat. Az előző heti biztonsági kiadásban megjelent WordPress 7.1.1 ezt a különálló sérülékenységet még tartalmazza. A közelmúltbeli karbantartás dátuma ezért önmagában nem bizonyítja a védelem meglétét.
A hivatalos tájékoztatóban szereplő javított verziók közül:
| WordPress-verzióág | A javítást tartalmazó kiadás |
|---|---|
| 7.1 | 7.1.2 |
| 7.0 | 7.0.6 |
| 6.9 | 6.9.9 |
| 6.8 | 6.8.10 |
| 6.7 | 6.7.9 |
| 6.6 | 6.6.9 |
| További régebbi ágak | Külön javított kiadások, egészen a 4.7.37 verzióig |
A táblázat nem a teljes verziólista. A régebbi ágakat használó üzemeltetőknek a WordPress 7.1.2 hivatalos kiadási dokumentációjában kell ellenőrizniük a saját águkhoz tartozó javítást. Nem szabad feltételezni, hogy bármelyik későbbi kisebb kiadás automatikusan tartalmazza azt.
A WordPress hangsúlyozza, hogy a régebbi ágakhoz készített javításokat kiegészítő segítségként adta ki, és csak a legfrissebb verzió élvez aktív támogatást. A visszaportolt javítások lehetőséget adnak az azonnali sérülékenység kezelésére, miközben a szervezet előkészíti a hosszabb távú verzióváltást.
Az automatikus háttérfrissítésre beállított weboldalakon a frissítési folyamatnak automatikusan el kell indulnia. Más esetekben az adminisztrációs felület Frissítések menüpontja használható, vagy a kiadás közvetlenül letölthető a WordPress.org oldaláról.
Üzemeltetési szempontból a frissítés sikeres befejezését minden weboldalon ellenőrizni kell, beleértve a kisebb, másodlagos oldalakat és a külső szolgáltató által kezelt telepítéseket is. Az automatikus frissítési szabályzat bekapcsolása önmagában nem elegendő.
Frissítés: már aktív támadásokat is megfigyeltek
Az eredeti cikkben idézett, szeptember 22-i The Hacker News-beszámoló még nem ismert valós támadásokban történt kihasználást. Ez egy adott időpont helyzetértékelése volt, amelyet az újabb megfigyelések azóta meghaladtak.
A Patchstack szeptember 23-án frissített elemzése már aktív kihasználásról számol be. A vállalat szerint a kezdeti felderítő kéréseket olyan támadások követték, amelyek a PEAR pearcmd.php összetevőjén keresztül támadói tartalmú PHP-fájlokat próbáltak a kiszolgálóra írni. Nyilvános felderítőeszközök is megjelentek. A részleteket a Patchstack támadási megfigyelésekről szóló közleménye ismerteti.
Ez nem bizonyítja, hogy minden sérülékeny weboldalt feltörtek. Azt azonban jelzi, hogy a veszély már túlmutat a laboratóriumi demonstráción, ezért a javítás telepítése mellett a korábbi kompromittálódás lehetőségét is vizsgálni kell.
A frissítés mellett a támadások nyomait is ellenőrizni kell
A megfelelő védekezéshez a frissítést a kockázattal arányos ellenőrzésnek kell kiegészítenie. A WordPress biztonsági ajánlásai kiemelik a hozzáférési és hibanaplók, a fájlváltozások figyelése, a korlátozott jogosultságok és a megbízható biztonsági mentések jelentőségét.
Ennél a sérülékenységnél ezek a gyakorlatok segíthetnek a gyanús útvonalkezelési kérések és a váratlan PHP-fájlmódosítások felderítésében, miközben megőrzik a vizsgálathoz szükséges bizonyítékokat.
Az eredeti cikk ezeket még a nyilvánosságra hozott működési mechanizmusból levezetett védelmi ajánlásokként ismertette. A későbbi támadási megfigyelések további indokot adnak az ellenőrzésre. A szokásos naplók ugyanakkor nem feltétlenül tartalmaznak elegendő részletet minden támadási kísérlet utólagos rekonstruálásához.
A tárhelyszolgáltatóra vagy ügynökségre támaszkodó vállalkozásoknál a javításnak legyen kijelölt felelőse és ellenőrizhető eredménye. A telepített verzió megerősítése, a weboldal alapvető funkcióinak frissítés utáni tesztelése és a még megoldatlan kivételek dokumentálása többet ér annál az általános biztosítéknál, hogy a szolgáltató kezeli a biztonsági frissítéseket.
A WordPress biztonsága a kiszolgálókörnyezeten is múlik
Az eset megmutatja, hogy a kitettség nem mindig állapítható meg kizárólag a tartalomkezelő rendszer vizsgálatával. Az alaprendszer hibája, egy szabályos témakönyvtár-szerkezet és egy kiszolgálóoldali segédprogram együtt súlyosabb támadási lehetőséget teremthet.
A WordPress frissítése lezárja a nyilvánosságra hozott támadási belépési pontot. A szükségtelen futtatókörnyezeti funkciók kikapcsolása és a fájlrendszer-jogosultságok szűkítése pedig hozzájárul ahhoz, hogy egy későbbi sérülékenység következményei korlátozottabbak legyenek.
Az eredeti cikk címe: „WordPress Patches Critical Core Flaw That Could Allow Unauthenticated Code Execution”. A magyar változat az aktív kihasználásra vonatkozó, külön jelölt kiegészítést tartalmaz a Patchstack szeptember 23-i frissítése alapján.
