WP2Shell в WordPress: как проверить сайт и защититься

Летом 2026 года была обнаружена критическая уязвимость ядра WordPress, получившая название WP2Shell. В отличие от множества атак на WordPress, связанных с уязвимыми плагинами или темами, в данном случае проблема находилась непосредственно в ядре CMS.

Опасность WP2Shell заключается в том, что атака может выполняться без предварительной авторизации. Злоумышленнику не обязательно знать пароль администратора или иметь учётную запись на сайте. При успешной эксплуатации цепочки уязвимостей становится возможным удалённое выполнение кода — RCE (Remote Code Execution).

При этом называть WP2Shell вирусом не совсем правильно. Это уязвимость и способ её эксплуатации. Уже после получения доступа злоумышленник может разместить на сервере webshell, создать скрытого администратора, установить вредоносный плагин или закрепиться на сайте другим способом.

Какие версии WordPress уязвимы

Полная цепочка WP2Shell затрагивает следующие версии WordPress:

• WordPress 6.9.0–6.9.4;
• WordPress 7.0.0–7.0.1.

Исправление полной цепочки появилось в WordPress 6.9.5 и 7.0.2. Поэтому сайты на этих ветках необходимо обновить как минимум до указанных версий или, что предпочтительнее, до более новой актуальной версии WordPress.

В ветке WordPress 6.8 полной цепочки удалённого выполнения кода WP2Shell нет, однако она была затронута связанной SQL-инъекцией. Для неё исправление выпущено в WordPress 6.8.6.

Сам WordPress классифицировал проблему как критическую и после выпуска исправления рекомендовал администраторам обновить сайты незамедлительно.

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

Атака связана с механизмом WordPress REST API, в частности с пакетной обработкой REST-запросов через batch endpoint.

Используемые при атаке адреса могут выглядеть следующим образом:

/wp-json/batch/v1

или:

/?rest_route=/batch/v1

Из-за ошибки маршрутизации запросов злоумышленник мог использовать REST API таким образом, который разработчиками WordPress не предполагался. В сочетании со второй уязвимостью это позволяло сформировать цепочку, заканчивающуюся удалённым выполнением кода.

Важная особенность WP2Shell заключается в том, что для атаки не требуется наличие какого-либо уязвимого плагина. Исследователи подтвердили возможность эксплуатации стандартной установки WordPress.

Почему простого обновления WordPress недостаточно

Первое и главное действие — обновить WordPress. Однако необходимо понимать разницу между устранением уязвимости и устранением последствий взлома.

Обновление закрывает возможность новой эксплуатации WP2Shell, но если злоумышленник успел воспользоваться уязвимостью раньше, на сервере уже могут оставаться:

• PHP-webshell;
• вредоносный плагин;
• изменённые файлы темы;
• дополнительная учётная запись администратора;
• следы атаки в базе данных;
• другие механизмы повторного доступа.

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

Как узнать установленную версию WordPress

Самый простой вариант — открыть административную часть сайта:

Консоль → Обновления

Текущая версия WordPress также может отображаться в нижней части административной панели.

Если имеется доступ к файлам сайта по FTP, версию можно посмотреть в файле:

/wp-includes/version.php

Внутри него необходимо найти строку:

$wp_version = '7.0.1';

При наличии SSH и WP-CLI версию можно получить командой:

wp core version

Как проверить WordPress на WP2Shell без SSH

Для первичной проверки достаточно обычного доступа по FTP или SFTP. Особенно внимательно следует изучить файлы, появившиеся или изменённые после публикации уязвимости летом 2026 года.

1. Проверяем wp-content/uploads

В первую очередь следует открыть:

/wp-content/uploads/

Это особенно важный каталог, потому что WordPress обычно имеет право записи в него даже на серверах, где изменение файлов ядра, плагинов и тем запрещено.

Внутри uploads обычно находятся изображения, документы и другие загруженные через сайт файлы:

.jpg .jpeg .png .webp .gif .svg .pdf .doc .docx

Наличие PHP-файла требует отдельной проверки. Следует искать расширения:

.php .phtml .php5 .php7 .phar

Например, подозрительно будут выглядеть:

/wp-content/uploads/2026/07/cache.php /wp-content/uploads/2026/08/shell.php /wp-content/uploads/tmp/index.php

Это не означает, что любой файл index.php обязательно вредоносный. Некоторые плагины создают небольшие index.php для защиты каталогов. Поэтому подозрительный файл сначала необходимо скачать и изучить, а не удалять вслепую.

2. Проверяем установленные плагины

Следующий каталог:

/wp-content/plugins/

Список находящихся в нём папок желательно сравнить со списком плагинов в административной панели:

Плагины → Установленные плагины

Особое внимание следует обратить на неизвестные каталоги и недавно появившиеся файлы.

Публичные инструменты эксплуатации WP2Shell могли создавать каталоги с именами вида:

wp2shell_xxxxxxxx

Однако ориентироваться только на название нельзя. Реальный злоумышленник может назвать вредоносный плагин как угодно и замаскировать его под обычный системный компонент.

3. Проверяем каталог upgrade

Также следует открыть:

/wp-content/upgrade/

WordPress использует эту директорию для временных файлов при обновлении. После нормального завершения обновлений в ней обычно не должно оставаться непонятных PHP-файлов и неизвестных каталогов.

4. Проверяем cache

Если существует каталог:

/wp-content/cache/

его также необходимо изучить. Злоумышленник не обязан размещать webshell непосредственно в каталоге plugins. Для закрепления может использоваться любое доступное для записи место.

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

5. Проверяем mu-plugins

Проверяем:

/wp-content/mu-plugins/

MU Plugins загружаются WordPress автоматически и поэтому представляют интерес для злоумышленника как механизм закрепления.

Если владелец сайта никогда не устанавливал обязательные плагины, а внутри директории неожиданно появились PHP-файлы, необходимо выяснить их происхождение.

6. Проверяем темы

Необходимо изучить:

/wp-content/themes/

Особенно активную тему сайта. Стоит обратить внимание на неожиданно изменившиеся файлы:

functions.php header.php footer.php

Если тема несколько месяцев не обновлялась, но один из её PHP-файлов получил свежую дату изменения, необходимо проверить его содержимое.

7. Проверяем корневой каталог WordPress

В корне обычной установки WordPress находятся стандартные файлы:

index.php wp-activate.php wp-blog-header.php wp-comments-post.php wp-config.php wp-cron.php wp-links-opml.php wp-load.php wp-login.php wp-mail.php wp-settings.php wp-signup.php wp-trackback.php xmlrpc.php

Появление неизвестных файлов вроде:

shell.php wp-old.php wp-admin1.php class-old.php 1.php x.php

является поводом для проверки.

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

Что искать внутри подозрительного PHP-файла

Webshell и другой вредоносный PHP-код часто стараются скрыть. Стоит обратить внимание на длинные нечитаемые строки и использование функций:

eval() base64_decode() gzinflate() gzuncompress() shell_exec() system() passthru()

Например, сочетание нескольких функций декодирования и последующего выполнения результата является поводом для детальной проверки.

При этом наличие одной функции base64_decode() ещё не доказывает заражение: она встречается и в легитимных плагинах.

Проверяем пользователей WordPress

После файлов обязательно следует проверить:

Пользователи → Все пользователи

Особенно внимательно просматриваем пользователей с ролью Администратор.

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

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

Специализированная проверка WP2Shell

В официальном каталоге плагинов WordPress появился специализированный инструмент Compromise Scanner for wp2shell.

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

Сканер анализирует, в частности:

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

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

Стоит ли полностью отключать REST API

После появления WP2Shell возникает закономерный вопрос: зачем вообще оставлять REST API доступным?

Полностью отключать REST API на современном WordPress обычно не рекомендуется. Его используют административная часть WordPress, редактор блоков и различные плагины. Полное отключение может привести к появлению трудно диагностируемых ошибок.

Однако можно запретить использование REST API неавторизованным пользователям.

Для этого WordPress предоставляет фильтр rest_authentication_errors. Например:

<?php add_filter( 'rest_authentication_errors', function( $result ) { if ( true === $result || is_wp_error( $result ) ) { return $result; } if ( ! is_user_logged_in() ) { return new WP_Error( 'rest_not_logged_in', 'REST API доступен только авторизованным пользователям.', array( 'status' => 401 ) ); } return $result; }); 

В таком случае авторизованные пользователи WordPress смогут продолжать работать с REST API, а анонимные внешние запросы будут отклоняться.

Перед установкой подобного ограничения необходимо убедиться, что сайт не использует публичный REST API для внешних интеграций, мобильных приложений, форм, каталога, WooCommerce или других функций.

Можно ли заблокировать только batch API

Да. До установки исправления исследователи WP2Shell рекомендовали в качестве временной защитной меры блокировать анонимный доступ именно к batch endpoint:

/wp-json/batch/v1 /?rest_route=/batch/v1

Например, для nginx возможно правило:

location ~* ^/wp-json/batch/v1 { deny all; }

Аналогичную блокировку можно реализовать через WAF.

Важно: это дополнительная или временная мера, но не замена обновлению WordPress. После выхода исправленной версии основной способ устранения WP2Shell — обновление ядра.

Запрещаем выполнение PHP в uploads

Есть ещё одна полезная мера защиты WordPress, не связанная исключительно с WP2Shell.

Каталог:

/wp-content/uploads/

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

Для Apache можно использовать правило в файле .htaccess внутри uploads:

<FilesMatch "\.(php|php[0-9]|phtml|phar)$"> Require all denied </FilesMatch>

Для nginx запрет может выглядеть следующим образом:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }

Это не устраняет уязвимости WordPress, но мешает злоумышленнику превратить записанный в uploads PHP-файл в доступный через браузер webshell.

Не нужно давать WordPress права 777

Иногда при обновлении WordPress запрашивает FTP-доступ, поскольку PHP-процесс не имеет разрешения изменять файлы ядра, плагинов или тем.

Попытка решить эту проблему командой вида:

chmod -R 777

является плохой идеей.

Если PHP не имеет права перезаписывать ядро WordPress, плагины и темы, это может быть дополнительной защитой при успешной эксплуатации RCE.

На подобных серверах безопаснее обновлять WordPress через FTP/SFTP или правильно настроить владельцев и разрешения файлов, чем открывать всему сайту максимально широкие права записи.

При использовании FTP предпочтительно создавать отдельную учётную запись только для каталога конкретного сайта и использовать защищённое соединение SFTP или SFTP, если оно поддерживается хостингом.

Проверяем журналы доступа

Если хостинг предоставляет access.log, стоит проверить обращения к:

/wp-json/batch/v1

и запросы с:

?rest_route=/batch/v1

Сам факт такого обращения ещё не доказывает взлом. После публикации критической уязвимости сайты автоматически сканируют многочисленные боты.

Более подозрительной является последовательность событий: запросы к batch API, после которых с того же IP начинаются обращения к административной части, загрузке плагинов или новым PHP-файлам.

Следует учитывать и ограничение обычных access.log: тело POST-запроса веб-сервер, как правило, полностью не сохраняет. Поэтому часть действий WP2Shell может быть видна только косвенно по файлам, базе данных и другим журналам.

Что делать владельцу WordPress-сайта

Оптимальный порядок действий выглядит следующим образом:

1. Создать резервную копию файлов сайта и базы данных.
2. Обновить WordPress до исправленной актуальной версии.
3. Проверить список администраторов.
4. Проверить wp-content/uploads на PHP-файлы.
5. Проверить plugins, themes, cache, upgrade и mu-plugins.
6. Изучить недавно изменённые PHP-файлы.
7. Проверить access.log на обращения к REST batch API.
8. По возможности выполнить специализированную проверку следов WP2Shell.
9. Запретить выполнение PHP внутри uploads.
10. При необходимости ограничить анонимный REST API.

Что делать, если обнаружен подозрительный файл

Не стоит сразу удалять найденный файл. Сначала его желательно скачать и сохранить вместе с информацией о дате изменения и расположении.

Если заражение подтверждается, одного удаления webshell обычно недостаточно. Необходимо выяснить, каким способом злоумышленник получил доступ и не оставил ли другие механизмы закрепления.

После подтверждённого взлома рекомендуется сменить:

• пароли администраторов WordPress;
• пароли FTP/SFTP;
• пароль базы данных;
• ключи и соли WordPress;
• пароли панели управления хостингом, если существует вероятность их компрометации.

Также следует повторно проверить файлы ядра, плагины, темы и пользователей.

WP2Shell — один из тех случаев, когда правило «у меня нет сомнительных плагинов, значит WordPress защищён» не работает. Уязвимость находилась непосредственно в ядре CMS и могла эксплуатироваться до авторизации пользователя.

Главная защита — своевременное обновление WordPress. Но если сайт хотя бы некоторое время был доступен из Интернета на уязвимой версии, разумно не ограничиваться обновлением, а проверить возможные последствия эксплуатации.

Особое внимание стоит уделить каталогам uploads, plugins, cache и themes, неизвестным администраторам, недавно изменённым PHP-файлам и обращениям к REST batch API.

А дополнительные меры — ограничение прав на запись, запрет выполнения PHP в uploads и контроль анонимного доступа к REST API — способны значительно уменьшить последствия не только WP2Shell, но и многих будущих уязвимостей WordPress.