Плагіни BdThemes встановлювали бекдори через отруєний API

Сім плагінів BdThemes для WordPress стали точкою входу в атаці на ланцюг постачання, хоча файли в офіційному каталозі плагінів не змінювалися. Зловмисники отруїли віддалений JSON-канал, який показував рекламні повідомлення у wp-admin. Коли адміністратор відкривав панель, ін’єктований скрипт міг створити сторонній обліковий запис адміністратора, завантажити вебшел і встановити приховані must-use плагіни для закріплення.

Wordfence повідомляє, що атаку спостерігали в реальних умовах 7 серпня 2026 року. До 8 серпня віддалений канал знову повертав чистий JSON, але це не видаляє вже створені облікові записи, вебшели чи механізми закріплення. Власникам сайтів із одним із зазначених плагінів потрібно перевірити базу даних і сервер поза звичайною панеллю WordPress.

Які плагіни BdThemes уражені?

Скомпрометований канал завантажував спільний компонент рекламних банерів Biggopti. Wordfence називає сім каталогів плагінів:

Наявність такого плагіна не доводить злам автоматично. Небезпечний сценарій вимагав, щоб отруєна відповідь потрапила до браузера авторизованого адміністратора. Найраніша можлива дата кампанії у хронології джерела — 23 червня; отруєні кінцеві точки зафіксували 6–7 серпня, а 8 серпня вони вже повертали чисті дані.

Як чистий плагін завантажив прихований бекдор

1. Плагін BdThemes отримував рекламний JSON із віддаленого сховища Sigmative.
2. Неекрановане значення display_id дало отруєній відповіді змогу вставити JavaScript на сторінку авторизованого wp-admin.
3. Скрипт використав чинну сесію адміністратора та nonce WordPress, щоб створити стороннього адміністратора.
4. Він завантажив фальшивий плагін із файлом emer-run.php, а потім записав must-use плагіни для входу за прихованим токеном і приховування створених зловмисником користувачів.
5. Результати надсилалися на інфраструктуру атакувальників. Альтернативне корисне навантаження генерувало передбачувані облікові дані з доменного імені сайту.

Тому перевірка цілісності файлів не виявляє початковий шлях атаки. Після виконання скрипту у привілейованій сесії адміністратора він уже міг змінити базу даних і сервер.

Що перевірити адміністраторам зараз?

Шукайте такі підтверджені джерелом індикатори. Назви файлів можуть змінюватися, тому відсутність одного точного імені не доводить, що сайт чистий.

• Імена адміністраторів із префіксом bd_ і шістьма наступними літерами або цифрами, а також неочікувані облікові записи з адресами @wordpress.org чи @developer.wordpress.org.
• Фальшивий плагін на кшталт wp-smart-thumbnails і файл вебшела emer-run.php.
• Неочікувані файли у wp-content/mu-plugins/, зокрема class-wp-token-validate.php, class-wp-query-*.php або wp-cache-optimizer.php.
• Параметри бази даних fz_emer_login_tokens або fz_emer_done_v1.
• Запити до ia-cdn[.]com/fz/ або неочікуваний трафік до отруєних шляхів API Sigmative.

Не покладайтеся лише на сторінку Користувачі у панелі. За даними дослідників, механізм закріплення перехоплював запити WordPress до бази даних, приховував сторонні облікові записи й змінював показану кількість користувачів. Порівняйте таблиці users і usermeta з відомим переліком адміністраторів та перевірте must-use плагіни безпосередньо на диску.

Що робити, якщо знайдено індикатор

1. Обмежте подальший доступ. Увімкніть контрольований режим обслуговування або обмежте адміністративний доступ. До очищення збережіть журнали вебсервера, CDN, автентифікації та бази даних.
2. Створіть криміналістичну копію. Збережіть поточний стан файлової системи й бази даних. Не видаляйте перший підозрілий файл, доки не зафіксуєте його шлях, час, хеш і пов’язані запити.
3. Видаліть доступ зловмисника поза панеллю WordPress. Перевірте адміністраторів у базі даних, каталоги wp-content/plugins/ і wp-content/mu-plugins/, видаліть сторонній код та облікові записи, а WordPress, теми й плагіни відновіть із довірених пакунків або перевіреної резервної копії до інциденту.
4. Змініть усі доступні сайту облікові дані. Оновіть паролі адміністраторів WordPress, salts, доступ до хостингу, SFTP/SSH, бази даних, CDN, SMTP, платіжних сервісів та API. Робіть це з чистого пристрою.
5. Перевірте повторну появу. Контролюйте нових користувачів, планувальник, конфігурацію сервера, вихідні запити й зміни файлів після відновлення. Тримайте уражені плагіни BdThemes вимкненими до появи перевіреного чистого випуску та офіційних рекомендацій.

Окремо підтримуйте актуальну версію ядра: у матеріалі про wp2shell у WordPress показано, як перевірити встановлення захисного випуску. Для ознак захоплення адміністратора корисний також чекліст інциденту Burst Statistics, а після виявлення вебшела — порядок перевірки серверного закріплення. Жодне з цих оновлень не замінює перевірку компрометації BdThemes.

Чисті файли не означають чистий сайт

У цьому інциденті офіційний каталог плагінів не був джерелом шкідливого навантаження. Довірений код отримував віддалені рекламні дані, а скомпрометована відповідь використала помилку екранування у браузері. Після запуску з правами адміністратора скрипт міг створити стійкі зміни на сервері та в базі даних.

Тому нова копія плагіна може бути чистою, а наявний сайт — уже зламаним. Відновлення має відповісти на два різні запитання: чи прибрали отруєний канал і чи встиг він створити закріплення саме на цьому сайті. Друге визначає лише перевірка бази даних, облікових записів, файлів і журналів.

References

1. Wordfence Threat Intelligence. «PSA: Supply Chain Compromise in BdThemes Ecosystem via Poisoned API Response». Wordfence, 8 серпня 2026 року. Технічний звіт та індикатори.
2. WordPress.org Documentation. «FAQ My Site Was Hacked». WordPress.org, дата доступу: 10 серпня 2026 року. Офіційні рекомендації з відновлення.