Через три дня после раскрытия двух критических багов атаки на уязвимости WordPress уже пошли в промышленных масштабах. Связка CVE-2026-60137 и CVE-2026-63030 позволяет удаленно захватить сайт без логина и пароля, а для русскоязычной IT-аудитории это плохая, но очень знакомая новость: если WordPress стоит где-то «на маркетинг», «на спецпроект» или «у подрядчика», проблема вполне может жить уже внутри вашего периметра.
О новой цепочке атак WP2Shell сообщает Dark Reading. Речь идет о двух уязвимостях в WordPress Core, которые по отдельности выглядят неприятно, но не апокалиптично, а вместе превращаются в прямой путь к удаленному выполнению кода. Первая, CVE-2026-60137, это SQL-инъекция, позволяющая вмешиваться в запросы к базе и получать доступ к данным, которые наружу выходить не должны. Вторая, CVE-2026-63030, логическая ошибка в Batch REST API WordPress, где можно объединять несколько запросов в один вызов. Проблема возникла из-за расхождения между тем, как batch-эндпоинт валидирует запросы, и тем, как потом их исполняет. На практике это дает атакующему возможность провести вредоносный запрос мимо проверок, для которых обычно нужна авторизация.
Ключевой момент в том, что в цепочке эти баги снимают сразу несколько стандартных барьеров. Атакующему не нужен украденный пароль, не нужен фишинг пользователя, не нужен дырявый плагин: достаточно анонимного запроса к стандартной установке WordPress. Исследователи из Searchlight Cyber нашли обе уязвимости при помощи GPT-5.6 Sol Ultra и назвали связку WP2Shell. По их оценке, на поиск багов и сборку рабочего exploit chain ушло около 10 часов. Это не просто красивая история про AI в security, а довольно приземленная демонстрация того, как резко сокращается путь от исследования до готового оружия. Для защитников это означает, что окно между disclosure и массовой эксплуатацией снова сжалось, только теперь еще сильнее.
Масштаб истории объясняется просто: затронуты версии WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1, а значит речь идет о десятках, а потенциально и о сотнях миллионов сайтов с конфигурацией по умолчанию. WordPress выпустил исправление 17 июля 2026 года и из-за серьезности проблемы включил принудительные обновления через систему auto-update для уязвимых инсталляций. Но патч сам по себе не гарантирует спокойную жизнь. Джейк Нотт из watchTowr прямо говорит: если сайт был уязвим, его уже нужно не только обновлять, но и проверять на новые администраторские учетные записи, вредоносные плагины и подозрительные файлы. Логика тут жесткая, но честная: когда эксплойты разлетаются за считаные часы, часть компрометаций происходит раньше, чем у владельца сайта вообще появляется шанс дочитать advisory до конца.
По данным VulnCheck, к воскресенью, 19 июля, исследователи подтвердили более двух десятков уникальных proof-of-concept-эксплойтов для WP2Shell. watchTowr, которая следила за активностью через сеть honeypot-систем с пятницы, зафиксировала, что уже к раннему утру субботы по UTC злоумышленники вовсю использовали публичный код: сначала вытаскивали хешированные учетные данные, а затем переходили к удаленному выполнению кода, когда появились дополнительные технические детали. На своих ловушках компания увидела десятки тысяч попыток эксплуатации и более 100 бэкдор-аккаунтов, созданных разными группами с вариациями общедоступных инструментов. Атаки при этом были не точечными, а оппортунистическими: под раздачу попадали организации любого размера и из любых отраслей. После создания скрытого админского аккаунта атакующие ставили поддельные WordPress-плагины, чтобы закрепиться, вытянуть креды и секреты или скачать дополнительный инструментарий. В одном из случаев наблюдали попытки загрузить Overlord RAT, троян удаленного доступа на Go.
Для тех, кто отвечает не только за безопасность, но и за деньги, здесь неприятен не сам факт еще одной RCE-истории, а ее операционная простота. Патрик Манч, chief security officer в Mondoo, формулирует это без лишней драматургии: SQL-инъекция дает доступ к базе WordPress, RCE отдает уже весь сервер. Вместе получается не утечка в вакууме, а полноценный web shell на хосте. Для бизнеса это означает совсем другой класс последствий: компрометация контента, кража секретов из конфигов, установка малвари, использование сайта как узла для дальнейших атак и, в случае общего хостинга или слабой сегментации, движение дальше по инфраструктуре. Для разработчиков и DevOps-команд вывод тоже неприятно прямой: WordPress больше нельзя считать чем-то второстепенным, что живет рядом с «настоящими» системами. Если он подключен к SSO, почте, аналитике, CRM, CDN, платежам или внутренним API, то у вас уже не «маркетинговый сайт», а вполне рабочая точка входа.
Отдельный контекст здесь в том, как меняется экономика атак. Еще недавно массовая эксплуатация крупных багов шла по понятному сценарию: disclosure, публикация PoC, первые сканеры, потом аккуратное наращивание темпа. В случае с WP2Shell этот конвейер выглядит еще более автоматизированным. Как только детали становятся публичными, frontier-модели помогают исследователям и злоумышленникам воспроизводить цепочки почти с ходу. В watchTowr прямо отмечают, что CVE-2026-63030 удалось воспроизвести за минуты после раскрытия, а CVE-2026-60137 потребовала лишь чуть больше усилий. Для рынка это плохой сигнал: защитные процессы, рассчитанные на несколько спокойных дней между disclosure и реальной волной атак, начинают морально устаревать.
История WP2Shell вряд ли останется разовой аномалией. Скорее это очередной маркер того, что уязвимости WordPress и других массовых платформ теперь будут переходить из отчета исследователя в массовую эксплуатацию почти без паузы, а спор о пользе AI для offensive security уже закрывается практикой. Вопрос для команд теперь не в том, можно ли успеть поставить патч, а в том, успевают ли их процессы за миром, где между публикацией бага и компрометацией проходит не неделя, а одна рабочая смена.