Восстановление взломанного WordPress: очистка сайта и устранение причины

Если WordPress взломали, задача состоит не только в том, чтобы убрать видимый вредоносный файл. Нужно понять, как злоумышленник получил доступ, найти все точки закрепления и вернуть сайт в работу так, чтобы заражение не появилось снова через несколько часов или дней.

Этот материал для владельцев сайтов и интернет-магазинов, которые заметили редиректы, неизвестных администраторов, спам-страницы, изменённые файлы, предупреждения хостинга или поисковых систем. Ниже — безопасная последовательность диагностики и восстановления без советов «удалите всё и начните заново».

Сначала сохранить состояние, потом чистить

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

Рабочий сайт при возможности переводят в контролируемый режим обслуживания или ограничивают доступ на уровне сервера. Если заражение активно раздаёт вредоносный контент, приоритет — остановить ущерб посетителям.

Почему простая переустановка WordPress не решает проблему

WordPress core можно заменить чистой копией, но вредоносный код часто находится не только там. Точки закрепления могут быть в uploads, mu-plugins, обычных плагинах, теме, базе данных, cron, дополнительных администраторах или серверных файлах вне web root.

Поэтому восстановление строится от доверенных источников: core сравнивается с официальными checksum, плагины и темы — с оригинальными пакетами, а пользовательские файлы проверяются отдельно.

Проверка WordPress core через WP-CLI

WP-CLI поддерживает проверку файлов ядра по официальным checksum. Команда помогает быстро увидеть изменённые или лишние файлы в core:

wp core verify-checksums

Для плагинов из WordPress.org можно использовать отдельную проверку checksum. Но отсутствие совпадения не всегда означает вирус: кастомные или коммерческие плагины могут не иметь публичных checksum, поэтому их нужно сравнивать с доверенным дистрибутивом.

Где искать закрепление злоумышленника

• неизвестные файлы PHP в uploads и временных каталогах;
• изменения в wp-config.php, index.php и серверных конфигурациях;
• неизвестные mu-plugins и обычные плагины;
• новые пользователи с ролью administrator;
• подозрительные cron-задачи;
• инъекции JavaScript и iframe в базе или шаблонах;
• файлы с недавним временем изменения, не связанным с обновлением.

Искать только по словам вроде eval или base64 недостаточно: они встречаются и в легитимном коде. Нужна проверка контекста, происхождения файла и поведения кода.

Пароли и ключи нужно менять после очистки

Если есть вероятность утечки доступа, после восстановления меняют пароли WordPress, хостинга, SFTP/SSH, базы данных и связанные API-ключи. WordPress security salts также стоит обновить, чтобы завершить старые авторизованные сессии.

Новые секреты нельзя хранить в публичном репозитории или пересылать в открытом виде. Для административных аккаунтов полезно включить двухфакторную аутентификацию и убрать пользователей, которым доступ больше не нужен.

Плагины и темы — частая точка входа

После очистки необходимо обновить WordPress, плагины и темы до поддерживаемых версий. Неиспользуемые компоненты лучше удалить, а не просто отключить. Если плагин заброшен или имеет известную проблему безопасности без исправления, его нужно заменить.

Кастомные изменения нельзя хранить внутри файлов стороннего плагина или родительской темы: обновление сотрёт их, а отказ от обновлений ради сохранения правок повышает риск. Для таких задач лучше использовать child theme или отдельный плагин. Если требуется аккуратно переработать существующий код, подходит услуга доработки WordPress.

Что проверить в базе данных

В базе стоит проверить пользователей, options, содержимое записей и виджетов, а также неизвестные autoload-настройки. Вредоносные скрипты могут храниться не в файлах, а в HTML контента или настройках темы.

Удалять записи по случайному совпадению строки опасно. Сначала нужно понять, какой плагин или функция создали значение, и только потом менять данные с резервной копией.

Когда нужен разработчик, а не автоматический сканер

Сканер полезен как один из источников сигналов, но он не знает архитектуру конкретного проекта. На сайте с кастомными интеграциями, WooCommerce, API и нестандартными плагинами автоматическое удаление может повредить рабочий код или пропустить вторую точку закрепления.

Если сайт приносит заявки или продажи, восстановление лучше выполнять с контролем файлов, базы, серверной конфигурации и журналов. Для этого можно привлечь WordPress-разработчика и после очистки настроить техническую поддержку WordPress.

Официальные источники

• WordPress.org — Hardening WordPress
• WP-CLI — wp core verify-checksums
• WP-CLI — wp plugin verify-checksums
• WordPress Developer Resources — Security

Если сайт уже показывает признаки взлома, лучше не экспериментировать на production. Можно прислать адрес сайта и описание симптомов, чтобы определить безопасный порядок диагностики.