Пять лет незаметного бэкдора: как автор плагина для WordPress встроил скрытый канал управления в официальный репозиторий

Всё началось с рутинной проверки. Система обнаружила несовпадение хеша одного из файлов плагина версии 5.2.3 с эталонным значением из официального репозитория. Контрольная сумма md5 файла page_post_redirect_plugin.php на двенадцати сайтах не соответствовала ни одной из версий, когда-либо опубликованных на wordpress.org. Дальнейший анализ показал, что файл содержал дополнительную функцию, которая при каждом неавторизованном просмотре страницы отправляла HTTP-запрос на сторонний домен w.anadnet.com и вставляла полученный ответ в начало контента. При этом администраторы сайта не видели инъекции - проверка !is_user_logged_in() отключала её для вошедших пользователей. Удалённый сервер получал имя сайта, URI запроса и строку user-agent, что позволяло показывать разный контент в зависимости от посетителя.

Но это была только первая линия атаки. При проверке журнала ошибок выяснилось, что сразу после обновления плагина до чистой версии возникли фатальные ошибки, связанные с отсутствием класса обновлений Puc_v4p10_Plugin_UpdateChecker. Оказалось, что вредоносная версия содержала полную копию библиотеки Plugin Update Checker, а в основном файле плагина была прописана команда проверки обновлений с собственного сервера anadnet.com. Это означало, что плагин мог в любой момент получить и установить произвольный код от разработчика, минуя механизмы проверки wordpress.org.

Изучение истории коммитов в SVN (системе управления версиями WordPress) прояснило хронологию. Ещё в октябре 2020 года автор добавил в основную ветку папку с библиотекой обновлений и указал URL своего сервера. Версии 5.2.1 и 5.2.2, выпущенные через официальный репозиторий, уже содержали этот скрытый канал. Через три месяца, в феврале 2021 года, разработчик удалил эту папку из основной ветки с комментарием "Удалить папку pro updater". Однако все существующие установки продолжали обращаться к его серверу. В марте 2021 года сервер anadnet.com начал раздавать модифицированную версию 5.2.3, которая содержала уже упомянутую функцию инъекции контента. Автор перестал поддерживать этот канал, но плагин на заражённых сайтах постоянно пытался с ним связаться.

Архив Интернета (Wayback Machine) зафиксировал метаданные обновления в мае 2022 года. JSON-документ подтверждал, что сервер предлагал именно версию 5.2.3, а дата последнего изменения совпадала с датами модификации файлов на сайтах. Это доказывало, что атака была намеренной, а не случайной.

Примечательно, что сообщения о подозрительном поведении плагина появлялись ещё в январе 2022 года. Разработчик Nico Martin опубликовал на форуме поддержки WordPress полную информацию с индикаторами компрометации. Однако к тому моменту код в официальном репозитории уже был очищен от бэкдора. Модераторы закрыли плагин на 13 дней, но причиной указали не связанную с бэкдором XSS-уязвимость. После исправления XSS плагин снова открыли. Никаких мер по поводу скрытого канала принято не было. Аналитики из Plugin Vulnerabilities и Imunify360 позднее опубликовали независимые разборы, но широкой огласки это не получило.

В 2026 году владелец хостинга смог обезвредить угрозу на своих восемнадцати окружениях с помощью собственного инструмента CaptainCore: одним API-запросом он переустановил все экземпляры плагина на чистую версию 5.2.4 из официального репозитория. После этого он уведомил команду проверки плагинов WordPress, и 14 апреля 2026 года плагин был временно закрыт. Новые установки заблокированы, но существующие 70 тысяч сайтов всё ещё содержат бэкдор на диске. Их механизм проверки обновлений продолжает стучаться на сервер anadnet.com.

Ключевой вывод из этой истории: доверие к официальному репозиторию не означает доверие к каждому файлу, который загружает плагин во время выполнения. Если плагин регистрирует собственный источник обновлений, репозиторий перестаёт быть единственным источником истины. Разработчик может внедрить бэкдор, а затем удалить его из основной ветки - старые установки продолжат получать вредоносные версии. Единственный способ обнаружить такую утечку - регулярная проверка контрольных сумм всех файлов на всех сайтах. Встроенная команда wp plugin verify-checksums в WP-CLI делает это автоматически, сверяя хеши с официальным списком wordpress.org. Если бы такой аудит проводился регулярно, заражённые сайты были бы выявлены ещё в 2021 году.

Этот случай не уникален для WordPress. Подобная модель атаки возможна в любом пакетном менеджере, где пакет может загружать дополнительный код после установки. Один коммит в официальный репозиторий, три месяца распространения, тихое удаление библиотеки - и обратный канал остаётся активным на годы. Без проверки хешей и без отслеживания внешних вызовов защититься от такого практически невозможно.

Разработчикам плагинов стоит задуматься об этике. Автор anadnet мог бы одним действием устранить последствия: разместить на своём домене статический JSON-документ, который будет перенаправлять все запросы на официальную версию из wordpress.org. Это не требует хостинга бинарных файлов или динамической логики. Простая публикация файла на уже существующем домене очистила бы все 70 тысяч сайтов за несколько месяцев. Пока такой шаг не сделан, каждый сайт, использующий Quick Page/Post Redirect Plugin, остаётся уязвимым для удалённого выполнения кода по команде извне.

Специалистам по безопасности рекомендуется немедленно проверить свои флиты. Если на любом сайте установлен этот плагин, его следует удалить и заменить на альтернативу вроде Redirection от John Godley или Safe Redirect Manager. Для проверки достаточно выполнить команду wp plugin verify-checksums quick-pagepost-redirect-plugin - она укажет на несовпадение файлов. Единственный надёжный способ избежать подобных инцидентов в будущем - версия номер - это не гарантия целостности. Хеши не врут, и только они способны выявить разницу между тем, что загружено из репозитория, и тем, что на самом деле исполняется на сервере.

MD5

• ad717da18cf8a2b69899c0d7dafee05a