Взломали сайт WordPress: как восстановить работу и убрать заражение

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

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

6 октября 2026 года вышел WordPress 7.1.3 с исправлениями безопасности; разработчики рекомендуют срочное обновление. Это повод проверить состояние проекта. Сам номер установленной версии не доказывает взлом, а обновление ядра не заменяет расследование уже обнаруженного заражения.

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

Скачайте чек-лист приемки восстановления — RU, CSV или чек-лист на английском — CSV. В нем 18 проверок: ограничение опасного поведения, сохранение данных, восстановление, доступы, бизнес-сценарии и наблюдение. Результаты и обезличенные подтверждения заполняет исполнитель вместе с владельцем сайта. Таблица не подтверждает устранение конкретного инцидента без выполненных проверок.

Какие признаки нужно проверить

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

Наблюдение	Что сохранить	Какой вопрос проверить
Переход на чужой домен	Исходный URL, время, условия перехода	Где появился редирект и какие запросы он затрагивает
Неизвестные страницы в поиске	Примеры адресов и результаты проверки URL	Есть ли спам в файлах, базе или генерируемом ответе
Новый администратор	Имя учетной записи и сведения о создании	Кто разрешил доступ и какие действия выполнены
Хостинг ограничил сайт	Текст уведомления и время	Что обнаружил провайдер и какие ресурсы затронуты
Файл возвращается после удаления	Путь и время повторного появления	Какой процесс, доступ или задача его создает
Заявки перестали доходить	Время последней успешной доставки	Поломка интеграции, изменение реквизитов или иной сбой

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

Подозрительные страницы не следует открывать на рабочем компьютере с активными учетными записями. Специалист может исследовать ответы HTTP и код в изолированной среде. Если проблема проявляется только у части посетителей, в карточке инцидента должны быть условия: вход из поиска, тип устройства, авторизация, конкретный адрес.

Первые действия владельца сайта

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

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

Практический порядок:

1. Связаться с хостингом и сопровождением, передать симптомы и время обнаружения.
2. Ограничить опасные ответы сайта и при необходимости остановить рекламный трафик.
3. Сохранить файлы, базу, доступные журналы и сообщения провайдера в защищенном месте.
4. Отдельно перечислить новые бизнес-данные и внешние сервисы, которые продолжают работать.
5. Определить, кто обследует причину, кто восстанавливает и кто принимает результат.

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

Что сохранить перед восстановлением

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

В рекомендациях Hardening WordPress описана польза нескольких сохраненных состояний: компрометацию могут заметить позднее ее начала. Проверяйте выбранную копию на отдельном контуре. Дата до появления видимой рекламы еще не подтверждает отсутствие скрытого изменения.

Для бизнес-данных составьте перечень:

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

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

Как выбрать путь восстановления

Состояние проекта	Возможный путь	Что требуется подтвердить
Есть проверенная копия до инцидента	Восстановить ее на отдельном контуре	Чистоту, совместимость и сохранность новых данных
Бэкап есть, его чистота неизвестна	Обследовать несколько сохраненных состояний	Когда появились изменения и какой набор можно использовать
Чистого бэкапа нет, исходники доступны	Собрать доверенную версию приложения	Происхождение компонентов и проверку переносимых данных
Сильно изменена собственная тема	Сопоставить ее с доверенным исходником	Какие изменения относятся к продукту, какие не разрешены
Подозрение на компрометацию сервера или аккаунта	Восстановить доверенное окружение с провайдером	Безопасность инфраструктуры и других проектов

Выбор «восстановить из бэкапа» должен сопровождаться датой копии, перечнем переносимых данных и проверкой причины. Если вернуть уязвимый компонент и прежние доступы, проблема может возникнуть снова. Сохранение рабочего процесса требует и исправления условий, при которых произошло вмешательство.

При сборке проекта используйте доверенные дистрибутивы ядра и расширений, а собственный код сравнивайте с подтвержденной версией. Загруженные пользователями файлы и база проверяются отдельно. Перенос всего wp-content из подозрительного проекта целиком переносит и неизвестные изменения.

Как сохранить новые заказы: условный пример

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

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

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

Это условный сценарий, а не описание проекта NBM-IT. Реальная процедура зависит от хранения заказов, настроек плагинов и внешних систем. Если достоверность записей вызывает сомнение, автоматический перенос заменяют контролируемой сверкой с владельцем данных.

Какие проверки помогают найти изменения в WordPress

Проверка файлов по официальным контрольным суммам дает ограниченное, но полезное свидетельство. WP-CLI core verify-checksums сравнивает файлы ядра с данными WordPress.org и выполняется до загрузки WordPress. Нужно учитывать версию и локаль проверяемого дистрибутива.

Успешная проверка ядра не охватывает всю базу, собственную тему, загрузки, настройки сервера и доступы. Несовпадение требует разбора: оно показывает изменение относительно дистрибутива, но само по себе не объясняет его происхождение. Сохраните список результатов вместо немедленного удаления найденных файлов.

Для расширений существует WP-CLI plugin verify-checksums, использующая данные WordPress.org. Для платного или собственного компонента может не быть подходящих контрольных сумм. Отсутствие проверки такого компонента нужно отметить в отчете и компенсировать сравнением с доверенным исходником.

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

Как закрыть причину и восстановить доступы

Попросите исполнителя разделить подтвержденное и предполагаемое. «Найден измененный файл» — установленный факт. «Он появился через конкретный плагин» — вывод, для которого нужны дополнительные признаки. Если первоначальный путь неизвестен, в акте работ должны остаться эта неопределенность и расширенный план защиты.

Согласуйте перечень затронутых доступов: WordPress, хостинг, передача файлов, база и внешние интеграции. В FAQ WordPress рассматриваются смена доступов и обновление секретных ключей для завершения активных сессий. Работайте с доверенного устройства и координируйте изменения, чтобы не остановить восстановленные интеграции.

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

Штатные обновления после обследования лучше проводить по отдельному плану обновления WordPress. Проверяйте текущие версии у разработчиков компонентов: требования совместимости и доступные исправления меняются.

Когда можно возвращать сайт в работу

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

Область	Условие приемки	Подтверждение
Опасное поведение	Исходный симптом не воспроизводится по проверенным условиям	Список адресов и проверок
Состав приложения	Компоненты имеют подтвержденное происхождение	Версии и результаты сравнения
Пользователи и доступы	Неизвестные полномочия разобраны, доступы обновлены	Перечень действий без паролей
Заказы и оплаты	Восстановленные записи сверены с внешними системами	Контрольные ID и результаты сверки
Формы	Обращение доходит до нужного получателя	Одна помеченная тестовая заявка
Авторизация	Разрешенные роли входят и выполняют свои действия	Протокол проверки ролей
SEO	Рабочие страницы имеют согласованные ответы и метаданные	Проверка основных шаблонов
Сопровождение после очистки	Есть новая резервная копия и порядок наблюдения	Ответственный и инструкция

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

На момент запуска зафиксируйте контрольное состояние и план наблюдения. Следите за повторным появлением исходных симптомов, новыми изменениями, ошибками и бизнес-доставкой. Продолжительность и интенсивность наблюдения выбирают по масштабу инцидента; обещание «проверили один раз — больше не взломают» непроверяемо.

Как проверить сайт в поиске после очистки

Откройте отчет «Проблемы безопасности» в Search Console. Google рекомендует устранить все перечисленные проблемы, а затем запросить проверку с описанием исправлений и подтверждением результата. Примеры URL в отчете могут быть неполными.

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

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

Что спросить у подрядчика по восстановлению

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

Уточните состав результата:

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

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

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

Что изменить в процессе поддержки

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

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

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

FAQ

Можно ли восстановить сайт, если чистого бэкапа нет?

Иногда возможно собрать приложение из доверенных компонентов и перенести проверенные данные. Объем работ зависит от наличия исходников и состояния базы. Сначала нужно обследование; обещать сохранение всего содержимого до него нельзя.

Поможет ли переезд на другой хостинг?

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

Почему вирус возвращается после удаления файла?

Сохранился способ его повторного создания или не устранен доступ к проекту. Возможные направления проверки — код, задачи, учетные записи и окружение. Конкретную причину устанавливают по доказательствам; название файла ее не определяет.

Достаточно ли установить защитный плагин?

Плагин может помочь с отдельными проверками и ограничениями. Он не заменяет сохранение данных, обследование окружения, восстановление доверенного кода и проверку бизнес-сценариев. Уточните, какие именно результаты он подтверждает.

Нужно ли менять домен после взлома?

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

Источники

• WordPress 7.1.3: обновление безопасности от 6 октября 2026.
• WordPress: FAQ My site was hacked.
• WordPress: Hardening WordPress.
• WP-CLI: проверка контрольных сумм ядра.
• WP-CLI: проверка контрольных сумм плагинов.
• Google: отчет о проблемах безопасности.

Источники проверены 9 октября 2026 года. Порядок организации работ, таблицы приемки и пример с заказами — рекомендации и условный сценарий; они не описывают инцидент клиента NBM-IT.