У одного из заметных поставщиков WordPress-инструментов сломалась не кнопка обновления, а сама цепочка доверия. Взлом BdThemes позволял злоумышленнику создавать скрытые учётные записи администраторов на сайтах, где стояли плагины вендора, а у флагманского Element Pack на WordPress.org указано более 100 тысяч активных установок.
По данным BleepingComputer, атакующий получил доступ на запись к инфраструктуре BdThemes и подменил удалённый JSON-поток, который открывался в браузере администратора через промо-компонент внутри панели WordPress. Это важная деталь: пользователю не нужно было устанавливать «левое» обновление, загружать архив со стороны или кликать по подозрительной ссылке. Достаточно было зайти в wp-admin под администратором, после чего вредоносный код отрабатывал в уже авторизованной сессии.
Под ударом оказались премиальные плагины и компоненты BdThemes, включая Element Pack, Prime Slider, Ultimate Post Kit, Pixel Gallery и Ultimate Store Kit. Субботой, 8 августа 2026 года, плагины были сняты с каталога WordPress.org до завершения проверки. Сам разработчик, если верить публикации, на момент выхода материала публичного заявления на своём сайте не сделал. Для тех, кто отвечает за сайты на WordPress в продакшене, сигнал неприятный, но предельно понятный: риск лежал не в «пиратской сборке», а в обычной рабочей интеграции с удалённым API поставщика.
Технически атака выглядела довольно изящно и потому опасно. Исследователи из Defiant, компании-разработчика Wordfence, зафиксировали активность через свой WAF 7 августа. По их данным, атакующий отравил статический JSON-ответ, который административный баннерный компонент подтягивал с удалённого сервера. Проблему усугубила ошибка в разборе этого JSON: код библиотеки Biggop Library, используемой компонентом Biggopti для загрузки промобаннеров, содержал XSS-уязвимость. Её, как сообщается, внесли ещё в марте 2026 года. Иначе говоря, злоумышленнику не пришлось ломать каждый сайт по отдельности: достаточно было вмешаться в верхний уровень поставки данных и использовать уже встроенный у клиента баг.
Полезная нагрузка была не только про создание нового администратора. В публикации говорится, что внедрённый JavaScript использовал легитимную сессию администратора для создания rogue admin accounts, а дополнительный файл w2.js закреплялся через веб-шелл emer-run.php, установленный в виде поддельного плагина. Более того, код вмешивался в WordPress-запросы к базе так, чтобы скрыть созданные админ-аккаунты из пользовательского списка. Это уже не просто «подсунули баннер», а полноценная операция на удержание доступа. Компрометация выглядела тихо, не требовала модификации файлов со стороны администратора и повторялась каждый раз, когда авторизованный пользователь открывал любую страницу wp-admin.
Почему эта история важнее очередного бага в плагине
Сама по себе XSS-ошибка в админке WordPress давно не сенсация. Проблема в том, что здесь она была завязана на внешнюю инфраструктуру вендора. Если верить разбору Defiant, два заражённых API-эндпоинта позже начали снова отдавать чистый JSON, но это не отменяет главного: доверенный канал между плагином и поставщиком легко превратился в точку входа. Для бизнеса это означает неприятную вещь: даже если ваш CI/CD в порядке, а обновления ставятся дисциплинированно, риск может приехать через «безобидный» внешний виджет, баннер или телеметрию внутри админки.
У этой истории есть и более широкий контекст. Исследователи Wordfence связали инфраструктуру управления атакой с тем же актором, которого ранее упоминали в компрометациях Advanced Responsive Video Embedder и OptinMonster. На фоне недавних supply-chain инцидентов в экосистеме WordPress это уже выглядит не как одиночная удача злоумышленника, а как повторяемый приём: искать плагины с широкой установочной базой, атаковать не конечный сайт, а звено поставки и использовать доверие к «родному» каналу данных. В мире npm это давно стало почти рутиной, но WordPress, судя по всему, догоняет с собственной спецификой.
Для русскоязычной IT-аудитории здесь несколько практических выводов. Разработчикам плагинов и SaaS-команд, которые отдают в клиентские панели удалённый контент, придётся внимательнее смотреть на экранирование вывода, модель доверия к JSON-ответам и права доступа к storage bucket. Продактам и владельцам веб-платформ полезно пересмотреть сам вопрос: зачем вообще в административной панели живут внешние промо-блоки, если цена ошибки — скрытый администратор на боевом сайте. А тем, кто отвечает за эксплуатацию WordPress, стоит проверять не только список плагинов, но и состав админ-учёток, наличие неожиданных расширений, следы webshell и любые фоновые обращения к внешним API из панели управления.
Что делать владельцам сайтов и командам поддержки
Проблема на момент публикации была указана как не закрытая патчем, поэтому логика реакции должна быть консервативной. Если в инфраструктуре используются продукты BdThemes, разумно провести аудит административных аккаунтов, проверить, не появились ли поддельные плагины, и сопоставить логи входов с периодом как минимум с 23 июня 2026 года — это самая ранняя возможная дата начала кампании, которую смогли восстановить исследователи. Полагаться только на визуальный осмотр админки в таком кейсе наивно: именно её злоумышленник и пытался обмануть. Нужны проверка базы, файловой системы и журналов на уровне хостинга или WAF.
Взлом BdThemes хорошо показывает, почему рынок постепенно отказывается от романтической идеи, что цепочка поставки заканчивается на установке плагина из официального каталога. На деле она продолжается каждым внешним запросом, каждым JSON-ответом и каждым «служебным» компонентом, который разработчик однажды решил показать в админке. У WordPress это особенно болезненно: слишком много сайтов строятся на сторонних расширениях, а значит, следующая крупная история почти наверняка снова будет не про один баг, а про доверие к целому слою экосистемы.