2026. október 6-án megjelent a WordPress 7.1.3, amely hét biztonsági és négy további hibajavítást tartalmaz. A fejlesztők mielőbbi frissítést javasolnak. De mit jelentenek a közleményben szereplő sérülékenységek, és miért fontosak egy weboldal tulajdonosának?
A WordPress hivatalos közleménye több különböző WordPress sérülékenységi problémát sorol fel. Az alábbiakban mind a hét javítást áttekintjük, és elmagyarázzuk az érintett hibatípusok működését.
A WordPress sérülékenységeknél bemutatott lehetséges következmények általános magyarázatok: nem jelentik azt, hogy valamennyi felsorolt következmény ennél a konkrét WordPress-hibánál is igazolt.
1. WordPress sérülékenység: Tárolt XSS a hozzászólások adminisztrációs oldalán
A közlemény szerint az egyik javítás a jóváhagyásra váró hozzászólásokon keresztül kihasználható, tárolt XSS-hibát érinti az adminisztrációs felületen.
Az XSS, vagyis Cross-Site Scripting olyan sérülékenység, amelynél a támadó által megadott tartalom futtatható kódként jut el egy másik felhasználó böngészőjébe. A böngésző a weboldal részeként kezeli ezt a kódot.
A tárolt XSS esetében a veszélyes tartalom először elmentődik, például egy adatbázisba. Később, amikor valaki megnyitja az azt megjelenítő oldalt, a kód lefuthat. Szemléltető példa egy rosszindulatú hozzászólás, amely az adminisztrátori megtekintés során válik aktívvá.
Az XSS lehetséges következménye a megjelenített tartalom módosítása, átirányítás, érzékeny információk megszerzése vagy a bejelentkezett felhasználó nevében végzett művelet. A tényleges hatás függ a sérülékenységtől és a felhasználó jogosultságaitól.
Az OWASP XSS-ismertetője részletesen bemutatja ezt a támadástípust. Ennél a WordPress-javításnál különösen lényeges, hogy a közlemény jóváhagyásra váró hozzászólásokat említ: az érintett megjelenítési hely az adminfelület.
2. WordPress sérülékenység: Szolgáltatásmegtagadást okozó hiba az URL-feldolgozásban
A második javítás a WP_Http::make_absolute_url() metódushoz kapcsolódó DoS-problémát kezeli.
A DoS, vagyis Denial of Service magyarul szolgáltatásmegtagadás. Ilyenkor a támadás a rendszer elérhetőségét veszélyezteti: a weboldal lelassulhat, hibákat adhat vagy elérhetetlenné válhat.
Ehhez nem feltétlenül kell óriási adatforgalom. Alkalmazásszintű DoS esetén egy hibásan kezelt bemenet feldolgozása aránytalanul sok erőforrást emészthet fel. Az erőforrások lekötése a rendes látogatók kiszolgálását is akadályozhatja.
A DDoS az elosztott változat, amelynél több forrás vesz részt a támadásban. A WordPress közleménye itt DoS-hibát nevez meg; nem írja le a szükséges kérésszámot vagy a pontos erőforrásigényt.
Bővebben: OWASP – Denial of Service.
3. WordPress sérülékenység: Másodrendű SQL-injection az exportálásnál
A WordPress WXR-exportját érintő javítás egy second-order SQL injection, magyarul másodrendű SQL-injection problémára vonatkozik.
Az SQL az adatbázisok lekérdezésére és módosítására használt nyelv. SQL-injection akkor keletkezhet, ha az alkalmazás egy külső forrásból származó értéket úgy illeszt egy adatbázis-parancsba, hogy az érték a parancs működését is megváltoztathatja.
Egyszerűen fogalmazva: a rendszer adatot vár, de annak egy részét utasításként értelmezi. Az ilyen hibák lehetséges következménye jogosulatlan adatolvasás, illetve a körülményektől függően adatmódosítás vagy törlés. Az OWASP SQL-injection összefoglalója ezeket az általános kockázatokat részletezi.
Mitől másodrendű? A veszélyes adat először bekerül a rendszerbe, és elmentődik. A hiba később jelentkezik, amikor egy másik funkció előveszi ezt az adatot, és nem biztonságosan használja fel egy újabb SQL-lekérdezésben.
Szemléltető folyamat:
- Az alkalmazás eltárol egy felhasználótól származó értéket.
- Egy későbbi művelet visszaolvassa azt.
- Az érték hibásan összeállított adatbázis-lekérdezésbe kerül.
- A lekérdezés jelentése megváltozik.
Ezért önmagában az, hogy egy adat már az adatbázisban van, nem teszi biztonságossá minden későbbi felhasználásra. A védekezés egyik alapja a lekérdezések megfelelő paraméterezése. A PortSwigger magyarázata a másodrendű SQL-injection sajátosságait mutatja be.
4. WordPress sérülékenység: Jogosultsági hiba: szerzők is rögzíthettek bejegyzéseket
A következő javítás olyan hibát érint, amely lehetővé tette, hogy Szerző szerepkörű felhasználók bejegyzéseket tegyenek ragadóssá, azaz rögzítetté.
Ez a jogosultság-ellenőrzési hibák jelentőségét szemlélteti. Egy rendszernek minden műveletnél ellenőriznie kell, hogy az adott felhasználó jogosult-e annak végrehajtására. A bejelentkezés önmagában ehhez nem elegendő.
Az ilyen problémák lényege, hogy valaki túlléphet a neki szánt jogosultsági határon. Ez lehet egyetlen funkció jogosulatlan használata is. A bejegyzések rögzítésére vonatkozó hiba nem azonos az adminisztrátori szerepkör megszerzésével.
5. WordPress sérülékenység: Nem nyilvános bejegyzések hozzászólásainak kiszivárgása
A frissítés egy olyan hibát is kezel, amely bejelentkezés nélkül hozzáférhetővé tette privát és még nem publikált bejegyzések hozzászólásait.
Az információszivárgás azt jelenti, hogy az alkalmazás olyan adatot ad ki, amelyhez az adott látogató nem jogosult hozzáférni. Ehhez nincs szükség fájlmódosításra vagy a weboldal látványos megváltoztatására: a probléma maga a jogosulatlan hozzáférés.
Egy jogosultsági rendszernek a kapcsolódó adatok védelmét is kezelnie kell. Egy tartalom és annak hozzászólásai külön lekérdezéseken keresztül is megjelenhetnek; az ellenőrzéseknek ezekre a hozzáférési utakra is ki kell terjedniük.
Az előző két pont hátterét az OWASP hozzáférés-ellenőrzési ismertetője foglalja össze.
6. WordPress sérülékenység: XSS az Imgur-beágyazásokban
A második XSS-javítás az Imgur-beágyazásokat érinti.
Az XSS szempontjából a külső szolgáltatásból érkező tartalom is lehet veszélyes bemeneti forrás. Ha az alkalmazás azt nem megfelelően illeszti a megjelenített oldalba, a böngésző nem kívánt kódot is végrehajthat.
A biztonságos megjelenítéshez a feldolgozás és a kimenet kezelése egyaránt számít. A konkrét beágyazási hiba jelenlétéből nem következik, hogy maga a külső szolgáltatás vagy minden onnan származó kép fertőzött lenne.
7. WordPress sérülékenység: Ütközés a WordPress belső eseménynevei között
A hetedik javítás a {status}_{type} hookhoz kapcsolódó, manipulálható paraméterekből eredő eseménynév-ütközést érinti.
A WordPress hookjai olyan kapcsolódási pontok, amelyekre bővítmények és egyedi fejlesztések saját működést köthetnek. Az action hook meghívásakor a hozzá regisztrált függvények futnak le.
Bizonyos eseménynevek több érték összefűzéséből állnak elő. A WordPress fejlesztői dokumentációjában szereplő ilyen hook például a bejegyzés állapotát és tartalomtípusát használja fel.
Egy eseménynév-ütközésnél különbözőnek szánt események azonos nevet kaphatnak. Ez megzavarhatja, hogy a rendszer melyik eseményhez tartozó működést indítja el. A kiadási közlemény nem részletezi a konkrét hiba teljes következményét, ezért ebből nem állítható általános, tetszőleges szerveroldali kódfuttatási lehetőség.
Mit tegyen most a weboldal tulajdonosa?
A teendők áttekintéséhez a WordPress hivatalos frissítési útmutatója ad kiindulópontot:
- Ellenőrizze a telepített verziót. Az automatikus frissítés eredményét is érdemes megnézni az adminisztrációs felületen.
- Készítsen biztonsági mentést a fájlokról és az adatbázisról a kézi frissítés előtt.
- Telepítse az elérhető biztonsági frissítést a Vezérlőpult → Frissítések menüben.
- Ellenőrizze az oldal működését. Javasolt végigpróbálni a fontos funkciókat, például a kapcsolatfelvételi űrlapot, a bejelentkezést és webáruháznál a vásárlási folyamatot.
Ha az oldalon már gyanús átirányítás, ismeretlen adminisztrátor vagy idegen tartalom jelent meg, érdemes külön biztonsági vizsgálatot végezni. A feltételezett fertőzés kivizsgálását kezeljük külön feladatként a verziófrissítéstől.
Segítségre van szüksége egy gyanús vagy fertőzött weboldallal? A WordPress- és Joomla-weboldalak vírusmentesítéséről, helyreállításáról itt talál további információt.