2026 júniusában egy általunk kezelt Joomla-weboldalon ismeretlen könyvtárak, PHP-fájlok és új Super User-fiókok jelentek meg. A naplófájlok elemzése után kiderült, hogy a támadók az SP Page Builder Pro bővítmény egy kritikus, akkor még nyilvánosan nem dokumentált sebezhetőségét használták ki.
A hibát később CVE-2026-48908 azonosítóval vették nyilvántartásba. Súlyossági besorolása a lehető legmagasabb, CVSS 10.0 – Critical lett.
Mi volt a sebezhetőség?
Az SP Page Builder rendelkezett egy egyedi ikoncsomagok feltöltésére szolgáló végponttal:
/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon
A sérülékeny verziókban ezt a műveletet bejelentkezés nélkül is meg lehetett hívni. A feltöltött fájlok típusának ellenőrzése sem volt megfelelő, így egy támadó képfájl vagy ikoncsomag helyett PHP-kódot tölthetett fel a szerverre.
Ha a feltöltött PHP-fájl a böngészőből elérhető helyre került, a támadó futtatni is tudta, így a Joomla adminisztrátori jelszavának ismerete nélkül is átvehette az irányítást az oldal felett.
A hiba az SP Page Builder 6.6.1 és az előtti verzióit érintette, és a 6.6.2-es verzióban javították.
A feltörés felfedezése
Az érintett weboldalon először a furcsa nevű images alkönyvtárak megjelenése tűnt fel, majd néhény idegen super user is a felhasználók között. A mélyebb ellenőrzés még további több tucat idegen könyvtárat és azok alatt php fájlokat tárt fel.
A napló fájlok elemzésével viszonylag gyorsan azonosítható volt az első támadás mikéntje és pontos időpontja.
Addigra bejelentésre is került a tárgyi nulladik napi sebezhetőség is és kiadásra került az SP Page Builder 6.6.2-es verziója, amely javította ezt a bug-ot.
A feltört weboldal helyreállítása
A feltörés felfedezése után azonnal kifelé elérhetetlenné tettük az oldalt, hogy megakadályozzuk a további incíidenseket a már létrehozott hátsó ajtókon.
Mivel a naplófájlokból pontosan ismert volt a támadás kiinduló időpontja, így tudtuk, hogy mely biztonsági másolatból lehet biztosan tisztára visszaállítani az oldalt (ezért fontos a rendszeres biztonsági másolat készítés).
A visszaállítás után azonnal frissítettük a bővítményt a javítócsomaggal, plusz biztonsági elemként .htaccess-ben is tiltottuk a kérdéses végponthívást.
Természetesen módosítottunk minden jelszót, töröltük a munkameneteket, ellenőriztük a cron-feladatokat és szigorítottunk a WAF tiltásokon, mert ha egy oldalt sikeresen feltörnek, akkor a tisztítás után még jó ideig fokozottan próbálkoznak az adott weboldallal (ahogy a következő hetek eseményei bizonyították is).
A biztonsági mentés és a visszaállítás időpontja között az ügyfél által létrehozott cikkeket az adatbázisból állítottuk vissza.
Összességében a weboldal kompromittálásának felfedezése és a teljes helyreállítás között nem telt el 24 óra!
Tanulságok
Egy Joomla-oldal akkor is feltörhető, ha a Joomla rendszermag naprakész, a jelszavak erősek, és az adminisztráció védett. Ebben az esetben a támadáshoz sem bejelentkezés, sem ellopott jelszó nem kellett: elég volt egy sérülékeny külső komponens.
A bővítmények rendszeres frissítése ezért csak az egyik védelmi réteg. Ugyanilyen fontos a rendszeres mentések megléte, a naplók figyelése, a Super User-fiókok ellenőrzése és az olyan szerveroldali szabályok használata, amelyek egy ismert támadási útvonalat már a Joomla elérése előtt blokkolnak.
És még ekkor is előfordulhat, hogy egy nulladik vagy „minusz egyedik” napi sérülékenységet kihasználnak a hackerek.
Ekkor jön jól a végső adu ász, a biztonsági szakember, akihez a nap 24 órájában lehet fordulni, s aki megnyugtatja a pánikba esett ügyfelet és gyorsan, szakszerűen intézkedik 🙂 .