Обзор wp2shell: критическая уязвимость ядра WordPress

Летом 2026 года в самом ядре WordPress нашли опасную цепочку уязвимостей, получившую имя wp2shell. Две ошибки вместе позволяли выполнить код на сервере без авторизации. Исправления вышли в WordPress 6.9.5 и 7.0.2, сайты на поддержке обновились автоматически. Но тема остаётся актуальной: не все сайты обновляются сами, а уязвимость показательна для понимания, как устроены такие атаки. Разбираем по пунктам.

Что такое wp2shell

wp2shell — это не одна уязвимость, а связка двух. Первая — внедрение SQL-запроса без авторизации (CVE-2026-60137) в одном из параметров выборки. Вторая — путаница маршрутов в пакетном методе REST API (CVE-2026-63030). По отдельности каждая опасна, а вместе они дают удалённое выполнение кода.

Название по аналогии с PHP2Shell подчёркивает суть: цепочка приводит к «шеллу» — выполнению команд на сервере.

Кого касается

Сайтов на WordPress версий 6.9.0–6.9.4 и 7.0.0–7.0.1. По одному из разборов, уязвимый путь достижим, когда у сайта нет постоянного объектного кеша, — а это конфигурация по умолчанию у многих. То есть под угрозой были обычные, типовые установки.

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

Как устроена такая цепочка

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

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

Что делать

1. Проверьте версию WordPress: админка → «Консоль» → «Обновления», или внизу любой страницы админки.
2. Обновитесь до 6.9.5, 7.0.2 или новее. Если вы на ветке 6.8 — минимум до 6.8.6 (там закрыта хотя бы SQL-инъекция).
3. Убедитесь, что автоматические обновления безопасности включены.
4. Если сайт долго был на уязвимой версии и доступен из интернета, проверьте журналы и файлы: появились ли посторонние PHP-файлы, новые администраторы.
5. При признаках взлома лечите по плану восстановления и меняйте пароли и ключи.

Плюсы и минусы ситуации

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

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

Вывод: даже у платформы с автообновлениями нельзя полагаться только на автоматику. Нужно знать свою версию и следить за обновлениями самому.

Наше мнение

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

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

Почему WordPress — постоянная цель

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

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