Egyszerre több WordPress oldalunkat törték fel – és ez lett a negyedik érv az egyedi fejlesztés mellett
Évek óta Laravel alapú, egyedi fejlesztésű weboldalakat készítünk. Eddig három okkal érveltünk emellett: a szabadon megtervezhető funkciókkal, a sebességgel és azzal, hogy a megjelenés nem egy sablon keretei közé szorul. Most jött egy negyedik, és őszintén szólva ez lett a legsúlyosabb.
Nem egy oldal. Nem egy szerver. Egyszerre több, egymástól teljesen független kiszolgálón futó WordPress oldal – mind olyan, amelyet mi készítettünk, és amelyeken naprakész volt a rendszer. A támadás nem a mi kódunkat találta el, hanem azt, ami minden WordPress-oldalon közös: a harmadik féltől származó sablonokat és bővítményeket. Ez a cikk arról szól, mi történt, miért történhetett meg, és miért nem véletlen, hogy a komolyabb üzleti oldalakat már nem sablonból építjük.
🛡️ A helyzet számokban
Mi történt pontosan?
Több ügyfelünk WordPress oldala – egymástól független tárhelyeken, különböző szolgáltatóknál – rövid időn belül kompromittálódott. A tünetek ismerősek voltak: ismeretlen adminisztrátori fiókok jelentek meg, a látogatókat időnként idegen oldalakra irányították át, a fájlrendszerbe pedig olyan kód került, amit senki nem tett oda.
A közös nevező nem a szerver volt, és nem is a mi munkánk. A közös nevező maga a WordPress ökoszisztéma: a sablonok és a bővítmények, amelyeket minden WordPress-oldal használ, és amelyeket harmadik felek fejlesztenek.
Miért nem elég a rendszeres frissítés?
A leggyakoribb válasz erre a helyzetre az szokott lenni, hogy „csak frissíteni kell rendszeresen". Ez 2020-ban még működő tanács volt. 2026-ban viszont már nem elég, és ennek matematikai oka van.
A támadók ma nem emberek, hanem automatizált rendszerek. Amikor egy népszerű bővítményhez biztonsági frissítés jelenik meg, a mesterséges intelligenciával felszerelt botnetek másodpercek alatt összehasonlítják a régi és az új kódot, megkeresik a javított hibát, és automatikusan előállítják a támadókódot. Utána elindul a tömeges pásztázás: a botok végigmennek az interneten, és minden olyan oldalt megtámadnak, amelyiken még a régi verzió fut.
A védekezőknek erre medián értéken öt órájuk van. Ha pénteken este jelenik meg egy frissítés és hétfőn reggel telepítik, az már késő. A támadás nem célzott – egyszerűen sorra kerül minden oldal, amely sebezhető.
Négy ok, amiért egyedi fejlesztésben dolgozunk
Az első három érv régóta megvolt. A negyedik az elmúlt hetekben vált a legfontosabbá.
1. Funkció – amit az üzlet megkíván, nem amit a bővítmény tud
Sablonos oldalnál a kérdés mindig úgy hangzik: „melyik bővítmény tudja ezt megcsinálni?" Egyedi fejlesztésnél viszont az igényből indulunk, és azt építjük meg, amire a cégnek valóban szüksége van – akkor is, ha erre nincs kész megoldás a piacon.
2. Sebesség – a bővítmények súlya nélkül
Egy tipikus WordPress oldalon húsz-huszonöt bővítmény tölti be a saját kódját minden egyes oldalmegnyitáskor, függetlenül attól, hogy az adott oldalon szükség van-e rájuk. Egyedi fejlesztésnél csak az fut le, aminek futnia kell – ez a különbség a betöltési időben is, és a Google értékelésében is meglátszik.
3. Megjelenés – nem a sablon szabja meg a határokat
A sablon mindenkinek ugyanazt a szerkezetet adja, és a testreszabás előbb-utóbb falba ütközik. Egyedi fejlesztésnél a design a márkához igazodik, nem fordítva – és nem kell kompromisszumot kötni azért, mert egy sablon nem enged valamit.
4. Biztonság – ez lett a döntő érv
Egy WordPress oldal biztonsága pontosan annyira erős, mint a rajta futó leggyengébb bővítmény. Huszonöt idegen komponens, huszonöt ismeretlen fejlesztő, huszonöt lehetséges belépési pont – és mindegyik hibája nyilvános adatbázisban szerepel, ahonnan a támadó botok dolgoznak. Az elmúlt hetek megmutatták, mit jelent ez a gyakorlatban.
Két különböző kockázati modell
Ugyanaz a cég, ugyanaz a weboldal-funkció – csak az alatta lévő technológia más:
Ön a sablon és 15–25 bővítmény fejlesztőjében bízik
Minden egyes komponens egy-egy önálló kockázati pont, amelyet idegen fejlesztők tartanak karban – vagy éppen nem tartanak karban. Ha bármelyikben hiba van, az egész oldal támadható. A hibák ráadásul nyilvánosak: a CVE-adatbázisokból bárki megnézheti, melyik verzió sebezhető.
A kód a mienk, a felelősség is a mienk
Nincs sablon, nincs bővítmény-ökoszisztéma, nincs nyilvános verziószám, amit a botok kereshetnének. Ami az oldalon fut, azt mi írtuk, mi ismerjük és mi tartjuk karban. A támadási felület a töredékére csökken – nem azért, mert a kódunk hibátlan, hanem mert nincs benne huszonöt idegen komponens.
Konkrét példák – olyan komponensekkel, amiket mi is használtunk
Nem általánosságban beszélünk. Az alábbi hibák mind nyilvános sérülékenységi adatbázisokban szerepelnek, és mind olyan bővítményekben vagy sablonban találhatók, amelyekkel mi is dolgoztunk ügyfélprojekteken.
Flatsome sablon – kártékony kód a rövidkódokban
A Flatsome az egyik legelterjedtebb WooCommerce-sablon, amelyet mi is használtunk több ügyfélprojekten. A 3.20.0-s és korábbi verziókban a sablon nem szűrte megfelelően a rövidkódok paramétereit (UX Slider, Video Button, UX Countdown és társai). Egy alacsony jogosultságú felhasználó kártékony JavaScriptet ágyazhatott be, amely azután minden látogatónál lefutott – és ha egy adminisztrátor nyitotta meg az oldalt, a kód az ő nevében hozhatott létre újabb admin fiókokat.
WPForms – bárki visszatéríttethette a fizetéseket
A WPForms több mint hatmillió oldalon fut, űrlapoktól a Stripe-fizetésekig. Az 1.8.4 és 1.9.2.1 közötti verziókban a rendszer nem ellenőrizte megfelelően a jogosultságokat: bárki, aki legalább előfizetői szinten regisztrált az oldalon, tömegesen visszatéríttethette a befolyt fizetéseket vagy lemondhatta az előfizetéseket. Ahol nyilvános a regisztráció, ott ez néhány perc alatt komoly anyagi kárt okozhatott.
Code Snippets – elég volt, ha az admin megnyitott egy linket
Ez a bővítmény egyedi kódrészletek futtatását teszi lehetővé – fejlesztők kedvence. A 3.9.4-es és korábbi verziókban hiányzott egy biztonsági ellenőrzés, így ha egy bejelentkezett adminisztrátor megnyitott egy preparált weboldalt, a böngészője a háttérben, a tudta nélkül letöltött és aktivált egy támadó által küldött PHP kódrészletet. Onnantól a szerver a támadóé volt.
WPS Hide Login – a rejtett belépő mégsem volt rejtett
Sokan használják ezt a bővítményt arra, hogy elrejtsék a belépési oldalt a jelszótörő botok elől. Az 1.9.15.2-es és korábbi verziókban azonban egyetlen URL-paraméter hozzáfűzésével elő lehetett csalogatni a titkos címet – a védelem tehát pontosan azt nem tudta, amiért telepítették. A támadók ezután a sötét webről származó jelszólistákkal próbálkozhattak.
WP2Shell – és maga a WordPress mag is
A 2026-os év legsúlyosabb esete nem is bővítményhez kötődik: a WordPress alaprendszerében találtak egy olyan hibaláncot, amellyel bejelentkezés nélkül át lehetett venni az irányítást egy teljesen alapértelmezett telepítés fölött is. A nyilvánosságra hozatal napján, 2026. július 17-én a mérések több mint 11 millió automatizált támadási kísérletet regisztráltak világszerte. Ez az az eset, ahol már az sem segít, ha egyetlen bővítményt sem telepít az ember.
💡 Miért soroljuk fel ezeket ilyen nyíltan? Mert ezek a hibák nyilvánosak – bárki megnézheti őket a NIST és a GitHub sérülékenységi adatbázisában. Épp ez a lényeg: a támadók ugyanezekből a listákból dolgoznak. Amint egy hiba felkerül, a botok elkezdik keresni azokat az oldalakat, amelyeken még a régi verzió fut. Ez a nyíltság a nyílt forráskód ereje és egyben a gyengesége is.
A legrosszabb rész: észre sem veszi
Ha egy támadó bejut, nem rongálja meg az oldalt. Éppen ellenkezőleg: mindent megtesz azért, hogy a tulajdonos semmit ne vegyen észre. A mai kártevők kifejezetten okosan rejtőzködnek, és három trükköt szinte mindig bevetnek.
Láthatatlan adminisztrátori fiók
A kártevő létrehoz magának egy admin fiókot, majd beépít egy apró kódot, amely kiszűri ezt a fiókot a Felhasználók listájából. Ön megnyitja a vezérlőpultot, és nem lát semmi szokatlant – közben a támadó teljes hozzáféréssel rendelkezik. Ha valaki mégis megtalálja és törli a fiókot, a kártevő a következő oldalletöltéskor egyszerűen újra létrehozza.
Csak a látogatóknak mutatja magát
A fertőzés megnézi, hogy ki érkezett az oldalra. Ha Google-keresésből jött látogató és nincs bejelentkezve, elindul az átirányítás egy hirdetéses vagy adathalász oldalra. Ha viszont Ön írja be közvetlenül a címet, vagy be van jelentkezve adminként, a kártevő csendben marad, és tökéletesen normális oldalt mutat. Így akár hónapokig észrevétlen maradhat.
Hátsó kapu a rendszer legmélyén
A kártevő olyan helyre rejti el magát, ahol a WordPress minden oldalletöltéskor kötelezően lefuttatja, de a vezérlőpulton meg sem jelenik – így a felületről kikapcsolni vagy törölni sem lehet. A legmodernebb változatok a tényleges kártékony kódot már nem is fájlban tárolják, hanem az adatbázisban, ahonnan futás közben töltik be. A hagyományos vírusirtók ezt gyakorlatilag nem látják.
És ha a szomszéd oldal a hibás?
Van ennek a történetnek egy olyan fejezete is, amiről ritkán esik szó: a saját oldala akkor is megfertőződhet, ha Ön mindent tökéletesen csinál.
A legtöbb weboldal osztott tárhelyen fut, ahol egy szerveren több tucat, néha több száz ügyfél oldala osztozik. Ha a szerver nincs megfelelően beállítva – és sok szolgáltatónál nincs –, akkor egy megtámadott oldalról a kártevő át tud lépni a szomszédos fiókokba. Kiolvassa a szomszéd oldal adatbázis-jelszavát tartalmazó beállítófájlt, belép az adatbázisba, átírja az admin jelszót, és már bent is van.
A Wordfence 2026-ban több ilyen tömeges esetet dokumentált. A tanulság kijózanító: hiába tartja naprakészen a saját oldalát, ha a mellette futó, elhanyagolt weboldal miatt dől el az Ön sorsa is. A biztonság nem a bővítmények frissítésénél kezdődik, hanem a szerver megfelelő beállításánál.
Hogyan dolgozunk az incidens után?
Az irány nem változott – az egyedi fejlesztés eddig is a fő profilunk volt. Az viszont igen, hogy mennyire tartjuk ezt a kérdést sürgetőnek, és hogy mit teszünk azokért az ügyfelekért, akiknek ma még WordPress oldala van.
Üzletileg fontos oldal csak egyedi fejlesztésben
Ha a weboldaltól rendelés, fizetés, ügyféladat vagy a cég hírneve függ, azt Laravel alapon, saját kódból építjük meg. Nincs sablon, nincs huszonöt idegen bővítmény, nincs nyilvános verziószám, amit a botok kereshetnének. Ami az oldalon fut, azt mi írtuk – és ha hiba van benne, azt mi javítjuk, nem egy ismeretlen külföldi fejlesztő jóindulatára várunk.
Elkülönített, szigorúan beállított kiszolgálók
Az ügyfeleink oldalai úgy futnak, hogy még szerverszinten sem tudnak egymás fájljaihoz hozzáférni. Ezzel a „szomszéd oldal fertőzött meg" forgatókönyv egyszerűen kiesik. Ez nem extra szolgáltatás nálunk, hanem az üzemeltetés alapja.
Folyamatos ellenőrzés, nem évenkénti átnézés
Rendszeresen összevetjük az éles rendszerek fájljait azzal, aminek ott kell lennie. Ha bármi megváltozik – akár egyetlen karakter –, azt észrevesszük. Az öt órás időablak világában ez az egyetlen működő megközelítés.
Meglévő WordPress oldalak biztonsági átvilágítása
Ha Önnek most WordPress oldala van, és a fentiek után felmerült a kérdés, hogy vajon tiszta-e, azt meg tudjuk nézni. Átvizsgáljuk a fájlokat, a felhasználói fiókokat és az adatbázist is – nem csak a felületet, mert ott a legtöbb fertőzés nem látszik.
2026 szeptemberétől ez már jogi kérdés is
Van egy határidő, amiről érdemes tudni: 2026. szeptember 11-én lép teljes körűen hatályba az EU kiberrezilienciáról szóló jogszabálya (Cyber Resilience Act). Ettől kezdve az eddig önkéntes biztonsági gyakorlatokból szankcionálható jogi kötelezettségek lesznek.
A lényeg dióhéjban: aki digitális terméket – és ide tartoznak a weboldalak is – készít vagy üzemeltet az EU piacán, annak 24 órán belül jelentenie kell minden aktívan kihasznált sebezhetőséget, folyamatosan naprakész listát kell vezetnie arról, hogy milyen szoftverkomponensek futnak az oldalon, és kezelnie kell a biztonsági kutatóktól érkező bejelentéseket.
Ez véget vet annak a gyakorlatnak, amikor egy webfejlesztő átad egy oldalt, aztán évekig nem néz rá. És pontosan itt látszik meg a különbség a két megközelítés között: egy huszonöt bővítményből álló WordPress oldalról naprakész komponenslistát vezetni komoly folyamatos munka – egy saját fejlesztésű rendszernél viszont eleve tudjuk, mi fut benne, mert mi írtuk.
💡 Nem a WordPress ellen beszélünk. Az internet oldalainak több mint 40%-át hajtja, és egy blognál vagy egyszerű bemutatkozó oldalnál ma is jó választás. De ha a weboldal az üzlet része, akkor a négy érv együtt áll össze: a funkciók az üzleti igényhez igazodnak, az oldal gyors marad, a megjelenést nem a sablon szabja meg – és nem huszonöt idegen fejlesztő döntéseinek vagyunk kiszolgáltatva. Az első három érv üzleti előny. A negyedik az elmúlt hetekben kockázatkezelési kérdéssé vált.
Gyakran ismételt kérdések
Nézzük meg együtt, hol áll most az Ön weboldala
Akár WordPress oldala van, akár egyedi fejlesztést tervez: egy beszélgetésen átnézzük a jelenlegi helyzetet, és őszintén megmondjuk, mit látunk. Ha nincs teendő, azt is.
Felhasznált források
- A sebezhetőségek hivatalos leírásai: NIST National Vulnerability Database, GitHub Advisory Database
- Fenyegetettségi statisztikák és incidenselemzések: Patchstack, Wordfence, Sucuri Security Blog
- Szabályozási háttér: Európai Bizottság – Cyber Resilience Act
A cikkben szereplő incidensleírás saját tapasztalatunkon alapul. Ügyfeleink azonosítására alkalmas adatot nem közlünk. A hivatkozott sebezhetőségeket az érintett fejlesztők azóta javították – a cikk célja nem konkrét termékek rossz hírbe hozása, hanem annak bemutatása, hogy a harmadik féltől származó komponensekre épülő architektúra strukturális kockázatot hordoz.
