Бекдор WordPress SC держит копии полезной нагрузки минимум в восьми местах: в файлах, базе данных и даже в shared memory. Это неприятный сдвиг для администраторов и разработчиков: удалить «подозрительный плагин» уже недостаточно, потому что сайт может пересобрать заражение на следующей загрузке страницы.
О компрометации сообщает The Hacker News со ссылкой на исследователей Sucuri. Вредоносный код получил имя SC из-за маркеров «SC_» во внедренном содержимом, а сама Sucuri описывает его как самовосстанавливающуюся сетку: каждый элемент умеет восстановить остальные, если часть заражения вычистили вручную или автоматическим сканером.
Схема выглядит не как один веб-шелл, а как маленькая инфраструктура внутри WordPress. В цепочке участвует .user.ini, который заставляет PHP запускать загрузчик перед каждым запросом в директории. Затем подключается файл wp-content/c1b12371.php, который ищет скрытый файл с точкой в имени. Тот, в свою очередь, восстанавливает фальшивый плагин в mu-plugins из нескольких источников: копии в обычной папке плагинов, закодированного фрагмента в кэше и ZIP-архива восстановления со случайным hex-именем.
Дальше становится веселее, хотя администраторам сайтов тут не до шуток. В wp-content/db.php лежит сжатая и закодированная Base64-версия всей полезной нагрузки. WordPress загружает этот файл на этапе bootstrap, и он заново разворачивает плагин, если тот исчез или стал слишком маленьким. Файл advanced-cache.php включается еще раньше обычных плагинов, когда активировано кэширование, и может восстановить вредоносный модуль из пяти независимых мест: существующего mu-плагина, обычной копии плагина, сегмента System V shared memory, ZIP-бандла и базы данных.
Отдельная копия живет в теме khorshidi, внутри functions.php. Она повторяет поведение db.php и переписывает плагин при его отсутствии. Финальная полезная нагрузка ставится сразу в двух вариантах: как must-use plugin wp-content/mu-plugins/hyper-engine-kit.php и как обычный плагин wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php. Для WordPress это особенно болезненная комбинация: mu-плагины не управляются через стандартный экран плагинов так же очевидно, как обычные, а drop-in-файлы часто выглядят как часть легитимной конфигурации.
Код также не помогает аналитикам жить спокойнее. По данным Sucuri, у malware нет читаемых имен функций: сначала запускается декодер, который распутывает содержимое через подстановочный шифр. После старта бэкдор прячет себя в админке и проверках обновлений, снимает отпечаток зараженного сайта, связывается с управляющей инфраструктурой через Ethereum-блокчейн, получает дополнительные payload’ы, создает скрытого администратора и запускает цикл повторного заражения.
Практический риск не ограничивается контролем над CMS. Оператор может подгружать произвольный JavaScript и внедрять его на страницы сайта. Для бизнеса это сценарий скиммеров, подмены форм, кражи платежных данных или заражения посетителей другими вредоносными компонентами. Еще одна возможность — выполнение PHP-кода на сервере, а значит доступ к файловой системе, конфигам, токенам интеграций и соседним компонентам хостинга, если изоляция настроена плохо.
Самая неприятная часть — shared memory. На серверах с поддержкой System V вредоносный PHP записывается в сегмент памяти с фиксированным числовым ключом. Такой сегмент находится в RAM и переживает удаление файлов и чистку базы. На shared-хостинге он, по словам Sucuri, иногда может принадлежать другому аккаунту. Для команд эксплуатации это означает простую вещь: привычный чеклист «удалили левый файл, поменяли пароль, обновили плагин» не закрывает инцидент, если не проверены drop-in-файлы, mu-плагины, тема, база, cron и shared memory.
SC также регистрирует cron-хуки, включая рандомизированные имена и известный hook для загрузки данных. Важная деталь: системный cron может дергать WordPress cron-файл независимо от реального трафика. То есть заражение способно вернуться по расписанию, даже если на сайт никто не заходит. Для расследования это меняет таймлайн: «последний подозрительный запрос» может быть не точкой восстановления, а лишь одним из следов.
Как именно этот бекдор WordPress попал на сайт, исследователи пока не установили. Типовые входы знакомые: уязвимости в ядре WordPress, плагинах и темах, слабые пароли, атаки на цепочку поставки популярных расширений, небезопасные формы загрузки файлов и медиазагрузчики, через которые на сервер проталкивают PHP web shell. На фоне этого отдельно упоминается активная эксплуатация SQL-инъекции CVE-2026-1581 в плагине wpForo Forum: уязвимы версии до 2.4.14 включительно, CVSS — 7.5. По телеметрии Previdian, с 3 июля 2026 года зафиксировано менее 20 попыток эксплуатации с пяти IP-адресов из Болгарии, Швейцарии, Франции, США и Йемена.
Для разработчиков и владельцев сайтов вывод приземленный: лечить WordPress-инцидент теперь нужно как компрометацию системы, а не как уборку одного файла. Нужны проверка целостности ядра и плагинов, ревизия wp-content, drop-in-файлов и mu-plugins, поиск скрытых админов, анализ cron, дамп и чистка базы, перезапуск PHP-FPM или веб-сервера там, где могла использоваться shared memory, и восстановление из заведомо чистого бэкапа. Бекдор WordPress SC хорошо показывает новый стандарт атак на массовые CMS: устойчивость важнее скрытности, а один surviving copy превращается в полный откат всей «очистки» назад.