Взлом WordPress из-за устаревших компонентов: разбор двух реальных случаев
В начале августа 2026 года мы расследовали взлом двух сайтов на WordPress. В статье делимся результатами расследования, планом действий в случае взлома сайта и рекомендациями, которые помогут минимизировать риски успешных атак злоумышленников.
В обоих случаях злоумышленники внедрили вредоносный код, создали скрытые административные учетные записи и оставили механизмы для повторного доступа к сайтам.
Последствия были серьезными:
- появились неизвестные администраторы;
- были изменены системные файлы и файлы темы;
- нарушилась работа авторизации;
- создавались тысячи мусорных URL;
- сайты потеряли часть видимости в поисковых системах.
На первый взгляд эти случаи отличаются: на одном сайте первоначальной точкой входа стала уязвимость ядра WordPress, на другом — уязвимые плагины.
Но причина у них общая: на сайтах использовались компоненты с известными уязвимостями, которые не были своевременно обновлены.
Это важный момент для владельцев сайтов. Взлом происходит не только тогда, когда кто-то узнает пароль администратора. Иногда достаточно оставить на сервере старую версию WordPress, плагина или темы.
Что мы обнаружили при расследовании
Чтобы определить причину взлома, мы изучили:
- журналы веб-сервера;
- последовательность HTTP-запросов;
- время изменения файлов;
- записи базы данных;
- вредоносный код, появившийся на сайтах;
- изменения административных учетных записей.
Сопоставление этих данных позволило восстановить последовательность событий и определить вероятные точки входа.
На первом сайте первоначальное проникновение произошло через уязвимости WordPress 6.9.4.
На втором сайте использовались уязвимые версии All-in-One WP Migration и Cyr to Lat Enhanced.
Полные журналы мы не публикуем, поскольку они содержат IP-адреса, внутренние пути, параметры запросов и другие сведения, раскрытие которых может создать дополнительные риски для безопасности сайтов и их владельцев.
Два сайта — две точки входа
Уязвимость затрагивает следующие версии:
6.8.0–6.8.5
6.9.0–6.9.4
7.0.0–7.0.1
Эти версии содержат критическую уязвимость, которая позволяет неаутентифицированному злоумышленнику выполнять произвольный код на сервере даже без установленных плагинов.
Первый сайт: взлом через уязвимости WordPress 6.9.4
На момент заражения на сайте использовался WordPress 6.9.4.
Эта версия была затронута двумя уязвимостями — CVE-2026-60137 и CVE-2026-63030.
17 июля 2026 года WordPress выпустил версии 6.9.5 и 7.0.2 с исправлениями этих проблем. Официальная документация WordPress указывает, что обе уязвимости затрагивали ветку 6.9, а 6.9.5 содержала исправления для обеих.
После проникновения на исследуемом сайте злоумышленники:
- изменили файлы темы;
- создали скрытых администраторов;
- добавили механизмы повторного заражения.
Таким образом, первоначальный доступ был получен не за счет украденного пароля администратора, а через уязвимый компонент самого WordPress.
Это принципиально важное различие.
Если пароль администратора скомпрометирован, проблему можно решать через смену паролей, ключей и контроль доступа. Но если точкой входа становится уязвимость ядра CMS, наличие сложного пароля само по себе не защищает сайт от атаки.
Второй сайт: уязвимые плагины WordPress
На втором сайте были установлены:
- All-in-One WP Migration 7.84;
- уязвимая версия Cyr to Lat Enhanced.
По журналам мы восстановили последовательность обращений к этим компонентам. После неё в базе данных и файлах сайта произошли изменения, а затем появилась новая административная учетная запись.
До начала атаки входа под легитимным администратором в доступных нам журналах зафиксировано не было.
По имеющимся данным признаков входа под легитимной административной учетной записью до начала атаки не обнаружено. Это не указывает на компрометацию пользовательского пароля как на первоначальную точку входа.
All-in-One WP Migration 7.84
Версия 7.84 содержала несколько известных проблем безопасности, которые были исправлены в последующих версиях.
В частности:
- CVE-2024-8852 позволяла неавторизованному пользователю получить доступ к публично доступным логам, в которых могли содержаться чувствительные сведения, включая полные пути к файлам;
- CVE-2024-9162 позволяла пользователю с административными правами внедрить произвольный PHP-код;
- CVE-2024-10942 была связана с небезопасной десериализацией данных и могла приводить к PHP Object Injection.
CVE-2024-8852 и CVE-2024-9162 были исправлены в версии 7.87. CVE-2024-10942 затрагивала версии до 7.89 включительно и была исправлена в 7.90.
При этом важно не смешивать условия эксплуатации этих уязвимостей.
Например, CVE-2024-9162 сама по себе требует административных прав. Поэтому наличие этой уязвимости ещё не означает, что любой неавторизованный посетитель сайта мог напрямую выполнить PHP-код.
В нашем случае All-in-One WP Migration использовался как часть общей цепочки атаки.
Cyr to Lat Enhanced
В используемой версии Cyr to Lat Enhanced присутствовала известная SQL-инъекция CVE-2022-4290.
Уязвимость затрагивала версии до 3.5 включительно. Частичное исправление появилось в 3.6, а полностью проблема была исправлена в 3.7. Уязвимость требует авторизованного пользователя с определёнными возможностями работы с терминами или тегами.
Поэтому саму CVE-2022-4290 некорректно описывать как уязвимость, которая напрямую позволяет любому посетителю создать администратора.
В расследуемом инциденте плагин был частью многоэтапной цепочки вместе с другими уязвимыми компонентами.
Как развивалась атака
В обоих случаях схема в целом выглядела одинаково:
уязвимый компонент → первоначальное проникновение → изменение файлов или базы данных → создание административного доступа → закрепление → повторный доступ → последствия для сайта и SEO
После получения доступа злоумышленникам было важно не просто один раз выполнить вредоносный код.
Они оставили механизмы, которые позволяли сохранять доступ к сайту после первоначального заражения.
Именно поэтому при обнаружении взлома недостаточно найти один подозрительный PHP-файл и удалить его. Если первоначальная точка входа не установлена, а все механизмы закрепления не найдены, сайт может быть заражен повторно.
Как последствия взлома затрагивают SEO
Взлом WordPress — это не только проблема безопасности. Изменения на сайте напрямую влияют на его работу и поисковую видимость.
В нашем случае последствия включали:
- создание более 20 тысяч мусорных URL (14 тыс. непроиндексированных, 9.5 тыс. попали в индекс);
- резкое снижение кликов и показов в Google (более чем в 2 раза).
Мусорные страницы, вредоносные редиректы, измененный контент и проблемы с доступностью сайта могут создавать дополнительные проблемы для поисковой индексации.
Что делать при подозрении на взлом WordPress
Если сайт уже показывает признаки компрометации, действовать нужно не только быстро, но и последовательно.
1. Ограничить доступ и сохранить данные
Сначала нужно по возможности ограничить дальнейшие изменения на сайте и сохранить резервную копию вместе с журналами.
Не стоит удалять логи или подозрительные файлы до завершения расследования: они могут содержать информацию о первоначальной точке входа.
2. Проверить файлы и базу данных
Необходимо проверить:
- ядро WordPress;
- плагины;
- темы;
- каталог загрузок;
- конфигурационные файлы;
- базу данных;
- административные учётные записи.
3. Найти механизм повторного заражения
Удаление одного вредоносного файла не означает, что сайт очищен. Нужно проверить, не оставил ли злоумышленник дополнительные точки входа, изменённые файлы, административные аккаунты или другие механизмы сохранения доступа.
4. Определить первоначальную точку входа
По возможности необходимо сопоставить:
- время запросов;
- IP-адреса;
- URL;
- изменения файлов;
- изменения БД;
- создание пользователей;
- действия администратора.
Именно это позволяет понять, как сайт был взломан, а не просто удалить последствия атаки.
5. Восстановить чистые файлы
Изменённые системные файлы и файлы тем нужно заменить чистыми копиями. Если используется резервная копия, необходимо убедиться, что она создана до заражения.
6. Обновить компоненты
После определения причины нужно обновить WordPress, плагины и темы до актуальных безопасных версий. Ненужные компоненты следует удалить, а не просто отключить.
7. Сменить доступы
После очистки необходимо сменить:
- пароли пользователей;
- пароли хостинга и FTP/SFTP;
- секретные ключи WordPress;
- другие учётные данные, которые могли быть доступны злоумышленнику.
8. Проверить последствия для SEO
После очистки важно проверить не только файлы и базу данных, но и то, что увидели поисковые системы за время заражения:
- индексируемые URL;
- sitemap.xml;
- robots.txt;
- редиректы;
- метатеги;
- канонические URL;
- страницы, которые появились во время заражения;
- Search Console;
- логи сервера.
Не стоит вслепую удалять все подозрительные файлы или ограничиваться кнопкой «Вылечить». Это может нарушить работу сайта и при этом не устранить первоначальную уязвимость или механизм повторного заражения.
Почему просто обновлять WordPress недостаточно
Обновление WordPress и плагинов — обязательная часть защиты сайта. Но не достаточно просто периодически нажимать кнопку «Обновить».
Перед обновлением важно учитывать совместимость компонентов и наличие резервной копии.
После обновления необходимо проверить, продолжает ли сайт нормально работать: открываются ли страницы, работают ли формы, авторизация, интеграции и другие критически важные функции.
Кроме того, на сайте могут оставаться:
- отключенные, но уязвимые плагины;
- устаревшие темы;
- ненужные компоненты;
- изменённые файлы;
- подозрительные административные аккаунты;
- ранее внедренный вредоносный код.
Если у вас в команде нет своего грамотного программиста, который делает регулярную проверку технического состояния сайта (а не только установку обновлений), мы можем предоставить вам техническое сопровождение.
Что могло снизить риск этих взломов
В обоих расследованных случаях регулярный технический контроль позволил бы раньше обнаружить проблему с версиями компонентов.
Минимальный набор регулярных задач для WordPress-сайта включает:
- контроль версии WordPress;
- контроль версий плагинов и тем;
- отслеживание критических уязвимостей;
- своевременную установку обновлений;
- удаление ненужных компонентов;
- контроль резервного копирования;
- проверку административных учетных записей;
- контроль изменений файлов;
- проверку сайта после обновлений;
- периодическую проверку безопасности и технических ошибок.
Это особенно важно для сайтов, которые приносят компании заявки, продажи или поисковый трафик.
Когда сайт работает нормально, технические проблемы часто остаются незаметными. Но одна старая версия компонента может превратить небольшую задачу по обновлению в расследование взлома, восстановление сайта и последующее восстановление поисковой видимости.
Именно поэтому мы рассматриваем техническое сопровождение как постоянную работу с сайтом, а не как разовое исправление ошибки.
Что входит в техническое сопровождение WordPress
В рамках сопровождения программист может контролировать:
- обновления WordPress;
- обновления плагинов и тем;
- совместимость компонентов;
- резервное копирование;
- технические ошибки;
- изменения файлов;
- административные учетные записи;
- работу форм и ключевых функций;
- технические проблемы, влияющие на SEO;
- безопасность и последствия обнаруженных уязвимостей.
Если появляется проблема, не приходится отдельно искать программиста и объяснять ему историю сайта: техническое состояние уже находится под контролем специалиста.
Если вы хотите подробнее узнать об услуге или заказать техническое сопровождение сайта, напишите нашему менеджеру.
Не ждите взлома, чтобы заняться техническим состоянием сайта
Два расследованных нами случая произошли совсем недавно — в начале августа 2026 года. Они показывают одну и ту же проблему: уязвимость может находиться на сайте задолго до того, как её обнаружит владелец.
При этом последствия появляются уже после успешной атаки: изменяются файлы и база данных, создаются новые пользователи, появляются мусорные страницы, нарушается работа сайта и страдает поисковая видимость.
Поэтому регулярное техническое сопровождение — это не только способ быстрее исправлять ошибки. Это способ постоянно контролировать состояние сайта и снижать вероятность того, что устаревший или уязвимый компонент останется без внимания.
Если на вашем сайте давно не проводилась техническая проверка, установлены старые плагины или обновления выполняются нерегулярно, мы в Ant-Team.ru можем взять эту часть работы на себя.
Наш программист будет заниматься техническим состоянием сайта, а ваша команда сможет сосредоточиться на бизнесе и продвижении.
Напишите нам, если хотите обсудить техническое сопровождение вашего сайта или сайтов вашего клиента.
Также у нас действует партнерская программа на техническую поддержку сайтов. Подробности для партнеров по ссылке.
Автор: Сергей Фуфаев, web-разработчик в Ant-Team.ru.
Подписывайтесь на наш телеграм-канал, чтобы первыми узнавать о выходе новых материалов. И смотрите наши полезные видео на YouTube, VK и Rutube.