Нынче о возможных опасностях для сайтов на WordPress: исходим из того, что речь идёт о подозрительном адресе @wp2shell.invalid, который может встречаться в разделе «Пользователи» новые неизвестные регистрации и, что странно, с правами «Администратор!», или в технических сводках вашего ресурса — всё это вызывает тревожные вопросы у владельцев сайтов. Разберёмся, является ли это признаком взлома, ошибкой или штатной особенностью системы.
Важно понимать: @wp2shell.invalid — это не штатный адрес WordPress и не название плагина (хотя, в моей практике встречалось, когда на сайте появлялись подобные установленные сторонним скриптом плагины).
Как и говорилось, подобные адреса (или производные, кои несложно узнать по характерным знакам) могут использоваться злоумышленниками при создании поддельной учётной записи администратора после эксплуатации уязвимости wp2shell. Поэтому особое внимание уделим не только обновлению WordPress, но и проверке сайта на возможные следы взлома — пару раз мне приходилось даже практически полностью восстанавливать сайт (что называется «с нуля»):
- Что такое WP2Shell и почему об этой уязвимости заговорили владельцы сайтов?
- какие версии WordPress затронула уязвимость WP2Shell
- какие версии WordPress были уязвимы?
- что означает адрес электронной почты @wp2shell.invalid?
- как происходит атака WP2Shell?
- как проверить WordPress на наличие следов WP2Shell — с подведением итогов
- проверьте список пользователей
- проверьте установленные плагины
- осмотрите файлы сайта — это можно сделать визуально, если имеются некие навыки
- проверьте журналы сервера
- как защитить сайт WordPress от WP2Shell — профилактика
- шаг 1 — обновите WordPress
- шаг 2 — проверьте и очистите сайт
- шаг 3 — смените пароли и секретные ключи
- шаг 4 — настройте дополнительную защиту
- можно ли проверить сайт через WP2Shell Checker?
- как эпилог статье: почему нельзя игнорировать адрес @wp2shell.invalid?
WordPress версия 7.1 — обновление движка. Исправление ошибок касательно wp2shell. о версиях cms WordPress (по версии 7.0 здесь)…
Вот так могут выглядеть «левые» пользователи и, что интересно, с правами Администратора! (я самого нижнего я оставил для фотки):
А плагины, добавленные скипом, могут выглядеть примерно так (напоминаю — отличить их можно по характерным приметам):
Как видите — 2 несанкционированных админом сайта плагина:
- W2S Batch Guard 54eb65
- W2S Firewall 54eb65
В данном случае, если уж были внедрены плагины с большой долей вероятности придется чисть и Базу данных сайта!
Давайте теперь разберемся с теорией относительно «дыры» версий WP 6.9 и 7.0 и что со всей этой бедой возможно сделать:
Что такое WP2Shell и почему об этой уязвимости заговорили владельцы сайтов?
В 2026 году специалисты по информационной безопасности невзначай обнаружили достаточно серьёзную цепочку уязвимостей в ядре WordPress, коя получила имя WP2Shell. Однако, следует добавить сюда же и то, что проблема затронула только определённые версии популярной CMS и позволяла злоумышленникам получить контроль над сайтом без предварительной авторизации. Если определенные версии — а именно 6.9 и 7.0 — то, следует предположить, что лазейка вкралась вместе с недоработанными обновлениям.
Говорят, что следы «дыры» найдены и в версии 6.8 WordPress — я ничего не могу об этом сказать. В своей практике не сталкивался. Зато сталкивался с теми, которые это игнорируют и не исправляют (банальным обновлением) — я уж об очистке кода ядра и Базы Данных и не говорю, раз дорого им кажется, пусть теряют свои сайты! Это их право!
Моим же читателям — с жирным подчёркиванием советую решить и закрыть (по возможности) эту тему, коли случилась беда и обнаружили подобные следы у себя!
Ситуация и ее особенности заключались в том, что для проведения так называемой атаки не требовалось устанавливать вредоносный плагин или получать пароль администратора — то есть напрямую взламывать сайт. Но уязвимости находились непосредственно в механизмах обработки запросов WordPress.
Таким образом получается, если, скажем, у вас имелась на сайте какая-то зашита в виде кода или плагина — он ничего бы не сообщила админу — так как процессы все внутри, а не извне!
После успешной атаки (внутренней обработки определенного запроса) назовём его «код2-shell» создает в недрах сайта новую учётную запись дополнительного администратора, — а значит: получает повышенные права и может загрузить вредоносный плагин, разместить PHP-скрипты с возможностью выполнять команды на сервере.
Одним из возможных следов такой активности стало появление подозрительных пользователей с адресами электронной почты вида @wp2shell.invalid. Если подобная запись обнаружена в административной панели WordPress, это серьёзный повод проверить сайт на компрометацию.
какие версии WordPress затронула уязвимость WP2Shell
Проблема связана с двумя уязвимостями, которые при совместной (или общей) эксплуатации легко образуют цепочку удалённого выполнения того или иного кода (RCE) — exploit.
Эксплойт (англ. exploit — использование в своих целях /эксплуатация/) — код или фрагмент кода, программа или последовательность действий (о чём говорилось выше), которые же используют некую уязвимость в программном обеспечении (в нашем случае «взлома / управления»).
Речь идёт о следующих идентификаторах:
- CVE-2026-63030 — ошибка обработки маршрутов и последующих запросов в механизме REST API Batch
- CVE-2026-60137 — уязвимость SQL Injection, связанная с возможными обработками параметра author__not_in в WP_Query
При объединении этих двух проблем в единое — скажем так, злоумышленник мог обойти предусмотренные ограничения (безопасности) и выполнить SQL-инъекцию, вследствие чего получить возможность запускать собственный код на сервере. И это, как догадываетесь, может быть все, что угодно-с, господа!)
Также обращаю ваше пристальное внимание на тот факт, что узвимость CVE-2026-63030 получила оценку 9,8 по шкале CVSS, что прямо указывает на критический уровень опасности.
какие версии WordPress были уязвимы?
| Версия WordPress | Состояние |
|---|---|
| 6.8.0–6.8.5 | Уязвимость SQL Injection, но не полная цепочка RCE WP2Shell |
| 6.8.6 | Исправлена SQL Injection |
| 6.9.0–6.9.4 | Полная цепочка WP2Shell |
| 6.9.5 и выше | Уязвимость исправлена |
| 7.0.0–7.0.1 | Полная цепочка WP2Shell |
| 7.0.2 и выше | Уязвимость исправлена |
Важно учитывать, что исправление в WordPress 6.8.6 устранило SQL-инъекцию, но эту ветку не следует приравнивать к версиям 6.9 и 7.0, в которых была доступна полная цепочка удалённого выполнения кода.
Первые исправления появились 17 июля 2026 года. Однако установка обновления не гарантирует, что сайт, который ранее подвергался атаке, уже полностью очищен от вредоносных файлов.
что означает адрес электронной почты @wp2shell.invalid?
Особое внимание владельцам сайтов стоит обратить на адреса электронной почты с доменом wp2shell.invalid.
Например, в списке пользователей WordPress может появиться следующая запись (скриншот в старте статьи):
- Имя пользователя: yun_11
- эл/почта: yun_11@wp2shell.invalid
- роль: Администратор
Такие учётки пользователи (внимательные) обнаруживают у себя на сайте и тут же обращаются ко мне или ребятам, описывают свои вопросы и требования… Проблема взлома обнаружена, а значит с этим что-то нужно делать — в данном случае наблюдается очень видимая эксплуатация WP2Shell!
Обратите внимание на доменное имя .invalid — оно зарезервировано системами для заведомо недействительных адресов. Не предназначается для обычной регистрации почтовых ящиков. В данном случае такой адрес выступает характерным признаком подозрительной эксплойт активности.
И вообще… советую присмотреться к пользователям сайта — особенно с префиксами:
- wp2_;
- w2s_;
- другие случайные И СТРАННЫЕ комбинации символов.
Имейте в виду, что, если сайт уже продолжительное время «взломан» то злоумышленники могут маскироваться! совершенно обычными именами, поэтому отсутствие характерного адреса (символики) не означают, что сайт находится в безопасности!
Главное: адрес @wp2shell.invalid не является штатным инструментом ядра и систем WordPress. И если вы обнаруживаете его у себя среди администраторов — это знак ВНИМАНИЕ!!. проверьте истории изменения файлов, файлы сайта и журналы .logs сервера… Рекомендую плагин Solid Security Basic, есть много необходимого по защите сайта (по ссылкам далее переходите).
как происходит атака WP2Shell?
Как и упоминал выше, для эксплуатации данной уязвимости используется механизм REST API Batch, предназначенный для обработки нескольких API-запросов в рамках одного обращения.
Одно из активаций маршрутов выглядит следующим образом:
/wp-json/batch/v1
…далее соответствующий запрос к ядру может передаваться через, например, такой параметр:
?rest_route=/batch/v1
Теперь вновь внимание: из-за ошибки обработки вложенных запросов (последовательностей) злоумышленники получали возможности добиться ситуации, когда проверка запроса и его фактическое выполнение происходили с разной(ими) интерпретацией(иями) маршрута(ов).
Затем, в сочетании с SQL-инъекцией это позволяло достаточно легко обойти ограничения и перейти к выполнению произвольного кода — ведь, скажем так, «серверная» защита не определяет в подобных действиях подозрений.
Типичные последовательности «привнесенных» действий могут выглядеть так:
- код (или злоумышленник) отправляет специально сформированные запросы к REST API сайта;
- использует ошибки обработки запросов и SQL-инъекцию;
- по итогу, например — получает возможность создать новую учётную запись администратора;
- загружает вредоносный плагин или размещает PHP-скрипт на сервере;
- использует установленный веб-шелл для выполнения коман;
- получает возможность изменять файлы сайта, внедрять перенаправления, размещать дополнительный вредоносный код и похищать данные.
Весьма неприглядная для владельца сайта ситуация и таким образом WP2Shell (ВП2 шелл) представляет опасность не только для общего содержимого сайта, но и для безопасности всего серверного окружения, если права веб-сервера позволяют выполнять дополнительные действия. Но — это другая история — а тем админам, у которых сайты размещены на виртуальных хостингах именно по этому поводу переживать не стоит — там автоматическая защита со стороны хостинга.
как проверить WordPress на наличие следов WP2Shell — с подведением итогов
Не грех напомнить: если ваш сайт (или сайт клиента) работал на WordPress 6.9.0–6.9.4 или 7.0.0–7.0.1, рекомендуется провести полноценную проверку, даже если CMS уже обновлена!
проверьте список пользователей
Откройте административную панель WordPress и перейдите в раздел:
Пользователи → Все пользователи — особенно внимательно присмотритесь и изучите учётные записи с ролью «Администратор».
Проверьте:
- Не появились ли незнакомые администраторы (вообще-то, админ должен быть только один — за исключением неких контролируемых случаев);
- нет ли адресов электронной почты с доменом @wp2shell.invalid;
- не встречаются ли подозрительные имена по типами wp2_… или w2s_…. и пр. пр;
- совпадает ли дата создания новых админ-пользователей с периодом предполагаемой атаки!!
- не изменились ли роли существующих учётных записей…
Если обнаружен неизвестный администратор, не ограничивайтесь простым удалением пользователя — он все равно (или другой) новый появятся через какое-то время!!. Перед поиском и решение проблемы — рекомендую сохранить резервную копию и данные (файлы/БД), необходимые для расследования этакого инцидента.
проверьте установленные плагины
Перейдите в раздел Плагины → Установленные плагины — обратите внимание на неизвестные расширения, которые вы не устанавливали самостоятельно.
В частности, стоит проверить каталоги с названиями вида (примеры с картинками давал в старте статьи):
wp-content/plugins/wp2shell_...
В некоторых вариантах атаки создавались случайные названия плагинов с буквенно-цифровыми окончаниями.
При этом отсутствие подозрительных на ваш взгляд каталогов никоим образом не доказывает безопасность сайта: вредоносные файлы могут размещаться в других директориях или удаляться после выполнения…
осмотрите файлы сайта — это можно сделать визуально, если имеются некие навыки
Особое внимание уделите следующим каталогам:
- wp-content/plugins/;
- wp-content/cache/;
- wp-content/uploads/;
- wp-content/mu-plugins/;
- wp-includes/ (ядро WP);
- wp-admin/ (ядро WP);
- wp-content/themes/.
Ищем неизвестные PHP-файлы, недавно внесённые скрипты, обращайте внимание на подозрительные архивы и каталоги, которые не относятся к установленным расширениям или теме оформления (шаблону вашего сайта). У меня был случай, когда было очень раскурочена дочерняя тема одного из сайтов!
Не удаляйте файлы только потому, что их названия кажутся необычными. Сначала необходимо установить их происхождение и назначение. Хотя бы обратитесь к банальному Поисковику Google.
проверьте журналы сервера
Если у вас есть доступ к логам веб-сервера, изучите обращения к маршрутам:
/wp-json/batch/v1
и
/?rest_route=/batch/v1
Дополнительными признаками подозрительной активности могут выступать такие:
- большое (необычное) количество POST-запросов;
- User-Agent со значениями wp2shell или cve-2026-63030/1.0 — это говорит само за себя;
- ответы HTTP 207 при подозрительных обращениях к Batch API;
- последующие (странные/незнакомые/непонятные) запросы на загрузку плагинов;
- создание новых администраторов — это явный признак собраться вашим вниманием к сайту!
- появление незнакомых PHP-файлов (или даже каталогов) в директориях сайта.
Отдельный запрос или код с ответом 207 не доказывает безусловный взлом! Оценивать следует по совокупностям событий и их последовательности…
Моя рекомендация на подобные случаи — обратитесь к специалисту (веб-разработчику, специализирующемся на WP). Так быстрее и правильнее — и, главное, дешевле во всяких смыслах — выйдет решение проблемы!
как защитить сайт WordPress от WP2Shell — профилактика
Самая важная мера — своевременно установить исправленную версию WordPress. Но если сайт уже подвергался атаке, потребуется дополнительная и более углублённая проверка и очистка. Полноценный анализ сайта на предмет очистки…
шаг 1 — обновите WordPress
Откройте раздел Консоль → Обновления и проверьте установленную версию CMS — минимальные версии, в которых были обнаружены компоненты уязвимости:
- WordPress 6.8.6;
- WordPress 6.9.5;
- WordPress 7.0.2.
На момент подготовки статьи, в официальном списке выпусков указаны более свежие версии: WordPress 7.1.4, 7.0.8 и 6.9.11 соответственно.
Предпочтительно использовать актуальную поддерживаемую версию WordPress, а не оставаться на старой ветке только ради минимального по затратам исправления безопасности! это, если, конечно, вы дорожите своим сайтом!
Перед обновлением сделайте резервную копию файлов и Базы данных (все это обязательно пригодится). К тому же, если хотите совета — работайте на тестовом сайте, полной копии зараженного ресурса: там отыскивайте и отлавливайте ошибки! потом перенесете правки разом на активный сайт
шаг 2 — проверьте и очистите сайт
Если есть признаки успешной эксплуатации WP2Shell, одного обновления обычно, как показывают практики моя и моих коллег, недостаточно.
Что я рекомендую выполнить:
- сохранить резервную копию для последующих анализов (одно как правило бывает недостаточно);
- выполняем самое очевидное для начала: удаляем неизвестные учётные записи после проверки и сохранения необходимых данных;
- визуально проверяем плагины и темы;
- заменяем подозрительные файлы чистыми копиями из официальных источников (скачайте свежайший WordPress и берите из него);
- проверить mu-plugins, каталоги кэша и загрузок;
- проверить wp-config.php, .htaccess и задания cron;
- проверить базу данных на неизвестных администраторов и изменения настроек;
- следует доподлинно убедиться, что на сервере не осталось веб-шеллов и всяких там механизмов повторной установки вредоносного кода.
При точно подтверждённом взломе — правильнее всего привлечь специалиста по безопасности или же обратитесь к своему хостинг-провайдеру. Простое удаление подозрительного плагина/кода/пользователя не устранит последствия атаки.
шаг 3 — смените пароли и секретные ключи
После устранения вредоносного кода необходимо обновить:
- пароли администраторов WordPress (обязательно!);
- пароли FTP/SFTP (обязательно!);
- доступ к панели управления хостингом (обязательно!);
- пароль базы данных (или перенесите данные на новую созданную), если он мог быть раскрыт (обязательно!);
- другие учётные данные, доступные с сервера.
Также рекомендуется обновить секретные ключи и соли авторизации WordPress в конфигурации сайта. Это поможет завершить действующие (активные) пользовательские сессии в админке сайта.
шаг 4 — настройте дополнительную защиту
- Для снижения риска повторных атак используйте средства мониторинга целостности файлов и защитные инструменты хостинга.
- в качестве временной меры (до окончательного исправления) можно ограничить анонимный доступ к REST API Batch по соответствующим маршрутам. Но помните — подобные блокировки чаще всего нарушают работу отдельных функций сайта — только как временный вариант защиты «текущего времени» работы сайта, а не как полноценную/серьёзную замену обновлению WordPress.
можно ли проверить сайт через WP2Shell Checker?
Исследователи Searchlight Cyber опубликовали специальную страницу для проверки уязвимости: wp2shell: Pre Authentication RCE in WordPress Core. На странице доступен WP2Shell Checker, по адресу сайта можно проверить наличие уязвимой версии.
Однако важно чётко понимать и осознавать разницы между проверкой уязвимости и расследованием взлома!!
Сканер всего-лишь помогает примерно определить, может ли сайт подвергаться атаке через определенную (условную) цепочку уязвимостей и не гарантирует, что на сайте отсутствуют ранее установленные веб-шеллы, скрытые администраторы или другие вредоносные изменения в коде или Базе данных.
…даже после успешного обновления и отрицательного результата проверки стоит внимательным образом осмотреть файлы, пользователей и журналы сервера, если сайт работал на уязвимой версии!
как эпилог статье: почему нельзя игнорировать адрес @wp2shell.invalid?
WP2Shell всем нам наглядно показал, что серьёзная угроза запросто может скрываться непосредственно в ядре CMS, даже если владелец сайта никогда не устанавливал подозрительных сторонних плагинов и работал со стандартной конфигурацией WordPress.
Особенно внимательно следует относиться к неожиданным администраторам со странными адресами электронной почты @wp2shell.invalid, неизвестным PHP-файлам и новым каталогам плагинов.
Для защиты сайта необходимо установить актуальное обновление WordPress, проверить учётные записи, провести тонкий и внимательный аудит файлов и базы данных, сменить пароли и убедиться, что на сервере не осталось вредоносного кода.
Если не можете этого выполнить самостоятельно, обратитесь к специалистам!..
И ещё важнейшее обстоятельство: не ждите появления явных ошибок взлома, перенаправлений на «опасные сайты» и пр. пр. или же предупреждений от поисковых систем — потом доказать что либо Поисковику будет сложно!.. вплоть до бана сайта!
Если ваш сайт работал на WordPress 6.9.0–6.9.4 или 7.0.0–7.0.1 — советую проверку безопасности провести даже если пока еще никаких подозрительных действий не было выявлено!!
…конструктивное и целеSEOбразное создание и продвижение сайтов — ATs media (запросто с WordPress) — Быть или не быть — не вопрос!:
На этом моя повесть нынче решительно окончена...!
Михаил ATs - 
