wp2shell: RCE в стандартном WordPress, найденная за десять часов за $25

17 июля 2026 года Searchlight Cyber опубликовала wp2shell — цепочку удаленного выполнения кода, срабатывающую до аутентификации, в ядре WordPress, которая не требует ни плагина, ни темы, ни входа в систему. Достаточно анонимного запроса к стандартной установке: «Атака не имеет предварительных условий, и ее может эксплуатировать анонимный пользователь в стандартной установке WordPress без плагинов», — говорится в рекомендации компании. Цепочка объединяет две уязвимости — CVE-2026-63030, уязвимость путаницы маршрутов в конечной точке пакетной обработки REST API WordPress, которую рекомендация проекта называет критической, и CVE-2026-60137, SQL-инъекцию в параметре author__not_in WP_Query, которую она называет умеренной. WordPress выпустила WordPress 7.0.2 в тот же день, а в рекомендациях проекта WordPress 6.9.5, WordPress 6.8.6 и WordPress 7.1 beta2 указаны как содержащие те же исправления. Searchlight ссылается на оценки, согласно которым число сайтов WordPress превышает 500 миллионов. Исследователь, стоящий за цепочкой, Адам Кьюс, говорит, что она появилась в результате запуска GPT-5.6 Sol Ultra на основе промпта, который OpenAI опубликовала для математической задачи: до четырех агентов, как минимум шесть часов на поиск и еще около четырех на эскалацию, примерно 25 долларов затрат на использование модели. Запись внесена как исследовательская находка — высокая серьезность по собственной шкале архива, достоверность класса A, отсутствие зафиксированного реального ущерба, датирована одним днем — и Orca AI Incident Archive содержит эту запись, а под ней приведены ссылки на первичные документы.

Раскрытие информации было {{1}}скоординированным{{/1}}. 17 июля Searchlight не раскрыла механику и дала защитникам выходные на обновление; Kues опубликовал полное техническое описание 20 июля. К тому времени цепочный эксплойт уже был независимо воспроизведён: по словам Searchlight, Calif и Hacktron воссоздали полную цепочку до того, как на GitHub появились другие доказательства концепции. Две собственные рекомендации WordPress по безопасности указывают одни и те же исправленные версии, а CISA 21 июля добавила обе CVE в свой каталог Known Exploited Vulnerabilities.

Две ошибки и массивы, которые сбиваются с шага

Точка входа — это функциональность, а не ошибка. В 2020 году в WordPress 5.6 появился batch-эндпоинт, чтобы клиент мог отправлять несколько виртуальных REST-запросов в рамках одного HTTP-запроса, например чтобы разом переименовать набор записей. Эндпоинт доступен независимо от того, аутентифицирован ли вызывающий, и каждый подзапрос несёт ту аутентификацию, которую предоставил вызывающий. Прямой запрос к маршруту REST WordPress проходит четырёхэтапный конвейер: проверка обязательных и допустимых параметров, их санитизация, выполнение колбэка проверки разрешений, затем выполнение колбэка эндпоинта. Эндпоинты полагаются на этот конвейер в своих предположениях о типах — что ID записи является целым числом, что заголовок является строкой.

API пакетной обработки разделяет конвейер на два этапа: в одном цикле проверяет каждый подзапрос, а во втором выполняет их, и хранит два массива, $matches и $validation, элементы которых должны соответствовать друг другу по индексу. В class-wp-rest-server.php, как описывает Kues, подзапрос, который сам по себе представляет собой ошибку WordPress, добавляется в $validation, а затем встречает continue, пропуская строку, которая добавляет в $matches. С этого момента каждое совпадение смещается на одну позицию назад. Цикл выполнения сопоставляет подзапрос по одному индексу с проверкой, записанной по этому индексу, но обработчик при этом сопоставлен с другим маршрутом — поэтому параметр проверяется по правилам одного эндпоинта, а затем выполняется кодом другого.

Именно это превращает внешне обычный параметр списка в инъекцию. Маршрут коллекции записей сопоставляет свой публичный author_exclude-аргумент с author__not_in. Когда значение является массивом, WordPress применяет absint к каждому элементу и сортирует их; когда значение является скаляром, оно без изменений конкатенируется в SQL-фрагмент, который становится NOT IN ($author__not_in). Строка вроде 0) OR 1=1 -- поэтому попадает в текст запроса. При обычном вызове маршрут отклонил бы её, потому что author_exclude должен быть массивом целых чисел; именно десинхронизированный пакетный вызов позволяет строке пройти.

Оставались два препятствия, и оба были преодолены за счёт вложенности этого приёма. Пакетный API отклоняет GET-запросы, а инъекция находится на GET-маршруте; кроме того, проверка метода запроса сама реализована как валидация параметров, которую та же десинхронизация может обойти. Опубликованная полезная нагрузка Kues отправляет некорректный внешний подзапрос, чтобы десинхронизировать проверку метода, затем внутренний пакет, второй подзапрос которого несёт вредоносный author_exclude, направленный против обработчика, который его не валидирует, затем GET-запрос, который его выполняет. Инъекция на основе UNION возвращает произвольные значения из базы данных в строках, оформленных как обычные посты.

Запуск модели: математический промпт, нацеленный на кодовую базу

Кюс не писал промпт с нуля. OpenAI опубликовала промпт, который использовала в работе над гипотезой о двойном покрытии циклами (Cycle Double Cover conjecture), и Кюс написал, что читал, будто модель недавно решила эту гипотезу и что никто в сообществе по безопасности, похоже, не обсуждает этот промпт. Его рассуждение было таково: если он достаточно хорош для сложной математики, то, вероятно, достаточно хорош и для исследований в области безопасности. Он адаптировал его и направил на WordPress.

Настройка была намеренно узкой. Он клонировал последний стабильный релиз WordPress в каталог с названием main/ и удалил его каталог .git, сообщив модели, что нельзя использовать журналы изменений, историю git или открытый интернет для сравнения кода с исправленной версией — по его словам, причина в том, что при поиске новых уязвимостей обращение к истории или к интернету — пустая трата токенов. Пустой third_party/ каталог был предложен, чтобы модель могла клонировать зависимости, такие как исходный код PHP или MySQL, если она считала, что цепочке нужны баги в библиотеках, лежащих в основе WordPress. Задача была определена как RCE до аутентификации в типичном производственном развертывании на MySQL, с участием до четырех агентов и как минимум шести часов. Kues писал, что он явно указывает требование к конфигурации, потому что иначе модели «жульничают» — выбирая крайне маловероятные параметры конфигурации или выдумывая предпосылки, которых атакующий никогда не смог бы достичь.

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

Его собственная оценка затрат: 50% недельного лимита использования, что он оценил примерно в $25 пропорционально подписке за $200, за эксплойт, созданный чуть более чем за десять часов. Человеческая часть не была бесплатной — Кус провёл следующий день, разбираясь в том, что сделала модель, и написал, что на понимание работы после эксплуатации у него ушло гораздо больше времени, чем на её генерацию. Его вердикт необычайно резок и строго ограничен: «Я не делаю общих утверждений, но могу с полной уверенностью сказать, что ни один исследователь безопасности не смог бы найти и завершить эту цепочку эксплойтов за 10 часов без ИИ».

От SELECT только для чтения до администратора

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

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

Во-вторых, превратите сфабрикованные записи в реальные строки. Функция встраивания WordPress кэширует разрешённые встраивания в базе данных как записи типа oembed_cache. Встраивание локальной записи по относительному пути, как в [embed]/?p=S[/embed], заставляет WordPress пропускать HTTP-запрос и никогда не проверять, существует ли указанная запись, поэтому создаётся строка. Три таких встраивания с разными токенами в строке запроса создают три разных хэша кэша — именно так злоумышленник получает несколько строк для работы.

В-третьих, обойдите единственное поле, которое остаётся неизменным. Когда версии записи в памяти и в базе данных расходятся, WordPress согласует их с помощью вызова, который явно задаёт post_content из результата встраивания. Всё в записи контролируется злоумышленником, кроме её содержимого — а это как раз то поле, которое customize_changeset использует для хранения JSON ожидающих применения изменений темы и сайта.

Четвёртое — гаджет цикла. У записей есть родители, и WordPress не допускает циклов: wp_insert_post_parent проходит вверх по дереву и, обнаружив петлю, вызывает обновление, которое устанавливает post_parent в ноль. Этот вызов не перезаписывает post_content, поэтому сфабрикованная версия в памяти переживает сверку — changeset с нетронутым JSON, подкреплённый реальной строкой.

Пятый: заимствовать полномочия администратора. Набор изменений, в статусе которого указано, что он запланирован на будущее, но дата которого находится в прошлом, применяется немедленно. Каждая запись в его JSON указывает user_id, а запись в цепочке Kues указывает user_id 1, администратора, поэтому WordPress временно принимает эту идентичность, чтобы применить изменение. Первое изменение — внешне безобидное обновление nav_menus_created_posts.

В-шестых, повторите запрос под этой идентификацией. Публикация записи запускает действие с динамически формируемым именем, {status}_{post_type}. Поскольку запись сфабрикована, значения статуса и типа могут быть любыми — включая parse и request, в результате чего получается parse_request-хук, который перезапускает конвейер обработки запросов с самого начала, пока заимствованная идентификация администратора всё ещё действует. Исходный пакетный запрос содержал подзапрос, создающий нового администратора; при первом проходе как гость он завершился неудачно, а при повторном воспроизведении выполняется успешно. После этого злоумышленник входит в систему под этой новой учётной записью и загружает плагин-бэкдор из ZIP-файла, что приводит к выполнению кода.

У этой техники есть условие. The Hacker News со ссылкой на Cloudflare сообщило, что CVE-2026-63030 приводит к удалённому выполнению кода только тогда, когда постоянный кэш объектов не используется; сама инъекция присутствует начиная с WordPress 6.8, а для полной цепочки требуется версия 6.9 или более поздняя. В стандартной установке постоянный кэш объектов отсутствует, поэтому формулировка Searchlight об «отсутствии предварительных условий» и оговорка Cloudflare описывают один и тот же случай по умолчанию с разных сторон.

Что устанавливают первичные документы

Собственные уведомления безопасности WordPress — самое сильное подтверждение, поскольку это вендор, признающий механику и выпускающий исправление. GHSA-ff9f-jf42-662q, оценённая как критическая, описывает слабость путаницы маршрутов пакетной обработки REST API в WordPress 6.9 и выше, которая в сочетании с инъекцией приводит к выполнению кода, и отмечает вклад Adam Kues из Assetnote и Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, оценённая как умеренная, описывает инъекцию author__not_in начиная с WordPress 6.8 и выше и указывает, что обе проблемы исправлены в WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 и WordPress 7.1 beta2. Записи NVD для двух CVE, оценённые CNA WPScan, а не NIST, имеют 9.8 для CVE-2026-63030 с вектором AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H и 5.9 для CVE-2026-60137 с AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — в первом случае уязвимость, доступная по сети и не требующая привилегий, а во втором — требующая высокой сложности атаки и приводящая только к воздействию на конфиденциальность. Собственное поле серьёзности архива для этой записи указано как high, тогда как WordPress помечает ошибку пакетной обработки как critical; это две отдельные шкалы, применённые ко всей цепочке и к отдельному компоненту, а не разногласие о самих ошибках.

Записи каталога CISA, как они отражены в полях обогащения NVD, были добавлены 21 июля 2026 года со сроками устранения 24 июля для CVE-2026-63030 и 4 августа для CVE-2026-60137. CISA называет первую «Уязвимость конфликта интерпретации в ядре WordPress», а вторую — «Уязвимость SQL-инъекции в ядре WordPress». Searchlight также опубликовал публичный инструмент проверки на wp2shell.com, чтобы операторы могли проверить экземпляр, не ожидая сигнатуры сканера.

Независимое воспроизведение документировано самим Searchlight и, следовательно, является утверждением о третьих сторонах, а не рассказом третьей стороны: согласно публикации от 20 июля, Calif и Hacktron восстановили всю цепочку до того, как на GitHub появились другие доказательства концепции. Независимо проверяемым является эффект — доказательства концепции, трафик эксплуатации и телеметрия вендоров в течение нескольких дней, что описано ниже.

Что утверждается, но не установлено

Две записи о заслугах за одну и ту же инъекцию не согласуются в открытых источниках. В уведомлении WordPress по CVE-2026-60137 указано, что уязвимость «была обнаружена и добросовестно раскрыта командой в составе TF1T, dtro и haongo». Версия Searchlight представляет ту же предаутентификационную инъекцию как то, что выявил её прогон модели, и не упоминает эту команду; уведомление WordPress указывает Kues только в связи с путаницей с пакетным маршрутом и не упоминает модель. Ни один из документов не объясняет это совпадение, и ничто из найденного при подготовке этой статьи его не проясняет: не исключается возможность того, что речь идёт о двух независимых находках одной и той же ошибки, но и возможность того, что один из отчётов представляет собой более позднее повторное обнаружение, тоже не установлена. Публичные материалы этого не разрешают, и данная статья тоже.

Цифра в заголовке публикации Searchlight от 20 июля не подтверждается текстом самой публикации. В заголовке говорится: «Брокеры эксплойтов платят 500 000 долларов за RCE в WordPress. Я нашёл одну с помощью GPT5.6 Sol Ultra и 25 долларов». В тексте конкретно документируются 25 долларов и десять часов; там нет ни имён брокеров, ни предложений, ни переписки, ни источника для цифры в 500 000 долларов. Ни один независимый отчёт, найденный для этого материала, не подтверждает цену, уплаченную или предложенную за wp2shell. Воспринимайте 500 000 долларов как формулировку заголовка, а не как устоявшуюся рыночную цену.

Собственный охват архивной записи уже, чем история вокруг неё. Она фиксирует исследовательскую находку в день раскрытия, не отмечает никакого реального ущерба и датирована одним днём — 17 июля 2026 года. Это не означает, что после этого ничего не произошло: сообщения о трафике эксплуатации появились в течение нескольких часов после выпуска рекомендации, а CISA внесла оба CVE в каталог четыре дня спустя. Эта отметка охватывает то, что описывает запись, — обнаружение и скоординированное раскрытие, — а последующая эксплуатация документируется другими сторонами на основе их собственных данных ниже.

Эксплуатация после публикации рекомендаций

Джейк Нотт, главный исследователь безопасности в watchTowr, рассказал The Hacker News, что «к ранним часам утра субботы (UTC) успешная эксплуатация уже была в полном разгаре: сначала использовался публичный эксплойт-код для эксфильтрации хешированных учетных данных, а после публикации дополнительных сведений последовало удаленное выполнение кода». В том же отчете приводится телеметрия KEVIntel, связывающая 13 уникальных IP-адресов из Швейцарии, Германии, Великобритании, Индонезии, Литвы, Нидерландов и Сингапура с эксплуатацией CVE-2026-63030, и цитируется основатель KEVIntel Райан Дьюхерст, который сказал, что запросы соответствовали общедоступным proof-of-concept и что использовались пейлоады всех типов: слепые, UNION-based и boolean-based.

Исследователи Wiz Шахар Дорфман и Гили Тикочински в публикации от 20 июля оценили масштаб: 60% организаций, использующих WordPress, имели как минимум один уязвимый экземпляр на момент публикации CVE, а 25% оставляли уязвимый сервер доступным из интернета; в течение 24 часов по мере начала установки исправлений эти показатели снизились до 50% и 10%. Они зафиксировали загрузки вредоносных плагинов через установщик в панели администратора, перебор пользователей через эндпоинт users и попытки локального включения файлов в отношении wp-config, а также доступ к панели администратора, возвращавший HTTP 200 — признак успешного входа, а не зондирования. Обнаруженное ими вредоносное ПО охватывало диапазон от минимального однострочного PHP-бэкдора до 150-КБ веб-шелла, замаскированного под легитимный плагин безопасности WordPress под названием CMSmap, с модулями управления файлами, доступа к базе данных, сканирования портов и повышения привилегий.

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

Что изменилось после этого, а что осталось открытым

Для операторов путь реагирования был коротким. Обновление до WordPress 7.0.2, WordPress 6.9.5 или WordPress 6.8.6 — это и есть исправление. Экстренные альтернативы Searchlight для сайтов, которые не могли обновиться сразу, заключались в блокировании анонимного доступа к batch API — либо путём установки плагина, который полностью блокирует анонимный доступ к REST API, либо путём блокировки /wp-json/batch/v1 и ?rest_route=/batch/v1 на веб-прикладном межсетевом экране. Компания предупредила, что оба варианта могут повлиять на законное использование сайта и должны рассматриваться как временные меры до выхода обновления. Публичный чекер на wp2shell.com напрямую проверяет экземпляр. Записи в каталоге CISA добавили срок соответствия: устранение до 24 июля для CVE-2026-63030 и до 4 августа для CVE-2026-60137.

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

Итак, материалы оставляют неустановленным лишь узкий, но значимый круг обстоятельств: кто из двух сторон, которым приписывают открытие, первым обнаружил инъекцию; получал ли какой-либо брокер когда-либо сумму, упомянутую в заголовке; и что — если вообще что-то — веб-шеллы, которые наблюдала Wiz, фактически забрали с сайтов, на которых оказались. По последнему пункту единственное публичное заявление — от Wiz: она не выявила ни бокового перемещения, ни эксфильтрации данных; это отсутствие доказательств с одной точки наблюдения, представленное именно в таком качестве.