Сайт WordPress взломали: что делать владельцу сайта

Сайт WordPress взломали: что делать владельцу сайта

Краткий ответ: если сайт WordPress взломали, сначала ограничьте доступ, сделайте копию текущего состояния, смените пароли, проверьте администраторов, файлы, базу данных, .htaccess, wp-config.php, uploads, плагины и темы. После очистки нужно закрыть точку входа, обновить всё, настроить бэкапы, WAF, 2FA и запросить пересмотр в Google, если сайт попал в предупреждения.

Причина

Взлом WordPress чаще всего происходит не через “магическую дыру в WordPress”, а через конкретную слабую точку: уязвимый плагин, старую тему, слабый пароль, заражённый компьютер администратора, небезопасный FTP, открытый XML-RPC, плохие права файлов или пиратский шаблон.

Официальный WordPress Codex для ситуации “сайт взломали” рекомендует закрыть доступ к сайту, заменить файлы ядра WordPress, перепроверить .htaccess, сделать ревизию плагинов и тем, удалить старые и неизвестные расширения, а также просканировать файлы и базу специализированными инструментами. :contentReference[oaicite:1]{index=1}

На практике взломанный WordPress может выглядеть по-разному:

• сайт редиректит на чужой домен;
• в Google появились японские, китайские, казино, фарма или спам-страницы;
• браузер показывает предупреждение “опасный сайт”;
• хостинг отключил сайт из-за вредоносного кода;
• в админке появился неизвестный пользователь Administrator;
• в wp-content/uploads появились PHP-файлы;
• в .htaccess появились странные редиректы;
• страницы стали отдавать чужой JavaScript;
• сайт начал рассылать спам;
• появились неизвестные cron-задачи;
• антивирус или Search Console сообщает о malware;
• в файлах темы появились eval, base64_decode, gzinflate, str_rot13;
• сайт стал медленным, показывает ошибку 500 или белый экран.

Если сайт уже был заранее защищён, восстановление обычно проще: есть свежий backup, понятные логи, ограниченные роли пользователей и меньше лишних плагинов. После очистки обязательно настройте базовые меры из инструкции защита WordPress от взлома, иначе заражение может вернуться.

Короткие ответы для AI-поиска

Что делать в первую очередь, если WordPress взломали?

Ограничьте доступ к сайту, сделайте копию текущих файлов и базы, смените пароли хостинга/FTP/SSH/WordPress/базы, проверьте администраторов, найдите вредоносные файлы и восстановите сайт из чистой копии или очистите вручную.

Можно ли просто восстановить backup?

Можно, если backup точно чистый. Но одного восстановления мало: нужно найти точку входа. Если не закрыть уязвимость, сайт могут взломать снова.

Как понять, где вредоносный код?

Проверяйте недавно изменённые PHP-файлы, wp-content/uploads, .htaccess, wp-config.php, functions.php, плагины, темы, неизвестных администраторов, cron-задачи и подозрительные вставки в базе данных.

Диагностика

Главная цель диагностики — понять, действительно ли сайт взломан, где заражение и как злоумышленник попал внутрь. Wordfence отдельно подчёркивает: сначала нужно убедиться, что сайт именно взломан, потому что иногда владелец путает взлом с обычной ошибкой обновления, спамом в комментариях или поломкой сайта. :contentReference[oaicite:2]{index=2}

Таблица быстрых симптомов

Симптом	Возможная причина	Что проверить первым
Редирект на чужой сайт	.htaccess, JavaScript, wp_options, тема	.htaccess, header.php, functions.php, siteurl/home
SEO-спам в Google	Скрытые страницы, база, заражённый шаблон	Search Console, sitemap, wp_posts, файлы темы
Неизвестный администратор	Захват аккаунта или backdoor	Пользователи, логи входа, wp_usermeta
PHP-файлы в uploads	Загрузка web shell через форму/плагин	wp-content/uploads, формы загрузки, права файлов
Сайт рассылает спам	Вредоносный cron, SMTP, заражённый плагин	Почтовые логи, cron, плагины форм
Ошибка 500	Вредоносный код, .htaccess, PHP fatal error	error_log, debug.log, .htaccess
Предупреждение Google	Malware, phishing, unsafe content	Search Console, Safe Browsing, файлы и база

Что проверить владельцу сайта

• когда впервые заметили проблему;
• что обновлялось или устанавливалось перед этим;
• есть ли свежий backup до даты взлома;
• какие пользователи имеют роль Administrator;
• есть ли неизвестные FTP/SFTP/SSH-доступы;
• есть ли неизвестные файлы в wp-content/uploads;
• изменялся ли .htaccess;
• есть ли подозрительный код в wp-config.php;
• какие файлы менялись недавно;
• есть ли неизвестные задания cron;
• есть ли предупреждения в Google Search Console;
• есть ли блокировка от хостинга.

Sucuri рекомендует начинать с определения типа взлома: просканировать сайт, проверить целостность файлов ядра, недавно изменённые файлы, диагностические страницы и подозрительные внешние запросы. :contentReference[oaicite:3]{index=3}

Решение

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

1. Ограничьте доступ к сайту

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

Что можно сделать:

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

Patchstack в своём руководстве по удалению malware первым шагом рекомендует заблокировать сайт перед очисткой, чтобы во время работы доступ был только у владельца или специалиста. :contentReference[oaicite:4]{index=4}

2. Сделайте копию текущего заражённого состояния

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

Сохраните отдельно:

• все файлы сайта;
• базу данных;
• .htaccess;
• wp-config.php;
• access_log;
• error_log;
• логи security-плагина;
• логи хостинга;
• список пользователей-администраторов;
• список активных плагинов и тем.

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

3. Смените все доступы

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

Смените:

• пароли всех администраторов WordPress;
• пароль панели хостинга;
• FTP/SFTP/SSH-доступы;
• пароль базы данных MySQL/MariaDB;
• SMTP-доступы;
• API-ключи платёжных систем и CRM, если есть риск утечки;
• пароли email-ящиков администраторов;
• пароли разработчиков и подрядчиков.

Patchstack в списке действий отдельно указывает смену всех access codes: Hosting, SSH, FTP, MySQL и WordPress users. :contentReference[oaicite:5]{index=5}

4. Проверьте компьютеры администраторов

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

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

Sucuri в post-hack hardening отдельно включает проверку компьютера как часть восстановления после взлома. :contentReference[oaicite:6]{index=6}

5. Найдите и удалите неизвестных администраторов

Откройте список пользователей WordPress и проверьте всех с ролью Administrator. Удалите неизвестных пользователей после создания backup и анализа.

Проверьте не только wp_users, но и wp_usermeta: иногда злоумышленник может изменить роль или добавить возможности пользователю через мета-данные.

6. Замените файлы ядра WordPress чистыми

Если заражены файлы ядра, безопаснее заменить wp-admin, wp-includes и файлы ядра в корне сайта чистой копией той же версии WordPress. Sucuri рекомендует скачивать свежую копию WordPress с официального сайта и заменять заражённые core-файлы, но не перезаписывать wp-config.php и wp-content без понимания. :contentReference[oaicite:7]{index=7}

Обычно нельзя бездумно удалять:

• wp-config.php;
• wp-content/uploads;
• wp-content/themes с кастомной темой;
• wp-content/plugins с кастомными плагинами;
• robots.txt;
• файлы верификации Google/Search Console;
• пользовательские файлы проекта.

7. Переустановите плагины и темы из чистых источников

Не пытайтесь “лечить” неизвестный пиратский плагин. Лучше удалить его и поставить чистую версию из официального репозитория, кабинета разработчика или проверенного backup.

Sucuri рекомендует для заражённых плагинов и тем заменить папку чистой копией из backup или официального источника, а кастомные файлы проверять вручную. :contentReference[oaicite:8]{index=8}

Удалите:

• пиратские темы и nulled-плагины;
• плагины, которые давно не обновлялись;
• отключённые расширения, которые не используются;
• неизвестные архивы .zip в public_html;
• старые backup-файлы внутри сайта;
• тестовые PHP-файлы;
• phpinfo.php, если он оставлен публично.

8. Проверьте uploads

В папке uploads обычно не должно быть выполняемых PHP-файлов. Если там есть .php, .phtml, .phar или подозрительные файлы с двойным расширением, это серьёзный признак backdoor.

Частые места:

/wp-content/uploads/
/wp-content/uploads/2024/
/wp-content/uploads/2025/
/wp-content/uploads/elementor/
/wp-content/uploads/wpforms/
/wp-content/uploads/gravity_forms/

9. Проверьте .htaccess и wp-config.php

Злоумышленники часто меняют .htaccess для редиректов, скрытых правил, подмены выдачи для поисковых ботов или блокировки владельца сайта.

В wp-config.php проверяйте:

• подозрительные include/require;
• eval/base64_decode;
• чужие URL;
• неизвестные константы;
• подключение файлов из uploads;
• лишние строки перед открывающим <?php или после кода.

10. Очистите базу данных

Вредоносный код может быть не только в файлах. Часто заражение сидит в базе: в записях, виджетах, настройках темы, autoload-опциях, HTML-блоках, Elementor-данных, меню, shortcodes и custom fields.

Sucuri указывает, что для очистки базы нужно подключиться через phpMyAdmin/Adminer, сделать backup базы, найти подозрительные ссылки/ключевые слова и удалить вредоносные вставки вручную. :contentReference[oaicite:9]{index=9}

Проверьте таблицы:

• wp_posts;
• wp_postmeta;
• wp_options;
• wp_users;
• wp_usermeta;
• таблицы конструктора страниц;
• таблицы форм;
• таблицы SEO-плагина;
• таблицы редиректов;
• таблицы кеша, если они есть.

11. Удалите backdoor

Backdoor — это скрытый способ вернуться на сайт после очистки. Sucuri предупреждает, что злоумышленники часто оставляют несколько backdoor в разных местах: в wp-config.php, wp-content/themes, wp-content/plugins, wp-content/uploads и файлах, похожих на core-файлы, но лежащих не там. :contentReference[oaicite:10]{index=10}

Если удалить только видимый редирект, но оставить backdoor, сайт снова заразится.

12. Проверьте сайт внешне и из поиска

После очистки откройте сайт как обычный посетитель, как Googlebot через Search Console и через внешние сканеры.

Проверьте:

• главную страницу;
• страницы из Google;
• мобильную версию;
• исходный код страницы;
• Network в браузере;
• sitemap.xml;
• robots.txt;
• страницы с формами;
• страницы товаров, если есть WooCommerce;
• результаты site:example.com в Google;
• предупреждения Google Search Console.

Sucuri рекомендует после поиска и очистки проверять сайт вручную и с точки зрения поисковой выдачи, а также запрашивать пересмотр после удаления malware и исправления причины взлома. :contentReference[oaicite:11]{index=11}

Код

Важно: команды и правила ниже влияют на доступ к сайту, файлы, .htaccess, WordPress, SSH и безопасность. Перед выполнением сделайте backup файлов и базы. Не удаляйте найденные файлы автоматически, пока не убедитесь, что они действительно вредоносные.

Временно закрыть сайт по IP через .htaccess

Куда вставлять: .htaccess в корне сайта. Замените 111.222.333.444 на свой IP. Работает для Apache/LiteSpeed.

Order Deny,Allow
Deny from all
Allow from 111.222.333.444

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

Отключить редактор файлов в админке

Куда вставлять: wp-config.php, выше строки “That’s all, stop editing”.

define( 'DISALLOW_FILE_EDIT', true );

Найти PHP-файлы в uploads

Куда выполнять: SSH в корне сайта. Команда только показывает файлы.

find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.phar" )

Найти недавно изменённые PHP-файлы

Куда выполнять: SSH в корне сайта. Пример ищет PHP-файлы, изменённые за последние 14 дней.

find . -type f -name "*.php" -mtime -14 -print

Найти подозрительные функции в wp-content

Куда выполнять: SSH в корне сайта. Это не доказывает заражение, но помогает найти места для ручной проверки.

grep -R "base64_decode|eval(|gzinflate|str_rot13|shell_exec|assert(" wp-content --include="*.php"

Проверить целостность ядра WordPress через WP-CLI

Куда выполнять: SSH в корне сайта.

wp core verify-checksums

Показать администраторов WordPress

Куда выполнять: SSH в корне сайта.

wp user list --role=administrator

Сменить пароль администратора через WP-CLI

Куда выполнять: SSH в корне сайта. Замените admin_login на реальный логин.

wp user update admin_login --user_pass="NovyySlozhnyyParol"

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

Проверить активные плагины

Куда выполнять: SSH в корне сайта.

wp plugin list --status=active

Временно отключить все плагины

Куда выполнять: SSH в корне сайта. Используйте, если нужно быстро понять, связан ли взлом/ошибка с плагинами.

wp plugin deactivate --all

Закрыть выполнение PHP в uploads

Куда вставлять: создайте файл .htaccess внутри /wp-content/uploads/. Для Apache/LiteSpeed.

<FilesMatch ".php$">
    Require all denied
</FilesMatch>

Закрыть доступ к wp-config.php

Куда вставлять: .htaccess в корне сайта. Для Apache/LiteSpeed.

<Files "wp-config.php">
    Require all denied
</Files>

SQL-поиск подозрительных вставок в базе

Куда выполнять: phpMyAdmin, Adminer или MySQL-консоль. Перед SQL-запросами сделайте backup базы. Замените wp_ на свой префикс таблиц, если он другой.

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%base64_decode%'
   OR post_content LIKE '%iframe%'
   OR post_content LIKE '%display:none%';

Результат

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

Проверьте после восстановления:

• нет ли неизвестных администраторов;
• все пароли сменены;
• ядро WordPress чистое;
• плагины и темы переустановлены из чистых источников;
• uploads не содержит PHP-файлов;
• .htaccess не содержит чужих редиректов;
• wp-config.php чистый;
• в базе нет спам-ссылок и вредоносных scripts;
• Search Console не показывает новые проблемы;
• хостинг снял блокировку;
• бэкапы создаются и хранятся вне сайта;
• настроены 2FA, WAF и ограничение входа.

Если после очистки сайт стал показывать ошибку 500, проверьте .htaccess, права файлов, PHP-ошибки и error_log. Для отдельной диагностики подойдёт инструкция ошибка 500 WordPress.

Дополнительные способы

Восстановить сайт из чистого backup

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

После восстановления из backup всё равно нужно:

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

Проверить соседние сайты на том же хостинге

Если на одном хостинг-аккаунте лежит несколько сайтов, заражение может переходить между ними. Sucuri предупреждает, что при нескольких сайтах в одном hosting environment нужно сканировать все сайты, потому что cross-site contamination является одной из причин повторных заражений. :contentReference[oaicite:12]{index=12}

Проверить Google Search Console

Если Google показал предупреждение, после очистки нужно запросить пересмотр. Но делать это нужно только после полной очистки и закрытия точки входа.

Проверьте:

• Security Issues;
• Manual Actions;
• Coverage/Indexing;
• Sitemaps;
• URL Inspection;
• неизвестные страницы в индексе;
• подозрительные запросы и страницы входа.

Проверить WooCommerce отдельно

Если взломали интернет-магазин, нужно проверить не только файлы сайта, но и заказы, пользователей, платёжные интеграции, webhooks, email-шаблоны, checkout, SMTP и личные данные клиентов.

Если магазин после очистки начал работать медленно, используйте отдельный материал как ускорить WooCommerce, потому что malware, лишние cron-задачи и заражённые плагины могут сильно нагружать сайт.

Проверить cron-задачи

Вредоносный код может закрепляться через cron. Проверьте WordPress cron, серверный cron и задачи в панели хостинга.

wp cron event list

Проверить скорость после очистки

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

Частые ошибки

Ошибка 1. Просто удалить подозрительный файл

Один файл может быть только видимой частью заражения. Часто на сайте есть несколько backdoor, заражение в базе и изменённый .htaccess.

Ошибка 2. Восстановить backup и ничего не обновить

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

Ошибка 3. Не менять пароли

Если доступы уже украдены, очистка файлов не поможет. Злоумышленник сможет войти снова.

Ошибка 4. Удалять wp-content полностью

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

Ошибка 5. Чистить базу без копии

Неправильный SQL-запрос может удалить контент, настройки, заказы, пользователей или SEO-данные.

Ошибка 6. Считать сканер полной гарантией

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

Ошибка 7. Оставить старые backup-архивы в public_html

Архивы сайта и дампы базы могут содержать пароли, email, заказы и персональные данные. Их нельзя хранить в публичной папке сайта.

Ошибка 8. Не проверять поисковую выдачу

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

Диагностика проблем

Проблема: сайт редиректит на чужой домен

Возможная причина: заражённый .htaccess, JavaScript в теме, вредоносная опция в базе, injected script.

Что делать: проверить .htaccess, wp_options, header.php, footer.php, functions.php, плагины и исходный код страницы.

Проблема: в Google появились спам-страницы

Возможная причина: SEO spam injection, скрытые записи, подмена sitemap, вредоносный код в базе.

Что делать: проверить Search Console, sitemap.xml, wp_posts, wp_options, SEO-плагин, правила редиректов и скрытые страницы.

Проблема: хостинг заблокировал сайт

Возможная причина: malware, phishing, рассылка спама, нагрузка, вредоносные файлы.

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

Проблема: после очистки сайт снова заражается

Возможная причина: остался backdoor, не закрыта уязвимость, заражён соседний сайт, украдены доступы, есть вредоносный cron.

Что делать: проверить все сайты на хостинге, uploads, cron, администраторов, wp-config.php, .htaccess, плагины, темы и логи входа.

Проблема: неизвестный администратор появляется снова

Возможная причина: backdoor создаёт пользователя повторно или украден доступ к базе/хостингу.

Что делать: сменить доступы, проверить cron, wp-content, functions.php, mu-plugins, базу, логи и хостинг.

Проблема: сайт показывает белый экран после удаления malware

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

Что делать: включить debug.log, проверить error_log, восстановить чистые файлы и использовать инструкцию белый экран WordPress.

Проблема: после чистки пропали стили или функции

Возможная причина: удалили изменённый файл темы/плагина без восстановления чистой версии, сломан кеш, удалён кастомный код.

Что делать: восстановить чистую версию темы/плагина, проверить дочернюю тему, очистить кеш и сверить изменения с backup.

FAQ

Что делать сразу, если сайт WordPress взломали?

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

Нужно ли отключать сайт?

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

Можно ли просто удалить вирусный код?

Можно удалить найденный код, но этого часто недостаточно. Нужно найти backdoor и точку входа, иначе заражение может вернуться.

Что лучше: чистить сайт или восстановить backup?

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

Как понять, что backup чистый?

Сравните дату backup с датой первых признаков взлома, проверьте файлы, базу, пользователей, .htaccess, uploads и Search Console. Если спам уже был в индексе до даты backup, копия может быть заражена.

Почему сайт снова взломали после очистки?

Обычно причина в оставленном backdoor, старом уязвимом плагине, заражённом соседнем сайте, украденных паролях или неочищенной базе данных.

Нужно ли менять пароль базы данных?

Да, если есть подозрение на утечку wp-config.php, доступов хостинга или файлов сайта. После смены пароля базы нужно обновить DB_PASSWORD в wp-config.php.

Нужно ли уведомлять клиентов?

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

Как убрать предупреждение Google о вредоносном сайте?

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

Как защититься после взлома?

Настройте 2FA, WAF, ограничение входа, правильные роли пользователей, регулярные backup вне сервера, обновления, запрет PHP в uploads, контроль изменений файлов и проверку логов.

Вывод

Если сайт WordPress взломали, нельзя ограничиваться удалением одного подозрительного файла. Нужно действовать системно: закрыть доступ, сделать копию, сменить пароли, проверить пользователей, очистить файлы, базу, .htaccess, wp-config.php, uploads, плагины и темы.

После очистки обязательно нужно закрыть точку входа: обновить WordPress, удалить старые расширения, включить 2FA, настроить WAF, правильные права файлов, запрет PHP в uploads, регулярные backup и мониторинг логов.

Главная цель — не просто вернуть сайт в работу, а не дать злоумышленнику вернуться тем же путём.