Коротко: в 2025 году кто-то скупил на Flippa (площадке для продажи готовых интернет-бизнесов) набор из более чем 30 плагинов WordPress. Затем выпустил одно тихое обновление «для совместимости», в котором спрятал бэкдор (скрытый чёрный ход в коде), дал ему отлежаться около восьми месяцев — пока сайты спокойно его ставили — и в начале апреля 2026 года включил. Самое неприятное тут не код. Плагины не менялись — сменился их владелец, и сайтам, на которых они стоят, об этом никто не сообщил.
Мы держим хостинг с обслуживанием и следим за такими историями по клиентским сайтам, поэтому ниже — разбор простым языком, со ссылками на тех, кто реально вскрыл атаку, а не на пересказы.
Что произошло, по порядку
Это был набор Essential Plugin — линейка небольших утилит (всплывающие окна, таймеры обратного отсчёта, слайдеры), у которых вместе более 20 000 активных установок по счётчику самого WordPress.org; в рекламе разработчик заявлял более 400 000 установок и 15 000 клиентов. В 2025 году весь набор продали на Flippa за нераскрытую сумму покупателю, известному только под псевдонимом «Kris».
Дальше ловушку готовили не спеша:
| Когда | Что произошло |
|---|---|
| 2025 | Набор из 30+ плагинов продают на Flippa новому владельцу |
| 8 авг. 2025 | Выходит версия 2.6.7. В списке изменений — «проверка совместимости с WordPress 6.8.2». На деле добавлена 191 строка PHP (язык, на котором работает WordPress) — спрятанный бэкдор |
| Около 8 месяцев | Код лежит без движения. Сайты ставят и автоматически обновляют плагин, доверяя тому, что работает у них годами |
| Начало апр. 2026 | Бэкдор удалённо включают, и он начинает внедрять вредоносный код |
| 7 апр. 2026 | Команда плагинов WordPress.org подтверждает атаку, принудительно рассылает исправление и убирает все затронутые плагины из каталога |
Отлёжка — самый расчётливый ход. Новый плагин с бэкдором ловят быстро. А плагин, которому вы доверяете три года и который ночью сам незаметно обновился, — нет.
Оружие замаскировали под «аналитику»
Когда бэкдор включился, плагины обратились к analytics.essentialplugin.com — поддомену с безобидным названием «аналитика» — и скачали на сайт файл wp-comments-posts.php. Этот файл записал около 6 КБ PHP-кода прямо в wp-config.php (он вырос с 3 345 до 9 540 байт) — один из самых чувствительных файлов любого WordPress-сайта. Оттуда атакующий мог писать на сайт что угодно: спам-страницы, переадресации, новый вредоносный код.
Вы ничего не нажимали. Вас не разводили по почте. Угроза пришла изнутри — из программы, которую вы поставили сами и намеренно.
Атаку поймали по резервной копии
Точную хронологию восстановила Anchor Hosting, которая держит ежедневные копии через restic. Они достали wp-config.php из нескольких копий за разные дни, сравнили размеры файла и вычислили окно активного внедрения: 6 апреля 2026 года, с 04:22 до 11:06 UTC — шесть часов сорок четыре минуты. Без копий по датам этот дописанный код выглядит просто частью вашего сайта.
В этом и тихий урок: резервные копии нужны не только чтобы восстановиться после аварии. Это ещё и единственная честная запись того, каким сайт был до того, как его что-то изменило.
Так кто на самом деле пострадал?
Вот что обычно опускают в заголовках. Подтверждённого числа реально заражённых сайтов никто не публиковал, и ни одного названного пострадавшего не объявилось. Задокументирован не «пострадавший», а масштаб риска.
И под ударом были самые обычные сайты. Эти плагины — всплывающие окна, таймеры, слайдеры — те самые незаметные мелочи, которые однажды ставят и забывают магазины малого бизнеса, блоги и сайты-визитки. Не защищённые корпорации со своей службой безопасности, а огромная масса обычных небольших сайтов.
Но риск — это ещё не заражение. Окно активного внедрения длилось меньше семи часов, а на следующий день WordPress.org принудительно разослал исправление. Те самые 6 КБ вредоносного PHP в wp-config.php получили те сайты, на которых нужный плагин был активен и успел в это окно обратиться к серверу злоумышленника, — и для них атакующий мог писать на сайт что угодно: спам-страницы, скрытые переадресации, новый вредоносный код, а оттуда и дальше вглубь.
Пострадавшие, которых никто не считает, — это брошенные сайты. Принудительное обновление доходит только до тех, кто ещё на связи с WordPress.org; а сайт, в который никто не заходит — из тех, чей разработчик тихо ушёл, — может до сих пор тихо нести в себе этот бэкдор. Короткое и громкое окно попало в новости. А тихая, растянутая часть — то, что беспокоит нас.
Дыра, которую нельзя залатать: чьи на самом деле ваши плагины
Вот чем эта атака отличается от обычного совета «обновляйте плагины». Искать было нечего — ошибки в коде не было. Плагины были в порядке. Изменилось то, кто ими управляет. Как сформулировала Anchor Hosting, «у WordPress.org нет механизма, который бы отмечал или проверял передачу плагина новому владельцу. Пользователям не приходит никакого уведомления о смене владельца». Patchstack — компания по безопасности, разобравшая код, — подтвердила бэкдор более чем в 20 плагинах из набора.
То есть посторонний может купить плагин, на котором держится ваша контактная форма, баннер о куках или таймер обратного отсчёта, — а узнаете вы об этом, только когда сайт начнёт раздавать спам.
Что это значит для владельца бизнеса
Лично проверить, кто незаметно скупил каждый плагин на вашем сайте, вы не сможете. Но риск резко падает от пары привычек:
- Меньше плагинов. Каждый — это маленькая компания, которую завтра могут продать. Опаснее всего тот, что поставили однажды и забыли.
- Замечайте изменения. Внезапное ночное обновление, файлы, которых вы не создавали, выросший без причины
wp-config.php— это сигналы, если есть кому смотреть. - Держите резервные копии отдельно от сервера и по датам — не «копии включены», а реально отдельно. Это и восстановление, и доказательство.
- Следите за лентами безопасности. Когда выходит такая история, всё решает разрыв между «уязвимость раскрыли» и «закрыли на вашем сайте» — вот где бесплатно посмотреть, какие дыры угрожают сайту.
Где здесь мы
По большей части это и есть то, что незаметно делает хостинг с обслуживанием: держать число плагинов небольшим, замечать лишние изменения файлов, хранить проверенные копии отдельно от сервера и следить за сводками по безопасности — чтобы такая история обернулась правкой на пять минут, а не разгребанием выходных. Сайт ваш — но кто-то должен следить, какая программа на нём работает и принадлежит ли она ещё тем, кому вы думаете. Это и есть работа. (Сайт сделали и оставили без присмотра? Начните отсюда: разработчик пропал — кто теперь следит за сайтом.)