Взломали WordPress? Первые 24 часа: Пошаговая инструкция по спасению (2026)

Знаете это чувство? Утро. Кофе. Открываете сайт — а там вместо главной страницы китайские иероглифы, или редирект на казино, или вообще белый экран с надписью «Hacked by …». Сердце в пятки. Руки холодеют. Мысли скачут: «Клиенты увидят! Начальник убьёт! Что я наделал?!»

Знакомо? Мне — тоже. И вам, думаю, тоже. Честно говоря, за 15 лет работы с WordPress я пережил штук семь таких историй. У клиентов, у себя, у друзей. И каждый раз первая реакция одинаковая — паника. А потом уже всё остальное.

Давайте сразу договоримся: паника — ваш главный враг сейчас. Не хакер. Не вирус. Именно паника. Потому что в панике люди удаляют логи, перезаливают бэкапы поверх заражённых файлов (и получают двойную заразу), пишут хостеру «срочно почините» вместо того, чтобы самим разобраться. А потом тратят недели на то, что спокойно решается за день.

Так что выдыхаем. Наливаем ещё кофе. И читаем дальше. Я расскажу, что делать в первые 24 часа после взлома — по шагам, без воды и без «лучших практик» из учебников. Только то, что реально работает.

А вы точно взломаны? Или просто что-то сломалось

Прежде чем поднимать тревогу, давайте убедимся, что это именно взлом. Потому что белый экран смерти, 500-я ошибка или кривая вёрстка после обновления плагина — это не взлом. Это, как говорится, совсем другая история (и про неё у нас тоже есть отдельная статья).

Вот признаки, которые кричат «взлом» во всё горло:

На главной появились посторонние тексты, ссылки, иероглифы
Сайт редиректит на другие ресурсы (особенно казино, порно, «чудо-таблетки»)
В админке появились новые пользователи, которых вы не создавали
Антивирус в браузере ругается на ваш сайт
Из functions.php или header.php исчез код, или появился непонятный
Google Search Console показывает предупреждение «Этот сайт может быть взломан»
Рассылается спам от имени вашего сайта

Нашли хотя бы один пункт? Поздравляю (хотя какие тут поздравления) — у вас взлом. Но это не конец света. Серьёзно. В 90% случаев сайт можно откатить за пару часов. В оставшихся 10% — тоже можно, просто придётся попотеть.

Правило №1: Ничего не трогайте. Серьёзно

Звучит странно, да? «Меня взломали, а мне говорят — сиди тихо». Но вот в чём дело: каждый ваш необдуманный шаг сейчас — это уничтожение улик. Хакер оставил следы. В логах. В файлах. В базе данных. И эти следы — ваш единственный шанс понять, как именно вас сломали, и не допустить повторения.

Что НЕ надо делать в первые минуты:

Не удаляйте подозрительные файлы «на всякий случай»
Не перезаливайте бэкап поверх текущего состояния (сначала сделайте снимок текущего!)
Не меняйте пароли от FTP/админки — хакер может это увидеть и затереть следы
Не пишите в поддержку хостинга «у меня взлом, почините» — они не чинят, они только отключают сайт
Не паникуйте вслух при клиентах (да, знаю, сложно)

А что надо? Сейчас расскажу.

Первые 30 минут: Режим «Стоп»

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

Шаг 1. Сделайте снимок текущего состояния

Звучит парадоксально — «сохрани то, что сломано». Но вот зачем: если вы начнёте чистку и что-то пойдёт не так (а оно пойдёт, поверьте), у вас будет точка отката. Хуже текущего состояния уже не будет.

На Бегете это делается через панель управления → «Резервные копии» → «Создать вручную». На VPS — через tar и mysqldump:

# На VPS, в корне сайта
tar -czf /backup/infected-$(date +%Y%m%d-%H%M).tar.gz /var/www/wordpress
mysqldump -u user -p database_name > /backup/infected-$(date +%Y%m%d-%H%M).sql

Сделали? Отлично. Теперь можно дышать.

Шаг 2. Включите режим обслуживания

Пока вы разбираетесь, посетители не должны видеть этот кошмар. Самый простой способ — через .htaccess (да-да, тот самый, который все ругают, но в критической ситуации он спасает):

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.45\.67\.89$  # Ваш IP
RewriteCond %{REQUEST_URI} !/maintenance\.html$
RewriteRule ^(.*)$ /maintenance.html [R=503,L]

# Заголовок для поисковиков — "вернитесь позже"
Header set Retry-After "3600"

Создайте файл maintenance.html с простым текстом «Технические работы, вернёмся через час». Всё. Посетители видят заглушку, поисковики понимают, что сайт временно недоступен (и не снимают его с выдачи), а вы спокойно работаете.

Кстати, не забудьте вписать свой IP — иначе сами себя заблокируете. Проверено на себе. Один раз.

Шаг 3. Смените пароли. Но осторожно

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

Сначала закройте доступ к админке через .htaccess — разрешите только со своего IP
Потом меняйте пароли: FTP, админка WordPress, база данных, хостинг-панель
Пароли — длинные, случайные, разные для каждого сервиса. Никаких «123456» и дней рождения

# Только ваш IP может зайти в админку
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 123.45.67.89
</Files>

Час 1-2: Диагностика. Кто, как, зачем

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

Где искать следы

Логи хостинга. На Бегете это раздел «Логи» в панели. На VPS — /var/log/nginx/access.log и error.log. Ищите:

Постранные POST-запросы на wp-login.php или xmlrpc.php (брутфорс)
Запросы к файлам вроде wp-content/uploads/2026/06/weird-file.php (бэкдоры часто маскируются под картинки)
Много запросов с одного IP за короткое время

Изменённые файлы. Если у вас есть доступ к терминалу, команда find — ваш лучший друг:

# Найти все PHP-файлы, изменённые за последние 7 дней
find /var/www/wordpress -name "*.php" -mtime -7 -ls

# Найти файлы с подозрительными именами (двойные расширения, странные символы)
find /var/www/wordpress/wp-content/uploads -name "*.php"
find /var/www/wordpress -name "*.php.*"
find /var/www/wordpress -name "*.*.php"

Кстати, знаете что? PHP-файлы в папке uploads — это почти всегда бэкдор. Запомните: в загрузках должны быть только картинки, документы, видео. Никаких .php. Если видите — 99% взлом.

Пользователи в WordPress. Зайдите в базу данных напрямую (через phpMyAdmin или консоль) и посмотрите таблицу wp_users:

SELECT ID, user_login, user_email, user_registered 
FROM wp_users 
ORDER BY user_registered DESC;

Видите пользователя wp_admin_support с email hacker@tempmail.com, зарегистрированного вчера в 3 часа ночи? Вот он, ваш «гость».

Сравнение с эталон… ой, то есть с оригиналом

Честно говоря, самый надёжный способ найти заражённые файлы — сравнить их с чистым WordPress. Скачайте свежий дистрибутив с wordpress.org той же версии, что у вас, и сравните:

# Скачать чистый WordPress той же версии
wget https://wordpress.org/wordpress-6.5.zip
unzip wordpress-6.5.zip

# Сравнить ядро (без ваших тем и плагинов)
diff -r wordpress/wp-includes/ /var/www/wordpress/wp-includes/ | grep "^Only"

Всё, что отличается от оригинала в папках wp-includes и wp-admin — подозрительно. В 99% случаев там будет либо дописанный код, либо новый файл, которого быть не должно.

Час 2-6: Два пути — бэкап или ручная чистка

Вот тут пути расходятся. И выбор (ой, простите — «вариант», слово-то запретное) зависит от одного вопроса: есть ли у вас чистый бэкап?

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

Путь А: Откат из бэкапа (быстро и надёжно)

Если бэкап есть — вам повезло. Восстановление занимает 20-40 минут. Но есть нюанс: перед откатом нужно закрыть дыру, через которую хакер попал. Иначе он вернётся. Как в фильме «День сурка», только без Билла Мюррея.

Порядок действий:

Найдите точку входа (мы это делали на этапе диагностики)
Закройте её: удалите уязвимый плагин, обновите ядро, смените пароль
Только теперь откатывайте бэкап
Сразу после отката — обновите всё, что можно (WordPress, темы, плагины)
Смените все пароли ещё раз

Про сам процесс отката мы подробно писали в статье про бэкапы. Тут повторяться не буду.

Путь Б: Ручная чистка (долго, но иногда единственный выход)

Бэкапа нет, или он тоже заражён, или вы потеряли неделю контента и не хотите её откатывать? Что ж, добро пожаловать в ад ручного труда. Но знаете что? Это реально работает. Я так делал раз пять — и всегда спасал сайт.

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

Удалить всех подозрительных пользователей через базу данных. Не через админку — хакер мог оставить себе админские права и восстановить себя.
Проверить все PHP-файлы на подозрительный код. Ищите: eval(, base64_decode, gzinflate, str_rot13, shell_exec, assert(. Это классические маркеры вредоносного кода.
Перезалить ядро WordPress целиком из чистого дистрибутива. Темы и плагины — тоже, если есть сомнения.
Проверить .htaccess — хакеры часто прописывают там редиректы.
Почистить базу данных от подозрительных записей в wp_options (ищите странные URL в siteurl, home, rewrite_rules).

# Поиск подозрительного кода в файлах
grep -rn "eval(" /var/www/wordpress/wp-content/
grep -rn "base64_decode" /var/www/wordpress/wp-content/
grep -rn "shell_exec" /var/www/wordpress/wp-content/

Знаете, что меня всегда удивляет? Хакеры ленивы. Они не шифруют свой код каким-то хитрым способом. Они вставляют eval(base64_decode('...')) и думают, что это круто. А мы берём grep — и всё видим. Как на ладони.

Час 6-12: Проверка и усиление защиты

Сайт очищен (или откачен из бэкапа). Кажется, можно выдыхать? А вот и нет. Сейчас самое важное — закрыть все дыры, иначе через неделю вы снова будете читать эту статью. Только уже с меньшим энтузиазмом.

Что обязательно нужно сделать

Обновить всё. WordPress, темы, плагины — всё до последней версии. 90% взломов происходит через уязвимости в устаревшем коде. Да, я знаю, что обновление может что-то сломать. Но знаете что ещё может что-то сломать? Взлом. И это ломает гораздо сильнее.

Удалить неиспользуемые плагины и темы. Серьёзно. Каждый плагин — это потенциальная дыра. Не пользуетесь — удаляйте. Не «деактивируйте», а именно удаляйте. Деактивированный плагин всё ещё лежит на сервере, и хакер может найти в нём уязвимость.

Поставить двухфакторную аутентификацию. Это занимает 5 минут, но отрезает 99% атак на админку. Плагинов масса — Two Factor, WP 2FA, даже в Jetpack есть. Нет оправданий.

Ограничить попытки входа. Через Fail2ban или плагин типа Limit Login Attempts. Хакеры обожают брутфорсить wp-login.php — дайте им по рукам после 5 неудачных попыток.

Скрыть версию WordPress. Мелочь, но усложняет жизнь хакеру. В functions.php:

remove_action( 'wp_head', 'wp_generator' );

Запретить выполнение PHP в uploads. Помните, я говорил, что в загрузках не должно быть PHP? Вот как это закрепить через .htaccess:

# В /wp-content/uploads/.htaccess
<Files *.php>
    Order Deny,Allow
    Deny from all
</Files>

Даже если хакер загрузит бэкдор в загрузки, он не выполнится. Красота.

Час 12-24: Сообщить поисковикам и мониторинг

Сайт чист, защита усилена. Но Google (и другие поисковики) уже могли пометить ваш сайт как «взломанный». Эта пометка висит в выдаче пугающим предупреждением и отпугивает посетителей. Надо это исправить.

Google Search Console

Если ещё не добавили сайт в GSC — самое время. Перейдите в раздел «Безопасность и ручные санкции» → «Проблемы безопасности». Там будет список того, что Google нашёл. После очистки нажмите «Запросить проверку».

Обычно Google проверяет сайт в течение 24-72 часов и снимает пометку. Иногда быстрее, иногда дольше. Нервыберегающий совет: не дёргайте эту кнопку каждые 10 минут. Один раз нажали — ждите.

Яндекс.Вебмастер

Аналогично, если сайт в выдаче Яндекса — зайдите в Вебмастер → «Безопасность и нарушения» → запросите проверку.

Мониторинг на повторные взломы

Знаете, что самое обидное? Когда вы всё почистили, а через неделю вас взломали снова. Потому что не нашли второй бэкдор. Или хакер вернулся через ту же дыру.

Чтобы такого не случилось, настройте мониторинг. Вариантов масса:

Uptime Kuma — следит за доступностью, сразу пришлёт уведомление, если сайт упадёт или начнёт редиректить
Плагин Wordfence (бесплатной версии хватит) — сканирует файлы на изменения и шлёт алерты
Скрипт на сервере, который раз в час сравнивает контрольные суммы критичных файлов

Я, честно говоря, предпочитаю комбинацию: Wordfence для файлов + Uptime Kuma для доступности. Покрывает 99% случаев.

А что, если меня взломали через хостинг?

Такие истории тоже бывают. Редко, но метко. Если у вас shared-хостинг и на соседнем сайте был взлом, а хакер перекинулся на ваш — это не ваша вина. Но и тут есть нюансы.

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

Во-вторых, если хостинг упорно молчит или отмахивается — меняйте хостинг. Да, это неудобно. Да, это расходы. Но знаете, что ещё неудобно? Восстанавливать сайт после повторного взлома. Про переезд у нас тоже написано, не переживайте.

Мифы о взломах WordPress

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

«WordPress взламывают чаще, чем другие CMS». Ага, потому что он самый популярный. Это как говорить «Жигули угоняют чаще, чем Ferrari — значит, они менее безопасные». Нет, просто Жигулей больше на дорогах. WordPress powering 43% интернета — естественно, хакеры атакой именно его. Но это не значит, что WordPress плохо защищён из коробки. Это значит, что вы должны следить за обновлениями.

«Мой сайт никому не нужен, его не взломают». Ох. Знаете, как хакеры выбирают цели? Они не выбирают. Они сканят весь интернет ботами и ломают всё, что плохо защищено. Ваш сайт с 10 посетителями в день может быть взломан просто потому, что у вас устаревший плагин Contact Form 7. Хакеру не важно, кто вы. Ему важно, что вы уязвимы.

«У меня стоит плагин безопасности, я в безопасности». Плагин безопасности — это как сигнализация в машине. Она орёт, когда кто-то лезет, но не останавливает взломщика с ломом. Плагин — это один из слоёв защиты, но не единственный. Обновления + сильные пароли + 2FA + бэкапы — вот настоящая защита.

Чек-лист: что делать в первые 24 часа

Чтобы не запутаться, вот короткая шпаргалка. Распечатайте, повесьте над монитором (ладно, это уже перебор, но вы поняли идею):

✅ Не паниковать. Серьёзно, это реально помогает
✅ Сделать снимок заражённого состояния (бэкап «как есть»)
✅ Включить режим обслуживания через .htaccess
✅ Сменить все пароли (FTP, админка, БД, хостинг)
✅ Найти точку входа через логи и сравнение файлов
✅ Откатить бэкап (если есть) или почистить вручную
✅ Обновить всё — ядро, темы, плагины
✅ Удалить неиспользуемые плагины и темы
✅ Поставить 2FA для всех админов
✅ Запретить PHP в uploads
✅ Запросить проверку в GSC и Яндекс.Вебмастере
✅ Настроить мониторинг на повторные атаки

Вместо заключения

Знаете, что я понял за эти годы? Взлом WordPress — это не катастрофа. Это неприятность. Да, стресс. Да, бессонная ночь. Да, возможно, разговор с недовольным клиентом. Но это не конец света. Сайт восстанавливается. Защита усиливается. Уроки усваиваются.

И вот что ещё. Если вас взломали — не вините себя. Серьёзно. Даже опытные разработчики попадают под раздачу. Я вот в 2018-м умудрился пропустить обновление плагина, и клиент получил редирект на казино. До сих пор стыдно вспоминать. Но сайт восстановили, выводы сделали, и с тех пор — тьфу-тьфу — всё чисто.

Главное — действовать быстро, действовать спокойно и действовать по плану. А план у вас теперь есть. Держите эту статью в закладках. Надеюсь, она вам никогда не понадобится. Но если что — вы знаете, что делать.

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

Сделали? Отлично. Теперь можно выдохнуть.