
О чём статья
В июле 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. Внепланово: обычно релизы идут по расписанию, а тут ждать не стали. Более того, разработчики задействовали систему автообновлений — то есть патч принудительно установили на все уязвимые сайты, до которых дотянулись. К такому прибегают крайне редко и только тогда, когда деваться уже некуда.
Если описать всё простыми словами, то захват идёт в три шага.

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

Отсюда вывод, о который спотыкаются чаще всего. Всё, что стоит на форме входа — длинный пароль, лимит попыток, капча, второй фактор, — эту атаку не встречает: она в форму просто не заходит. Так что «у нас надёжный пароль» здесь не аргумент.
Снимать защиту со входа при этом не нужно: от перебора паролей она работает и остаётся нужной. Просто это другая дверь, и от 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 вас не касается. Но расслабляться не стоит: версия старше двух лет несёт свою кучу проблем. Паниковать из-за этой новости всё же не надо. Проверяйте свою версию, а не пугайтесь заголовков.
ваш-сайт.ру/readme.html. Открылось и показало номер версии — значит, версию движка видит любой желающий, включая ботов. Файл нужно удалить.Перед началом обновлений обязательно создайте резервную копию файлов и базы. Обновляя старый сайт, помните: обновили один из модулей — и есть риск непредсказуемого поведения и конфликта зависимостей. С копией вы можете откатиться и действовать иначе. Без копии рискуете остаться и без дыры, и без сайта.
Кажется, что всё очень просто: нажал кнопку «обновить» — минутное дело. На практике мы постоянно видим другое. У части компаний сайтом давно никто предметно не занимается: подрядчик сменился, задача «следить за обновлениями» потерялась, версия движка давно устарела. И пока сайт открывается, всем кажется, что всё в порядке.
Как это выглядит изнутри и что копится на сайтах, за которые никто не отвечает, мы разобрали на живом примере во второй статье.
Как понять, что мой сайт уже взломали? Заметные признаки: чужой контент и реклама на страницах, редиректы на посторонние сайты, незнакомые страницы в поиске, письмо от хостинга о вредоносном коде.
Чаще взлом происходит незаметно: сайт ломают не ради него самого, а чтобы им пользоваться. Что бывает на практике:
Поэтому «сайт открывается и выглядит нормально» ничего не доказывает. Надёжный ответ может дать только проверка изнутри: цела ли файловая часть ядра, нет ли неизвестных пользователей с административными правами, чужих файлов в загрузках, незнакомых задач по расписанию.
Обновление может сломать сайт — что делать? Сначала копия, потом обновление. Старый и сложный сайт лучше обновлять по шагам и сперва на тестовой копии. Сломается — вернётесь к рабочей версии.
У меня стоит плагин безопасности, он защитит? Частично. Плагин фильтрует часть запросов, но дыра в самом движке — это фундаментальная уязвимость, её закрывает только обновление. Плагин — сигнализация, а не заделанная стена.
Хостинг сам обновляет сайты? Некоторые ставят автообновления безопасности, но полагаться на это как на гарантию нельзя: политики у всех разные, а ответственность за сайт остаётся на владельце.
Версия давно не обновлялась, боюсь ставить обновление. Страх обоснованный. Порядок тот же: полная копия, проверка на тестовой площадке, потом боевое обновление. Если внутри некому этим заниматься — дешевле один раз позвать специалиста, чем восстанавливать сайт после взлома.
wp2shell — не повод для паники, но повод потратить несколько минут. Откройте админку, посмотрите версию, сверьтесь с таблицей. Уязвимы и есть кому обновить — обновляйтесь сегодня. Некому или страшно — не оставляйте на самотёк.
Мы можем посмотреть ваш сайт и сказать, касается ли вас эта история. Без «купите у нас абонемент» — просто честно скажем, как есть.
Источники:
Посмотрим версию движка и плагинов, найдём публичные утечки и следы взлома, скажем честно, касается ли вас эта история. Отчёт останется у вас в любом случае.
Получить бесплатный аудит
Как сайты остаются без ответственного, что показывает аудит и что проверить у себя за пять минут.
Читать
Четыре типовые ситуации, в которых бэкапы формально настроены, но в день аварии оказываются бесполезны. И три проверки, которые…
Читать