Главная/Блог/Безопасность и данные

wp2shell: уязвимость WordPress, из-за которой сайт можно захватить без пароля

Безопасность и данные Автор: Дмитрий Рогачев 8 минут
Уязвимость WordPress wp2shell

В июле 2026 года в WordPress закрыли уязвимость, которая позволяет захватить сайт, не зная ни логина, ни пароля, — достаточно знать адрес. Её назвали wp2shell. Рабочий код атаки уже гуляет по интернету, и сайты по нему ломают прямо сейчас. Если у вас сайт на WordPress, потратьте пять минут. Ниже по порядку: что произошло, каких версий WP это касается и как обезопасить себя.

Предыстория

Историю запустили исследователи безопасности. Одна группа — TF1T, dtro и haongo — нашла в WordPress возможность подсунуть движку собственный запрос к базе данных. Независимо от них Адам Куэс из исследовательской команды Assetnote ковырял служебный интерфейс WordPress и обнаружил там путаницу с маршрутами. Обе находки ушли разработчикам ядра.

Отдельная важная деталь: свою половину связки Куэс нашёл с помощью ИИ-модели, и вся работа обошлась примерно в 25 долларов. Такие находки скупают брокеры эксплойтов — компании-посредники, которые перепродают уязвимости дальше, чаще всего государственным структурам. За рабочую уязвимость такого класса в WordPress они платят до полумиллиона долларов. Сам он описывает это так: модель написала цепочку атаки от SQL-инъекции до выполнения кода за четыре часа, а он потом разбирался, как всё это работает.

Дальше выяснилось интересное: по отдельности каждая уязвимость неприятная, но не критическая. А в связке они дают постороннему человеку полный контроль над сайтом. Отсюда и название — wp2shell, «от WordPress до shell», то есть до выполнения своих команд.

17 июля 2026 года WordPress выпустил сразу три обновления — 6.8.6, 6.9.5 и 7.0.2. Внепланово: обычно релизы идут по расписанию, а тут ждать не стали. Более того, разработчики задействовали систему автообновлений — то есть патч принудительно установили на все уязвимые сайты, до которых дотянулись. К такому прибегают крайне редко и только тогда, когда деваться уже некуда.

Как работает атака

Если описать всё простыми словами, то захват идёт в три шага.

Три шага атаки wp2shell
  1. Обход проверки прав. У WordPress есть служебный интерфейс, куда можно отправить несколько запросов одним пакетом. Права проверяются на входе, для всего пакета, а выполняется каждый запрос уже внутри — по своему собственному маршруту. В этот зазор и пролезает запрос, который сам по себе проверку бы не прошёл.
  2. Кража пароля администратора. Дальше подсовывается собственный запрос к базе данных, откуда и достаётся зашифрованный пароль администратора.
  3. Выполнение чужого кода. От имени администратора ставится безобидное на вид дополнение с закладкой внутри. После этого злоумышленник выполняет на сервере свой код.

Тут стоит понимать вот что: полных прав на сервер эта дыра дать не может — если только администратор не совсем отбитый и не выполняет PHP-код под правами root-пользователя. Код исполняется от имени того пользователя, под которым работает сайт. Но и этого хватает с запасом: постороннему достаётся всё, до чего дотягивается сам сайт — файлы, база данных со всеми клиентами, отправка почты с вашего домена, доступ к соседним сайтам на том же аккаунте хостинга. Доступ к сайту у вас при этом никуда не денется. Просто теперь он не только у вас.

И ни на одном шаге не нужны логин с паролем — нужен только адрес сайта. Поэтому атаку легко автоматизировать: боты могут перебирать сайты подряд.

Форма входа в админку WordPress

Отсюда вывод, о который спотыкаются чаще всего. Всё, что стоит на форме входа — длинный пароль, лимит попыток, капча, второй фактор, — эту атаку не встречает: она в форму просто не заходит. Так что «у нас надёжный пароль» здесь не аргумент.

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

Почему это не «очередная дырка»

Уязвимости оценивают по десятибалльной шкале. Здесь 9,8 и 9,1 — верхняя часть, куда попадают единичные случаи в год.

Далее, 21 июля 2026 года, через четыре дня после выхода заплатки, обе уязвимости внесли в каталог активно эксплуатируемых уязвимостей CISA — агентства кибербезопасности США. Попадание туда означает не «может быть опасно», а зафиксированные взломы. Госорганам США назначили сроки устранения: 24 июля и 4 августа. Рабочий код атаки к тому моменту уже опубликовали.

То есть от выхода исправления до подтверждённых атак прошло четыре дня.

Чем может быть чреват захват сайта для бизнеса:

Последствие Что видит бизнес
Подмена содержимого чужой контент, реклама, редиректы на посторонние сайты
Кража базы утечка клиентских данных и учётных записей
Спам с вашего домена домен в чёрных списках, письма компании перестают доходить
Пометка в поиске «сайт может быть опасен», вылет из выдачи, падение заявок
Шифровальщик сайт недоступен, восстановление только из копии

Каких версий это касается

Уязвимы три ветки WordPress. Посмотрите на свою версию и сравните:

Ваша ветка Уязвима Безопасная версия
7.0.x ниже 7.0.2 7.0.2
6.9.x ниже 6.9.5 6.9.5
6.8.x ниже 6.8.6 6.8.6
ниже 6.8 эта уязвимость не затрагивает

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

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

  1. Зайдите в админку. Версия видна в разделе Консоль → Обновления или внизу любой её страницы.
  2. Сравните с таблицей. Ниже безопасной версии в своей ветке — сайт уязвим, обновляться нужно немедленно.
  3. Заодно откройте ваш-сайт.ру/readme.html. Открылось и показало номер версии — значит, версию движка видит любой желающий, включая ботов. Файл нужно удалить.

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

Почему «просто обновиться» получается не у всех

Кажется, что всё очень просто: нажал кнопку «обновить» — минутное дело. На практике мы постоянно видим другое. У части компаний сайтом давно никто предметно не занимается: подрядчик сменился, задача «следить за обновлениями» потерялась, версия движка давно устарела. И пока сайт открывается, всем кажется, что всё в порядке.

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

Частые вопросы

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

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

  • с вашего домена начинает уходить спам — вы узнаёте об этом, когда письма компании перестают доходить до клиентов, а домен оказывается в чёрных списках;
  • в папках сайта появляются посторонние файлы — веб-шеллы, через которые чужой человек заходит внутрь, когда ему удобно, даже после смены паролей;
  • сайт превращается в раздатчик вирусов для собственных посетителей;
  • на нём появляются сотни чужих скрытых страниц-дорвеев — казино, аптеки, подделки. Часто их показывают только поисковым роботам, а вы, открывая сайт, видите всё как обычно;
  • ресурсы сервера уходят на майнинг или на атаки чужих сайтов, а вы видите только необъяснимые тормоза и письмо-комплейн от хостинга;
  • клиентскую базу выгружают и продают без единого следа на страницах.

Поэтому «сайт открывается и выглядит нормально» ничего не доказывает. Надёжный ответ может дать только проверка изнутри: цела ли файловая часть ядра, нет ли неизвестных пользователей с административными правами, чужих файлов в загрузках, незнакомых задач по расписанию.

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

У меня стоит плагин безопасности, он защитит? Частично. Плагин фильтрует часть запросов, но дыра в самом движке — это фундаментальная уязвимость, её закрывает только обновление. Плагин — сигнализация, а не заделанная стена.

Хостинг сам обновляет сайты? Некоторые ставят автообновления безопасности, но полагаться на это как на гарантию нельзя: политики у всех разные, а ответственность за сайт остаётся на владельце.

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

Что в итоге

wp2shell — не повод для паники, но повод потратить несколько минут. Откройте админку, посмотрите версию, сверьтесь с таблицей. Уязвимы и есть кому обновить — обновляйтесь сегодня. Некому или страшно — не оставляйте на самотёк.

Мы можем посмотреть ваш сайт и сказать, касается ли вас эта история. Без «купите у нас абонемент» — просто честно скажем, как есть.

Источники:

Дмитрий Рогачев, Основатель ITHOUSE
Дмитрий Рогачев
Основатель ITHOUSE

Занимается ИТ-инфраструктурой с 2011 года. Под управлением компании более 25 организаций на постоянном обслуживании, самое долгое сопровождение длится 15 лет. Сертифицированный консультант VK Tech по VK WorkSpace.

Проверим ваш сайт

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

Получить бесплатный аудит
Читайте также

Другие статьи