Критическая уязвимость WordPress wp2shell: почему сайту вашего бизнеса нужна проверка прямо сейчас

В середине июля 2026 года команда безопасности WordPress выпустила экстренные обновления ядра системы, закрывающие связку из двух критических уязвимостей — их уже окрестили wp2shell. Патч вышел 17 июля, а уже на следующий день специалисты по кибербезопасности зафиксировали первые попытки атак с использованием публичного эксплойта. Для владельцев сайтов на WordPress, а таких в Узбекистане — тысячи, от интернет-магазинов до корпоративных блогов, это повод не откладывать проверку до понедельника, а сделать её сегодня.

Что произошло: связка CVE-2026-60137 и CVE-2026-63030

Речь идёт о двух уязвимостях, которые по отдельности опасны, а вместе — критичны. Первая, CVE-2026-60137, — это неавторизованная SQL-инъекция в одном из базовых механизмов ядра WordPress. Вторая, CVE-2026-63030, позволяет злоумышленнику, уже получившему доступ через первую брешь, удалённо выполнить произвольный код на сервере без какой-либо аутентификации.

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

Разработчики оценили серьёзность проблемы настолько высоко, что распространили патч не только через обычный механизм обновлений, но и принудительно — через встроенную систему автоматических обновлений безопасности, которая обычно применяется только к самым опасным брешам. Исправления вошли в версии 6.8.6, 6.9.5 и 7.0.2.

Почему это касается и вашего сайта

WordPress остаётся самой распространённой CMS в мире, и Узбекистан не исключение: на нём строят лендинги, интернет-магазины, корпоративные сайты и блоги компании самого разного масштаба. Логика «у нас маленький сайт, кому он нужен» здесь не работает — автоматизированные сканеры ищут уязвимые версии не выборочно, а массово, перебирая миллионы доменов подряд. Взломанный сайт используют для рассылки спама, размещения фишинговых страниц, майнинга или как плацдарм для атак на другие ресурсы в той же сети хостинга.

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

Как понять, что сайт под угрозой

Проверка занимает несколько минут, но требует последовательности:

• Узнайте версию ядра. В админ-панели WordPress она указывается на странице «Обновления» или в разделе «Информация о сайте». Если версия ниже 6.8.6 (для веток 6.8.x), 6.9.5 (для 6.9.x) или 7.0.2 (для 7.0.x) — сайт уязвим.
• Проверьте, включены ли автообновления безопасности. По умолчанию WordPress обновляет минорные версии автоматически, но на части сайтов эта функция отключена вручную из-за прошлого опыта конфликтов с плагинами.
• Посмотрите логи сервера на аномалии. Массовые POST-запросы к нетипичным адресам, неизвестные файлы в директории wp-content/uploads или новые администраторские аккаунты — признаки того, что эксплойт уже применялся.
• Если используете хостинг с управляемым WordPress — уточните у провайдера, применил ли он патч централизованно на уровне платформы.

Что делать прямо сейчас

Порядок действий здесь простой, но каждый шаг важен:

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

А если сайт работает не на WordPress

История с wp2shell — хороший повод пересмотреть отношение к безопасности CMS в целом, независимо от платформы. Для сайтов на 1С-Битрикс действует похожая логика: своевременное обновление ядра и модулей, отслеживание бюллетеней безопасности вендора и ограничение прав доступа снижают риск на порядок эффективнее, чем любые точечные меры постфактум. У 1С-Битрикс есть встроенный «Проактивный фильтр» и модуль контроля целостности, которые стоит держать включёнными постоянно, а не только после громких новостей об очередной уязвимости.

Общее правило для любой CMS — WordPress, 1С-Битрикс или иной платформы — звучит одинаково: обновления ядра и расширений должны применяться в течение дней, а не недель после выхода патча безопасности, особенно если он вышел вне обычного графика релизов. Именно внеплановый, срочный характер обновления обычно и сигнализирует о критичности проблемы.

Как выстроить процесс, а не тушить пожары

Каждая громкая уязвимость вроде wp2shell вскрывает одну и ту же проблему: у многих сайтов просто нет владельца процесса обновлений. Сайт когда-то заказали, сдали в эксплуатацию — и с тех пор к нему никто системно не возвращался, кроме редких правок контента. В такой модели любое критическое обновление обнаруживается случайно, через новости или, что хуже, через факт взлома.

Рабочая альтернатива — регулярный регламент, а не разовые авралы:

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

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

Итог

Связка уязвимостей wp2shell — CVE-2026-60137 и CVE-2026-63030 — затрагивает базовую конфигурацию WordPress независимо от установленных плагинов и уже активно эксплуатируется в реальных атаках. Патч вышел 17 июля 2026 года в версиях 6.8.6, 6.9.5 и 7.0.2, и его установка должна стать первоочередной задачей для владельцев любого сайта на этой платформе. Проверка версии ядра, обновление плагинов, резервное копирование и смена паролей — минимальный набор шагов, который стоит выполнить в течение ближайших дней. А для бизнеса это ещё и напоминание: безопасность CMS — будь то WordPress или 1С-Битрикс — работает только тогда, когда обновления применяются регулярно, а не после того, как уязвимость уже попала в новости.