Если вы читаете это, потому что уже нашли у себя что-то странное – незнакомого администратора в списке пользователей, письмо о смене пароля, которое вы не запрашивали, левые записи в блоге или откровенный дефейс, – начну не с теории, а с короткого ответа. В подавляющем большинстве недавно зафиксированных случаев причина чаще всего одна: сайт вовремя не обновился, и через дыру в самом WordPress кто-то получил доступ к серверу (выполнять код на сервере).
Порядок действий при этом почти всегда один и тот же, и он важнее, чем кажется: сначала закрыть саму дыру (обновить ядро до исправленной версии), только потом менять пароли и чистить следы. Если сделать наоборот – вычистить сайт, оставив дверь открытой, – вас взломают заново в тот же день, буквально за минуты.
Ниже разберу, почему так происходит и что делать по шагам.А вот тем, кто пришёл заранее, до всякого взлома, скажу главное сразу: обновляйте WordPress без задержек и проверяйте, что обновление реально встало. Этого одного достаточно, чтобы не попасть в большинство подобных историй, которые я разбираю дальше. Остальное – детали и подстраховка. И да, к сожалению, мне тоже на днях пришлось столкнуться с этой проблемой.
Что на самом деле происходит при таком взломе
Схема почти всегда одинаковая и состоит из двух этапов, которые люди путают между собой. Сначала – вход: в коде WordPress находят уязвимость, которая позволяет выполнить произвольную команду на сервере вообще без пароля, просто отправив специально сформированный запрос. Это называется RCE (удалённое выполнение кода), и это самый тяжёлый класс проблем, какой бывает. Потом – закрепление: получив разовую возможность что-то выполнить, атакующий оставляет себе постоянную дверь, чтобы возвращаться, когда захочет, даже после того как исходную дыру закроют.
Свежий и очень наглядный пример – история, которую назвали wp2shell. Технически это связка двух ошибок в ядре WordPress: путаница с маршрутами в REST API (через служебный адрес /wp-json/batch/v1) и SQL-инъекция. По отдельности каждая ограничена, но вместе они дают взломщику возможность выполнения кода на стоковой установке – без единого плагина, без входа, без каких-либо особых настроек. Разработчики выпустили заплатки 17 июля 2026 года и включили принудительное автообновление, а через несколько дней обе уязвимости попали в правительственный каталог активно эксплуатируемых – то есть их массово использовали в реальных атаках. Публичные эксплойты к тому моменту уже лежали на GitHub, так что порог входа для злоумышленника был не «команда хакеров», а «скрипт и список сайтов».
Вот как выглядит матрица версий – по ней проще всего понять, касается ли это лично вас:
| Версия WordPress | Уязвима | Исправлено в |
|---|---|---|
| до 6.8 | не затронут данной уязвимостью | – |
| 6.8.0 – 6.8.5 | частично (только SQL-инъекция) | 6.8.6 |
| 6.9.0 – 6.9.4 | да, полностью | 6.9.5 |
| 7.0.0 – 7.0.1 | да, полностью | 7.0.2 |
С той стороны, где стоит хостинг, момент выхода такой дыры выглядит очень характерно. По логам видно, как в течение считанных часов после публикации начинается перебор: один и тот же запрос к /wp-json/batch/v1 прилетает на сотни сайтов подряд, без разбора, что там за проект. Атака не целится в вас лично – она просто прочёсывает всё, что отвечает, и оставляет закладку там, где сработало. Поэтому «да кому мой маленький сайт нужен» здесь не работает совсем: никто и не выбирал ваш сайт, его нашёл автомат.
«У меня же включены автообновления!!»
Это самое частое возражение, и в нём кроется самая неприятная деталь всей истории. Да, при таких критичных дырах WordPress включает принудительное обновление и старается дотянуться до всех. Но «старается» – не то же самое, что «дотянулся». Принудительный апдейт тихо не срабатывает в нескольких вполне обычных ситуациях: если обновления отключены прямо в wp-config.php (а это часто делают разработчики «чтобы ничего не сломалось»), если сайт развёрнут из системы контроля версий, если на файлы стоят слишком строгие права и WordPress физически не может себя перезаписать, и, на удивление, если у сайта совсем маленький трафик, потому что механизм обновления привязан к посещениям.
Здесь путаются чаще всего. Человек видит в настройках галочку «автообновления включены» и считает вопрос закрытым. А сайт тем временем неделями сидит на уязвимой версии, потому что апдейт по одной из причин выше не прошёл, и никто об этом не узнал – ошибка-то молчаливая. Проверка занимает тридцать секунд: откройте консоль, раздел «Обновления», и посмотрите номер версии своими глазами. Если у вас доступен терминал на хостинге, ещё точнее – команда, которая показывает установленную версию напрямую (про работу через SSH у нас есть отдельный разбор). Не «должно было обновиться», а «вижу нужный номер».
Отдельно про облачные фаерволы вроде Cloudflare. Они в таких случаях действительно выкатывают правила, которые режут вредоносные запросы на подлёте, иногда в то же мгновение. Это полезно, но это не заплатка. Правило фаервола можно обойти, оно может не покрывать все векторы, и оно ничего не говорит о том, что случилось с сайтом до того, как правило появилось. Полагаться на WAF вместо обновления – примерно как не чинить замок, а поставить у двери охранника, который узнаёт грабителей в лицо по старым фотографиям.
Статья длинная. Предлагаем сделать паузу и ознакомиться с лучшими украинскими хостинг-провайдерами из нашего рейтинга. По каждому есть подробный разбор: как тестировали, что с аптаймом, скоростью и поддержкой, где сильные и слабые стороны. Загляните в обзоры тех, кто вам интересен, почитайте отзывы клиентов.
Как выглядит сама закладка
Дальше начинается вторая часть – то, ради чего всё и затевалось. Разовое выполнение кода мало что даёт: перезагрузили сайт – и доступ пропал. Поэтому атакующий первым делом ставит бэкдор — файл, который будет жить на сайте постоянно и пускать хозяина обратно.
Любимое место для такого файла – папка mu-plugins (must-use plugins). Это плагины, которые WordPress подгружает автоматически на каждом запросе, их не видно в обычном списке плагинов в админке и нельзя отключить кнопкой. Для закладки место идеальное: работает всегда, глаза не мозолит. Сам файл обычно маскируется под что-то системное – какой-нибудь «auto-updates» или «cache-loader», чтобы при беглом взгляде не вызывать вопросов.
Внутри такие бэкдоры чаще всего устроены хитрее, чем просто «кусок вредоносного кода». Настоящих команд в файле нет – нередко подобные бэкдоры вообще не содержат основного вредоносного кода, а подгружают его. Смысл в том, что содержимое можно менять на стороне атакующего, не трогая ваш сайт: сегодня файл рассылает спам, завтра ворует данные из формы, послезавтра пытается дотянуться до соседних сайтов – а на диске у вас всё это время лежит один и тот же безобидный на вид файлик. Часто такой шелл ещё и закрыт паролем и добавляет заголовок, чтобы страница не попала в поисковую выдачу. Аккуратная работа, ничего не скажешь.
Что из этого следует практически: искать взлом по «странному коду в теме» – занятие почти бесполезное. Кода команд там может не быть вовсе.
Как не попасть: профилактика без иллюзий
Про обновления я уже сказал, повторяться не буду – это фундамент, и без него остальное не имеет смысла. Поговорим лучше о том, что обычно остаётся за кадром.
Первое – резервные копии, и здесь есть ловушка, в которую попадают постоянно. Бэкап спасает от потери данных, но сам по себе не защищает от взлома, а иногда и вредит. Если копия снята уже после того, как поставили закладку, в ней лежит и сайт, и бэкдор, и левый администратор. Восстановились из такой копии – и переинфицировали себя в одно нажатие. Звучит нелепо, но именно так люди по второму кругу возвращают на сайт то, что только что вычистили. Поэтому копий должно быть несколько, за разные даты, и надо понимать, какая из них заведомо чистая. Тему резервного копирования мы разбирали подробно – что бэкап на самом деле умеет и чего не умеет.
Второе – про соседей по аккаунту. На виртуальном хостинге в одном аккаунте нередко живёт несколько сайтов, и если пробили один, добраться до остальных обычно тривиально – они лежат рядом в файловой системе, под тем же пользователем. Провайдеры для того и городят изоляцию аккаунтов друг от друга (тот же CloudLinux), но внутри одного аккаунта эта изоляция не работает – она про соседей по серверу, а не про ваши собственные сайты между собой. Так что если у вас в аккаунте пять сайтов, а обновлён один, – уязвимы, считайте, все пять.
Третье, и об этом говорят реже всего, – выбор самого хостинга. Нормальный провайдер не сидит сложа руки, когда выходит дыра такого калибра: он выкатывает правила на своём фаерволе, а иногда и сам инициирует обновления по всем клиентам, чтобы прикрыть тех, до кого автоапдейт не дошёл. Это не то, что видно в тарифе, но именно это отличает хостинг, с которым вы переживёте плохой день, от хостинга, где вы узнаете о взломе от Google. Как мы вообще оцениваем провайдеров и почему нельзя верить витринным цифрам – расписано в нашей методологии рейтинга.
Если уже взломали: лечение по порядку
Теперь самое важное: что делать, если беда уже случилась. Здесь критичен именно порядок, потому что большинство людей всё делают правильно, но не в той последовательности, и потому проигрывают гонку.
Обновление WP
Начните с двери, а не с уборки. Первым делом убедитесь, что WordPress обновлён до исправленной версии из таблицы выше. Пока дыра открыта, любая чистка бессмысленна: вы удаляете левого админа, а через пять минут скрипт заходит снова и создаёт нового. Я много раз видел, как человек по кругу сносит одних и тех же пользователей и не понимает, почему они возвращаются, – а они возвращаются потому, что вход всё ещё открыт. Сначала патч.
Смена паролей
Дальше – смените все секреты (ВСЕ!!!), а не только свой пароль. Раз у атакующего было выполнение кода, он мог прочитать wp-config.php целиком, а там открытым текстом лежат доступы к базе данных и секретные ключи-«соли». Поэтому меняем: пароли всех пользователей сайта (не только администраторов), соли в конфиге через официальный генератор – это заодно разлогинит все активные сессии, включая сессию взломщика, если она где-то висит, – пароль базы данных, пароль от панели хостинга, все FTP-доступы и любые API-ключи, которые хранились в этом WordPress.
Анализ логов
Пока меняете доступы, загляните в журналы – это тот шаг, который чаще всего пропускают, а зря. Логи веб-сервера access.log и error.log, плюс журналы панели хостинга, показывают то, чего не видно в самом WordPress: когда именно случилось заражение, какой URL для этого дёргали, с каких IP шли обращения и – самое важное на будущее – не продолжаются ли попытки эксплуатации прямо сейчас. Оговорюсь честно: решающие запросы таких атак часто уходят в тело POST и в логах видны скупо, так что журнал не всегда даёт полную картину. Но даже частичная картина помогает: если после патча вы видите, что перебор к уязвимому адресу продолжается, – значит дыру закрыли вовремя и вас теперь просто безуспешно прощупывают, а не ломают снова.
Проверка файлов
Только теперь ищем и убираем сам бэкдор. Первым делом – папка mu-plugins: там не должно быть ничего, кроме ваших собственных must-use плагинов, всё незнакомое – под подозрение. Загляните в wp-config.php и в файл .htaccess: там иногда прописывают строку, которая подключает вредоносный файл к каждому запросу (директива с именем вроде auto_prepend_file); если встретите её – проверьте, на какой файл она ведёт. Про то, как .htaccess вообще управляет обработкой запросов, у нас есть отдельная статья. Заодно проверьте папку загрузок: PHP-файлов в wp-content/uploads быть не должно в принципе, любой такой файл – почти наверняка шелл. Кстати, многие хостинги по умолчанию вообще запрещают исполнение PHP в папке загрузок – знают, чем это заканчивается.
Отдельно стоит заглянуть в базу данных: не появилось ли администраторов, которых вы не создавали, странных записей в блоге, задач в планировщике WordPress, которые могли бы пересоздавать удалённый бэкдор. Чистая база – хороший признак, но не гарантия: закладку могли спрятать и в файлах.
Проверка ядра системы
Когда бэкдор убран, стоит проверить целостность самого ядра. У WordPress есть механизм сверки: он сравнивает все файлы ядра и плагинов из официального каталога с эталоном и показывает любой изменённый или лишний файл. Если у вас есть доступ к терминалу – это команды wp core verify-checksums и wp plugin verify-checksums. Если терминала нет, есть способ грубее, но рабочий: скачать с wordpress.org чистый архив ровно вашей версии и залить поверх сайта только папки ядра (wp-admin и wp-includes), не трогая wp-content и wp-config.php. Это перезапишет любой подменённый файл ядра оригиналом.
И последнее решение, которое честнее принять сразу. Если вы нашли бэкдор, вычистили его и проверка целостности молчит – в большинстве случаев этого достаточно. Но если атака была плотной, если вы видели не одну закладку, а десяток левых админов и кучу мусорных записей, – гарантировать, что вы вычистили всё, на живом сайте нельзя. RCE даёт слишком много возможностей, чтобы быть уверенным на сто процентов. Самый надёжный путь в таком случае – пересборка: чистая установка ядра и плагинов из официальных источников, а из старого сайта переносится только выверенный контент базы и медиафайлы. Это дороже по времени, но это единственный вариант, после которого можно спать спокойно. Здесь всё зависит от того, насколько сайт для вас важен и насколько глубоко в него залезли.
Короткий вывод
Практически все взломы такого рода – не про гениальных хакеров и не про плохой хостинг. Это про пропущенное обновление и про молчаливо не сработавший автоапдейт, о котором владелец узнал слишком поздно. Дверь открывает вовремя не обновлённый WordPress, а шелл в mu-plugins – уже следствие. Хорошая новость в том, что и защита, и лечение упираются в одно и то же простое действие, которое почему-то делают в последнюю очередь: проверить своими глазами, какая версия стоит, и держать её свежей. Всё остальное – подстраховка вокруг этого.
Источники
- WordPress – обновление ядра (официальная документация)
- WP-CLI – команда core verify-checksums (проверка целостности файлов)
- NVD – CVE-2026-63030 (путаница маршрутов REST API batch)
- NVD – CVE-2026-60137 (SQL-инъекция в WP_Query)
- CISA – каталог активно эксплуатируемых уязвимостей (KEV)
- VulnCheck – технический разбор цепочки wp2shell
FAQ по уязвимостям
Как понять, что мой сайт на WordPress взломали?
Тревожные признаки: незнакомый администратор в списке пользователей, письмо о смене пароля, которое вы не запрашивали, чужие записи в блоге, дефейс или редиректы на посторонние сайты. Часто внешне всё выглядит нормально, а закладка тихо сидит в файлах. Самый надёжный способ убедиться – проверить версию WordPress и заглянуть в папку mu-plugins на предмет незнакомых файлов.
Что такое wp2shell простыми словами?
Это связка из двух ошибок в ядре WordPress, которая вместе даёт анонимному человеку из интернета возможность выполнить код на вашем сервере – без пароля, без входа, на стоковой установке даже без плагинов. Уязвимость закрыли 17 июля 2026 года. Если у вас стоит исправленная версия, через эту дыру к вам уже не зайдут.
Какие версии WordPress уязвимы и в каких исправлено?
Полностью уязвимы ветки 6.9.0–6.9.4 и 7.0.0–7.0.1; исправлено в 6.9.5 и 7.0.2 соответственно. Ветка 6.8.0–6.8.5 затронута частично (только SQL-инъекцией) и лечится версией 6.8.6. Всё, что старше 6.8, этой проблемой не затронуто.
У меня включены автообновления – я в безопасности?
Не обязательно. Принудительное обновление тихо не срабатывает, если апдейты отключены в wp-config.php, если сайт развёрнут из системы контроля версий, если на файлы стоят слишком строгие права или если у сайта совсем маленький трафик. Ошибка при этом молчаливая, поэтому проверять надо своими глазами: консоль, раздел «Обновления», номер версии.
Что такое веб-шелл и бэкдор?
Это файл, который атакующий оставляет на сайте после взлома, чтобы возвращаться в любой момент – даже после того как исходную дыру закроют. Часто он не содержит вредоносного кода напрямую, а подгружает его с чужого сервера и выполняет через eval. Из-за этого содержимое можно менять на стороне взломщика, не трогая ваш сайт.
Почему бэкдор прячут именно в mu-plugins?
Папка mu-plugins (must-use plugins) подгружается WordPress автоматически на каждом запросе. Такие плагины не видно в обычном списке в админке и нельзя отключить кнопкой. Для закладки это идеальное место: работает всегда и не бросается в глаза, часто маскируется под системный файл вроде auto-updates.
Что делать в первую очередь, если сайт уже взломали?
Сначала закрыть дыру – обновить WordPress до исправленной версии. Пока вход открыт, чистить бесполезно: удалённый администратор вернётся через минуты. Только после патча меняйте пароли и убирайте закладку. Порядок здесь важнее скорости.
Какие пароли и ключи менять после взлома?
Все, а не только свой. Раз у атакующего было выполнение кода, он мог прочитать wp-config.php с доступами к базе и солями. Меняйте пароли всех пользователей, соли в конфиге, пароль базы данных, пароль панели хостинга, все FTP-доступы и API-ключи. Смена солей заодно разлогинит все активные сессии.
Как найти и удалить закладку?
Начните с папки mu-plugins – там не должно быть ничего, кроме ваших файлов. Проверьте wp-config.php и .htaccess на строку auto_prepend_file, ведущую на посторонний файл, и папку wp-content/uploads – PHP-файлов там быть не должно. Загляните в базу: нет ли левых администраторов и задач в планировщике, которые могли бы пересоздавать бэкдор.
Достаточно ли просто удалить бэкдор, или нужно пересобирать сайт?
Если закладка найдена, удалена и проверка целостности ядра молчит, в большинстве случаев этого достаточно. Но при плотной атаке – с десятком левых админов и множеством мусорных записей – гарантировать полную чистоту на живом сайте нельзя. Тогда надёжнее пересборка: чистое ядро и плагины из официальных источников, а из старого сайта только выверенный контент.
Спасёт ли меня резервная копия?
Бэкап защищает от потери данных, но не от взлома, а иногда и вредит. Если копия снята уже после появления закладки, восстановление из неё вернёт и бэкдор, и левого администратора. Держите несколько копий за разные даты и понимайте, какая из них заведомо чистая – то есть снята до момента взлома.