После срочного обновления WordPress: как проверить следы взлома

Срочное обновление WordPress закрывает известную уязвимость с момента установки. Но оно не отвечает на другой вопрос: успел ли кто-то воспользоваться этой уязвимостью раньше. Поэтому после критического патча полезно провести отдельную проверку — особенно если сайт обновили спустя несколько часов или дней после релиза.

Это не перестраховка. В июле 2026 года Patchstack зафиксировал первые попытки эксплуатации цепочки уязвимостей WordPress примерно через 90 минут после выпуска исправления. На уязвимые сайты шёл массовый, а не только адресный трафик. Из этого следует практическое правило: статус «обновлено» нельзя автоматически считать статусом «инцидента не было».

Обновление и расследование решают разные задачи

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

Если просто установить новую версию и удалить всё подозрительное, можно потерять время атаки, исходный файл и другие данные, по которым восстанавливают картину происшествия. Поэтому порядок действий важен: сначала фиксируем состояние, затем ограничиваем риск и только после этого очищаем или восстанавливаем сайт.

Сначала сохраните текущее состояние

До ручной очистки сделайте копию файлов и базы данных, сохраните журналы веб-сервера, PHP, панели хостинга и защитных средств. Такая копия может содержать заражённые файлы, поэтому её нельзя считать готовой точкой восстановления. Это снимок для анализа.

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

Определите окно риска

Окно риска начинается не тогда, когда владелец узнал об уязвимости, а когда уязвимая версия стала доступна извне. Для конкретного случая нужно установить:

какая версия WordPress, плагина или темы была установлена;
когда появилось исправление и когда его установили;
была ли уязвимая функция доступна без авторизации;
стояла ли перед сайтом защита и что именно она анализировала;
сохранились ли журналы за весь период.

Защитный экран снижает риск, но сам по себе не доказывает отсутствие проникновения. В описанной Patchstack кампании часть ранних правил можно было обойти, изменив форму доставки запроса. Проверять нужно не наличие одной блокировки, а совокупность журналов, файлов и событий WordPress.

Проверьте пользователей и доступы

Начните с учётных записей администраторов. Сопоставьте их с реальным списком сотрудников и подрядчиков. Обратите внимание на недавно созданных пользователей, смену ролей, незнакомые адреса электронной почты и аккаунты с правами выше необходимых.

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

Сверьте файлы с доверенными версиями

Официальная команда wp core verify-checksums сравнивает файлы ядра с контрольными суммами WordPress.org и делает это до загрузки WordPress. Параметр --include-root помогает заметить посторонние элементы в корне установки. Для плагинов из официального каталога есть команда wp plugin verify-checksums --all.

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

Отдельно просмотрите wp-content/uploads, wp-content/plugins, wp-content/themes и wp-content/mu-plugins. В каталоге загрузок обычно не должно быть PHP-файлов. MU-плагины особенно важны: они загружаются автоматически и могут не показываться в обычном списке плагинов.

Сопоставьте журналы и изменения

Руководство WordPress по усилению защиты называет журналы одним из главных источников для расследования: они помогают восстановить IP-адрес, время и последовательность действий. Ищите всплески запросов к уязвимому маршруту, необычные POST-запросы, обращения к новым PHP-файлам, входы в административную часть и изменения пользователей.

Не ограничивайтесь access-log. Полезны error-log, журнал PHP, история панели управления хостингом, события WAF, журнал отправки почты и аудит WordPress, если он был включён заранее. Проверяйте события по одной временной шкале: запрос к уязвимому маршруту, появление администратора, установка расширения и первый вызов неизвестного файла могут оказаться частями одного эпизода.

Выберите способ восстановления по результатам

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

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

Чек-лист после критического обновления

Записать прежнюю и текущую версии, время установки патча и часовой пояс.
Сохранить снимок файлов, базы и доступных журналов до очистки.
Определить период, когда уязвимая версия была доступна извне.
Проверить всех администраторов, новые аккаунты и изменение ролей.
Завершить неизвестные сессии и заменить доступы, которые могли быть раскрыты.
Сверить ядро и официальные плагины по контрольным суммам.
Проверить загрузки, плагины, темы и MU-плагины на новые исполняемые файлы.
Сопоставить access-log, error-log, события защиты и действия WordPress.
Проверить формы, письма, редиректы, поисковые страницы и задания cron после восстановления.
Настроить хранение журналов и контроль изменений на будущее.

Вопросы о проверке WordPress после обновления

Если WordPress обновлён, можно ли считать сайт безопасным?

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

Достаточно ли проверить контрольные суммы?

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

Чем здесь может помочь VOWE?

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