Администраторы WordPress-сайтов столкнулись с массовыми атаками через цепочку уязвимостей wp2shell, которая затрагивает не отдельный плагин или тему, а само ядро CMS. Это делает инцидент особенно серьезным: многие владельцы сайтов привыкли считать главной угрозой сторонние расширения, но в этот раз риск возник в базовой установке WordPress, причем атакующему не требовалась учетная запись администратора или предварительный доступ к сайту.
Уязвимость wp2shell объединяет две проблемы, получившие идентификаторы CVE-2026-63030 и CVE-2026-60137. В связке они позволяют злоумышленнику добиться удаленного выполнения кода до авторизации. Проще говоря, атакующий может отправить специально подготовленный запрос к уязвимому сайту и заставить сервер выполнить команды, хотя у него нет логина, пароля и обычных прав в панели управления WordPress.
Особенно опасно то, что атака работает против обычных установок WordPress без дополнительных условий. Для эксплуатации не нужен редкий плагин, специфическая тема, нестандартная настройка или заранее украденный пароль. Если сайт работает на уязвимой версии ядра, он уже может быть целью автоматического сканирования. Именно поэтому после появления публичных технических деталей атаки начались быстро и приобрели массовый характер.
Под угрозой оказались сайты на ветках WordPress 6.9.x и 7.0.x до выхода исправлений. Разработчики WordPress выпустили защитные обновления 17 июля 2026 года: версии 6.9.5 и 7.0.2, а также исправления для поддерживаемых веток. На многих сайтах автоматическое обновление могло сработать самостоятельно, но это не повод расслабляться. Администратору все равно нужно вручную проверить фактическую версию, потому что автообновления иногда отключены, ломаются из-за прав на файлы или не применяются на старых хостингах.
Название wp2shell хорошо отражает суть атаки. Цепочка уязвимостей позволяет перейти от обычного внешнего запроса к получению shell-доступа или установке webshell. Webshell — это вредоносный файл или плагин на сервере, через который злоумышленник может выполнять команды, загружать дополнительные файлы, менять содержимое сайта, создавать учетные записи, читать конфигурации и закрепляться в системе. Для владельца сайта это уже не просто «ошибка в WordPress», а полноценная компрометация сервера.
Одним из заметных признаков заражения стало появление подозрительной учетной записи администратора с именем Wp2shell. В некоторых случаях атакующие создавали сразу несколько новых администраторов, чтобы сохранить доступ даже после удаления одного аккаунта. Для защитника это важный сигнал: если на сайте появился неизвестный пользователь с правами администратора, нужно считать инцидент серьезным и проверять не только список пользователей, но и файлы, плагины, базу данных, логи и ключи доступа.
В других случаях злоумышленники устанавливали вредоносный плагин Wp2shell. Такой плагин мог выглядеть как обычное расширение, но фактически служил бэкдором. Через него можно было возвращаться на сайт после первичного взлома, выполнять команды, менять файлы и использовать сервер для дальнейших атак. Поэтому при проверке сайта недостаточно просто обновить WordPress. Нужно внимательно изучить список плагинов, особенно неизвестные, недавно добавленные или скрытые расширения.
Атаки также могли приводить к странному поведению REST API. Некоторые администраторы замечали ошибки 403 и проблемы с доступом к API, а затем обнаруживали, что на сайте уже создан новый администратор или добавлен вредоносный компонент. Это показывает, что последствия компрометации не всегда выглядят как очевидная подмена главной страницы. Иногда сайт продолжает работать, но внутри уже есть новый доступ, измененные настройки или скрытая малварь.
REST API в WordPress давно является важной частью современной CMS. Через него работают редактор блоков, мобильные приложения, интеграции, плагины, внешние сервисы и административные функции. Но любой мощный API увеличивает площадь атаки. Если в механизме обработки запросов появляется ошибка, злоумышленник может использовать ее не через красивый интерфейс сайта, а через специально подготовленные HTTP-запросы, которые обычный пользователь никогда не увидит.
Массовость атак объясняется тем, что WordPress занимает огромную долю рынка сайтов. Даже если уязвимыми окажется небольшая часть установок, это все равно тысячи и тысячи потенциальных целей. Для злоумышленников такая уязвимость особенно привлекательна: можно запустить автоматическое сканирование интернета, найти сайты с нужными версиями, проверить уязвимость и затем массово устанавливать webshell, бэкдоры или вредоносные плагины.
Главная опасность для владельца сайта заключается не только в потере контроля над страницами. Через WordPress часто проходят контактные формы, заказы, персональные данные клиентов, учетные записи пользователей, интеграции с платежными системами, API-ключи, почтовые сервисы, CRM и рекламные инструменты. Если атакующий получает доступ к серверу, он может украсть не только содержимое сайта, но и связанные секреты, токены и данные пользователей.
Отдельный риск связан с базой данных. WordPress хранит в ней настройки, пользователей, хеши паролей, записи, страницы, метаданные, данные плагинов и иногда чувствительную информацию из форм. Если атака позволила получить доступ к базе, злоумышленник может скачать ее и попытаться подобрать пароли офлайн. Даже если пароли хранятся не в открытом виде, слабые комбинации могут быть восстановлены. Поэтому после компрометации нужно менять пароли, а не просто удалять вредоносный файл.
Еще один важный шаг — замена salt-ключей WordPress. Эти ключи используются для защиты сессий и cookie. Если злоумышленник получил доступ к конфигурации сайта или базе, старые сессии могут оставаться опасными. После смены salt-ключей пользователей принудительно выбросит из аккаунтов, и им придется войти заново. Это неудобно, но полезно: так можно снизить риск, что атакующий сохранит доступ через старую авторизованную сессию.
При обнаружении признаков wp2shell нельзя ограничиваться обновлением ядра. Обновление закрывает входную дверь, но не удаляет того, кто уже мог попасть внутрь. Если сайт был скомпрометирован до установки патча, на сервере могут остаться webshell, вредоносный плагин, новый администратор, измененный файл темы, скрытый cron-запуск, подозрительная запись в базе данных или внешний скрипт. Поэтому проверка после обновления обязательна.
Первое действие администратора — убедиться, что сайт работает на исправленной версии WordPress. Затем нужно проверить всех пользователей с правами администратора, удалить неизвестные учетные записи и сменить пароли легитимных пользователей. После этого стоит включить двухфакторную аутентификацию, особенно для администраторов, редакторов и технических аккаунтов. Если атакующие успели похитить учетные данные, простой апдейт ядра не защитит от повторного входа.
Следующий шаг — ревизия плагинов и тем. Нужно удалить все неизвестные, неиспользуемые и недавно появившиеся расширения, проверить даты изменения файлов, сравнить содержимое с оригинальными версиями и переустановить чистые копии из надежных источников. Особенно подозрительны плагины с названиями, похожими на системные, резервные, временные или технические. Злоумышленники часто маскируют бэкдоры под безобидные служебные компоненты.
Файловая система сайта требует отдельной проверки. Webshell может находиться не только в папке плагинов. Его могут спрятать в uploads, в каталоге темы, в mu-plugins, во временных директориях, в кэше или в файлах с похожими на изображения расширениями. Иногда вредоносный PHP-код добавляют в уже существующий файл, чтобы он не выглядел новым. Поэтому лучше использовать сравнение с чистой копией WordPress и специализированные сканеры малвари.
Папка uploads заслуживает особого внимания. В нормальной конфигурации там должны храниться изображения, документы и медиафайлы, но не исполняемые PHP-скрипты. Если в uploads появились PHP-файлы, странные архивы, неизвестные исполняемые файлы или элементы с запутанными именами, это тревожный знак. На сервере желательно запретить выполнение PHP в каталогах загрузок, чтобы даже случайно загруженный webshell не смог запуститься.
Нужно проверить и файл wp-config.php. В нем могут находиться параметры базы данных, salt-ключи, нестандартные константы и иногда следы вредоносных изменений. Если атакующий получил доступ к этому файлу, он мог узнать пароль к базе данных. В таком случае желательно сменить пароль пользователя базы, обновить конфигурацию и проверить, не используется ли тот же пароль где-то еще. Повторное использование паролей в инфраструктуре резко увеличивает ущерб от одной компрометации.
Логи веб-сервера и PHP помогают понять масштаб атаки. В них можно искать подозрительные обращения к REST API, необычные POST-запросы, попытки загрузки файлов, доступ к неизвестным плагинам, обращения к wp-admin от необычных IP-адресов, создание пользователей и запуск странных скриптов. Даже если сайт уже очищен, логи помогают определить, когда началась атака и какие действия успел выполнить злоумышленник.
Если есть подозрение на успешную эксплуатацию, лучше восстановить сайт из чистой резервной копии, сделанной до даты компрометации. Но резервная копия должна быть действительно чистой. Если восстановить сайт из бэкапа, где webshell уже присутствовал, проблема вернется. После восстановления все равно нужно обновить WordPress, плагины и темы, сменить пароли, salt-ключи, токены API и проверить пользователей.
Резервные копии должны храниться отдельно от основного сайта. Если бэкапы лежат в той же файловой системе и доступны веб-серверу, злоумышленник может удалить или изменить их. Хорошая стратегия — иметь несколько копий, хранить их вне основного хостинга, регулярно проверять восстановление и не полагаться только на автоматическую функцию хостинг-панели. Бэкап полезен только тогда, когда его можно реально развернуть.
Для владельцев сайтов на виртуальном хостинге важен контакт с провайдером. Хостинг может иметь свои логи, WAF, уведомления, снимки файловой системы и средства блокировки вредоносных процессов. Если сайт был заражен через wp2shell, провайдер может помочь определить дату атаки, восстановить файлы, отключить выполнение PHP в опасных каталогах и проверить соседние сайты на том же аккаунте. На одном хостинг-аккаунте часто размещают несколько сайтов, и компрометация одного может угрожать другим.
Если WordPress используется в бизнесе, инцидент нужно рассматривать как возможную утечку данных. Нужно понять, какие персональные данные хранились на сайте, какие формы работали, были ли заказы, платежные интеграции, личные кабинеты и подписки. Если злоумышленник имел доступ к базе или файлам, он мог получить данные клиентов. В таких случаях техническая очистка сайта — только часть работы; может потребоваться юридическая и организационная оценка последствий.
Особенно опасны сайты интернет-магазинов. WooCommerce и похожие решения могут хранить данные заказов, адреса, телефоны, email, историю покупок, купоны, статусы платежей и интеграции с доставкой. Даже если полные данные банковских карт обычно не хранятся на сайте, злоумышленник может внедрить скрипт для перехвата платежей, изменить реквизиты, добавить поддельную форму оплаты или украсть клиентскую базу для дальнейшего фишинга.
Для SEO и репутации сайта заражение тоже опасно. Взломанный WordPress могут использовать для размещения спам-страниц, дорвеев, фишинговых форм, редиректов, вредоносных скриптов и скрытых ссылок. Владелец может заметить проблему не сразу, а уже после попадания сайта в черные списки браузеров, поисковых систем или антивирусов. После очистки придется не только удалять малварь, но и восстанавливать доверие поисковиков и пользователей.
Атаки wp2shell еще раз показывают, что безопасность WordPress нельзя строить только на принципе «не ставить сомнительные плагины». Это важное правило, но недостаточное. Уязвимость в ядре CMS может затронуть даже аккуратно обслуживаемый сайт. Поэтому нужны регулярные обновления, мониторинг файлов, резервные копии, ограничение прав, двухфакторная аутентификация, WAF, журналирование и готовый план реагирования.
Web Application Firewall может помочь снизить риск массовой эксплуатации, особенно если он умеет блокировать подозрительные REST-запросы и известные шаблоны атак. Но WAF не заменяет патч. Если ядро WordPress уязвимо, фильтр может выиграть время, но не гарантирует полной защиты. Злоумышленники часто меняют полезную нагрузку, обходят сигнатуры и ищут сайты без качественного фильтра. Главная мера — обновление до исправленной версии.
Администраторам также стоит ограничить доступ к wp-admin и критическим API там, где это возможно. Для корпоративных сайтов можно использовать VPN, allowlist IP-адресов, дополнительную HTTP-аутентификацию, защиту от перебора паролей и отдельные правила для REST API. Но такие ограничения нужно внедрять осторожно, чтобы не сломать редактор, интеграции и работу плагинов. Без понимания архитектуры можно случайно заблокировать легитимные функции сайта.
Принцип минимальных привилегий важен не только для пользователей WordPress, но и для серверной инфраструктуры. Файлы сайта не должны быть доступны на запись там, где это не требуется. PHP-процесс не должен иметь лишних прав на системные директории. Пользователь базы данных должен иметь только необходимые разрешения. Чем меньше прав у скомпрометированного компонента, тем сложнее злоумышленнику развить атаку.
Отдельно стоит проверить cron-задания. WordPress использует собственный механизм WP-Cron, а сервер может иметь системный cron. Злоумышленники иногда добавляют задачи, которые регулярно восстанавливают удаленный webshell, скачивают вредоносный код или создают нового администратора. Если удалить только видимый файл, но оставить задачу восстановления, заражение вернется через несколько минут или часов.
Нужно проверять и скрытые административные механизмы. В WordPress есть mu-plugins — обязательные плагины, которые загружаются автоматически и не всегда видны в обычном списке расширений. Это удобная функция для разработчиков и хостингов, но она может использоваться злоумышленниками для закрепления. Если на сайте есть директория mu-plugins, ее содержимое нужно обязательно просмотреть.
Еще один важный элемент — внешние ключи и интеграции. Если сайт подключен к почтовому сервису, CRM, платежному шлюзу, аналитике, облачному хранилищу или API маркетплейса, после взлома нужно менять соответствующие токены. Атакующий мог прочитать их из настроек плагинов, базы данных или конфигурационных файлов. Смена пароля администратора WordPress не защищает от уже украденного API-ключа.
Для разработчиков и агентств, которые обслуживают много WordPress-сайтов, wp2shell стал проверкой зрелости процессов. Если у компании десятки клиентских проектов, ручная проверка каждого сайта занимает много времени. Нужна централизованная инвентаризация версий, автоматические уведомления об уязвимостях, единый процесс обновления, резервные копии, список администраторов, мониторинг изменений файлов и шаблон реагирования на инцидент.
Инвентаризация особенно важна. Многие компании даже не знают точное количество своих WordPress-установок. Старые лендинги, тестовые сайты, забытые поддомены и архивные проекты могут оставаться в интернете годами. Именно такие забытые установки часто становятся легкими целями. Если сайт больше не нужен, его лучше отключить. Если нужен — обновлять и защищать наравне с основными ресурсами.
Ситуация с wp2shell также показывает, насколько опасна задержка между выпуском патча и его установкой. После публикации исправления исследователи и злоумышленники быстро анализируют изменения, понимают суть уязвимости и создают эксплойты. Поэтому «обновлю на следующей неделе» для критической RCE-уязвимости может быть слишком поздно. Если эксплойт уже публичен, счет идет не на месяцы, а на часы и дни.
Для небольших сайтов это может казаться избыточной тревогой, но массовые атаки не выбирают жертв вручную. Ботам безразлично, крупный это интернет-магазин или маленький блог. Они сканируют диапазоны адресов, проверяют версии и пытаются выполнить известный эксплойт. Маленькие сайты часто даже привлекательнее: у них слабее мониторинг, дешевле хостинг, реже обновления и меньше внимания администратора.
После очистки сайта стоит проверить его снаружи. Нужно убедиться, что нет неизвестных страниц, странных редиректов, спама в поисковой выдаче, подозрительных JavaScript-вставок, новых файлов sitemap, поддельных форм входа и вредоносных загрузок. Иногда владелец очищает административную часть, но не замечает, что поисковики уже проиндексировали сотни спам-страниц. Восстановление репутации может занять больше времени, чем техническое удаление webshell.
Для пользователей сайта тоже есть риск. Если зараженный WordPress раздавал вредоносный JavaScript или поддельные формы, посетители могли столкнуться с фишингом, кражей данных или перенаправлением на мошеннические страницы. Поэтому после серьезного инцидента владельцу нужно оценить, нужно ли уведомлять пользователей, менять пароли личных кабинетов, проверять журналы заказов и отключать подозрительные формы.
Отдельно важно не доверять поверхностному сканированию. Некоторые бесплатные онлайн-сканеры видят только то, что доступно извне. Они могут не заметить webshell, который скрыт в файловой системе и вызывается по специальному параметру. Они также не проверят базу данных, пользователей, cron, токены API и историю логов. Полная проверка должна выполняться изнутри сервера или через надежный инструмент с доступом к файлам и базе.
Хорошая практика после такого инцидента — переустановка ядра WordPress из чистого источника. Не нужно вручную лечить каждый системный файл, если можно заменить ядро на заведомо чистую версию. Но при этом нужно сохранить wp-content, базу данных и пользовательские файлы, проверив их отдельно. Вредоносный код чаще всего прячется именно в пользовательской части, поэтому простая переустановка ядра не всегда достаточна.
Для защиты на будущее стоит включить автоматические обновления безопасности, но не полагаться только на них. Автообновления могут спасать от срочных уязвимостей, но иногда они отключены из-за совместимости, корпоративных процессов или настроек хостинга. Лучше сочетать автоматические патчи с мониторингом версий и регулярной ручной проверкой. Если сайт критически важен, обновления нужно сначала тестировать на копии, но делать это быстро.
Двухфакторная аутентификация не остановит wp2shell на этапе первичной RCE-атаки, потому что уязвимость работает до авторизации. Но 2FA помогает после инцидента, когда злоумышленник мог получить пароли пользователей или попытаться войти через обычную панель управления. В кибербезопасности важно понимать, против какого этапа атаки работает каждая мера. Одной универсальной защиты не существует.
Также нужно ограничить количество администраторов. Чем больше аккаунтов с полными правами, тем выше риск. Редакторам и авторам не нужны административные полномочия. Технические аккаунты подрядчиков нужно отключать после завершения работ. Старые учетные записи бывших сотрудников и агентств должны удаляться или переводиться в безопасный режим. После wp2shell это особенно важно, потому что атакующие часто создают новых администраторов для закрепления.
Для серверов с несколькими сайтами нужно проверять межсайтовое заражение. Если один WordPress был взломан, злоумышленник может попытаться перейти к соседним директориям, если права настроены плохо. На дешевом хостинге несколько сайтов часто принадлежат одному системному пользователю, и компрометация одного проекта открывает путь к другим. Разделение сайтов по разным пользователям и контейнерам снижает этот риск.
С точки зрения отрасли wp2shell стал напоминанием, что даже зрелые и массовые платформы могут получать критические уязвимости. WordPress существует много лет, имеет огромное сообщество и развитый процесс исправлений, но это не исключает ошибок в сложных механизмах. Масштаб CMS делает каждую критическую проблему особенно опасной, потому что путь от технического отчета до массовой эксплуатации может быть очень коротким.
Главный вывод состоит в том, что wp2shell — это не рядовая проблема отдельного плагина, а критическая цепочка уязвимостей в ядре WordPress, позволяющая удаленное выполнение кода без авторизации. Атакующие уже используют ее для создания администраторов, установки webshell, добавления вредоносных плагинов и закрепления на сайтах. Владельцам WordPress нужно срочно проверить версию ядра, установить исправления 6.9.5 или 7.0.2, удалить неизвестных администраторов и плагины, сменить пароли, salt-ключи и API-токены, проверить файлы, базу данных, cron-задания и логи. Простого обновления может быть недостаточно, если сайт уже был заражен: в таком случае нужна полноценная очистка, восстановление из чистого бэкапа и пересмотр всей модели защиты.