18 июля 2026 года история с двумя уязвимостями в ядре WordPress получила финальные штрихи: обеим присвоили официальные CVE-номера, механизм атаки полностью раскрыли, а на GitHub уже лежит рабочий proof-of-concept. Суть проста и неприятна одновременно — анонимный HTTP-запрос без какой-либо авторизации способен привести к удалённому выполнению кода на сайте. И это не баг какого-то плагина от третьей стороны, а дыра в самом ядре движка. То есть чистая установка WordPress, без единого плагина, оказалась уязвима. Пострадали все сайты на версиях 6.9 и 7.0 — до тех пор, пока не вышли патчи.
Связку из двух уязвимостей исследователи окрестили wp2shell. Первая — CVE-2026-63030, путаница в обработке батч-запросов REST API. Вторая — CVE-2026-60137, классическая SQL-инъекция в ядре. По отдельности каждая по-своему неприятна, но вместе они дают злоумышленнику полный контроль: анонимный запрос эскалируется до выполнения произвольного кода.
Нашёл первую брешь Adam Kues из Assetnote — подразделения Searchlight Cyber, занимающегося управлением поверхностью атаки. Отчёт он подал через программу HackerOne, которую ведёт сама команда WordPress. В своём материале, опубликованном под именем wp2shell, Kues написал прямо: атака «не требует никаких предварительных условий и может быть выполнена анонимным пользователем». SQL-инъекцию нашли независимо трое других исследователей — TF1T, dtro и haongo. Любопытно, что Searchlight Cyber решила придержать собственный технический разбор — вместо этого компания направила владельцев сайтов на чекер по адресу . Но сдержанность одной команды ничего не решила: другие исследователи прочитали публичный патч WordPress, восстановили полную механику атаки и выложили рабочий эксплойт на GitHub — в течение суток после релиза исправления.
Патчи вышли в пятницу: версии 6.9.5 и 7.0.2. WordPress включил принудительное автообновление через собственную систему, чтобы протолкнуть фиксы максимально широко. Обе правки уже вошли и в бета-версию 7.1 (beta2). При этом картина по версиям неоднородная. Ветка 6.8.0–6.8.5 несла только SQL-инъекцию без цепочки для RCE, и патч 6.8.6 закрыл именно её. А вот версии 6.9.0–6.9.4 и 7.0.0–7.0.1 содержали полную цепочку удалённого выполнения кода, закрытую в 6.9.5 и 7.0.2 соответственно. Дело в том, что путаница в батч-маршрутах, которая и открывает путь к RCE без авторизации, появилась только начиная с 6.9 — сама по себе версия 6.8 для этой атаки не пригодна. WordPress 6.9 вышла 2 декабря 2025 года, то есть все сайты с риском RCE работали на релизе младше восьми месяцев. Отдельная неприятность: WordPress так и не прояснил, доходит ли принудительное обновление до сайтов, где автообновления были заранее отключены владельцем. Так что проверять фактически установленную версию стоит вручную, не полагаясь на предположение, что патч прилетел сам.
Механика атаки распадается на две части. Корень SQL-инъекции — в параметре author__not_in внутри WP_Query: если вместо ожидаемого массива передать строку, проверка типов не срабатывает, и необработанные значения попадают прямиком в SQL-запрос. Вторая часть — путаница в маршруте /wp-json/batch/v1, который умеет обрабатывать сразу несколько под-запросов за один вызов, отслеживая их с помощью двух параллельных массивов. Ошибка в одном из под-запросов сдвигает эти массивы друг относительно друга на одну позицию — и в результате запрос обрабатывается под правами и обработчиком совсем другого запроса. Соединив эти две вещи, атакующий обходит список разрешённых действий на эндпоинте и протаскивает контролируемые им данные прямо в уязвимый SQL-запрос — без единой формы авторизации. Сам батч-эндпоинт существует с версии 5.6, вышедшей ещё в 2020 году, а вот эксплуатируемая путаница в нём — новинка версии 6.9.
Отдельного внимания заслуживает расхождение в оценках серьёзности проблемы. Собственный бюллетень WordPress называет цепочку RCE критической. Но в официальной записи CVE эта же уязвимость получила всего 7.5 балла — то есть «высокий», а не «критический» уровень. Дело в методике: оценка учитывает только доступ к данным, но не потерю целостности и доступности, которые логично было бы ожидать от полноценного выполнения кода. При этом сама SQL-инъекция как отдельная уязвимость оценена выше 9.1 балла — то есть формально «критичнее», чем связка, приводящая к захвату сайта целиком. Получается парадокс: баг, который WordPress называет критическим RCE, по системе CVSS выглядит менее опасным, чем его составная часть. Разумный подход — отслеживать оба CVE по отдельности, не полагаясь ни на один из ярлыков.
Есть и смягчающий фактор. По данным Cloudflare, которая одновременно с раскрытием выпустила правила для своего WAF, путь к выполнению кода работает только тогда, когда на сайте отсутствует персистентный объектный кеш. Проблема в том, что стандартная установка WordPress такого кеша не имеет — то есть риск для конфигурации «из коробки» остаётся полным. Сайты, использующие Redis или Memcached в качестве персистентного кеша, могут оказаться защищены от этого конкретного пути RCE — но это побочный эффект, а не официальное исправление, и от SQL-инъекции он не спасает вовсе.
На стороне детектирования готовится помощь: Rapid7 обещает добавить аутентифицированные проверки в InsightVM и Nexpose к 20 июля. Пока уязвимость не попала в каталог CISA KEV, который требует подтверждённых случаев эксплуатации — на 18 июля данных об активных атаках не поступало. Но контекст стоит держать в голове: массовая эксплуатация WordPress-сайтов — давно известный паттерн отрасли. До того как в июне её сервер был раскрыт и выведен из строя, группировка WP-SHELLSTORM успела скомпрометировать, по собственным заявлениям, свыше 17 000 сайтов через уязвимость в кеширующем плагине — уже известную, уже пропатченную и эксплуатируемую лишь при нестандартной конфигурации. wp2shell отличается тем, что публичен, пропатчен и при этом эксплуатируется при настройках по умолчанию — а значит, потенциальный масштаб риска выше.
Для тех, кто пока не может обновиться, предлагается несколько временных мер — все они прямо названы затычками и способны сломать легитимные интеграции. Первая — правило в WAF, блокирующее одновременно /wp-json/batch/v1 и rest_route=/batch/v1: блокировать нужно оба варианта, иначе прикрытие только пути /wp-json оставляет открытым доступ через строку запроса. Управляемый WAF от Cloudflare уже блокирует эту цепочку автоматически для сайтов, стоящих за ним. Вторая мера — полностью отключить REST API, что убивает любой неавторизованный доступ через него. Третья — установить короткий плагин-заглушку, опубликованный Searchlight, который отклоняет анонимные запросы к /batch/v1 на хуке rest_pre_dispatch.
В посте Searchlight фигурирует цифра свыше 500 миллионов сайтов на WordPress по всему миру — но это общая база установок, а не число реально уязвимых ресурсов. Круг сайтов с риском RCE ограничен теми, кто работает на версии 6.9 и выше, вышедшей 2 декабря 2025 года, и ни один из бюллетеней не назвал точное число затронутых площадок.
Поскольку код WordPress открыт, а в примечаниях к релизу были прямо названы изменённые файлы, раскрытие механизма бага стало практически неизбежным в тот момент, когда патч вышел в публичный доступ. Даже решение Searchlight придержать собственный подробный разбор ничего не изменило: другие исследователи восстановили логику атаки по диффу патча в течение суток и выложили рабочий эксплойт на GitHub. Отсюда вывод, который трудно оспорить: выпустить исправление безопасности, не раскрыв при этом саму уязвимость через сам патч, попросту невозможно. Единственная реальная защита — скорость внедрения патча против скорости разведки со стороны атакующих. По сути, дальше начинается гонка двух показателей: статистики обновления версий WordPress (сколько сайтов реально пропатчилось) против сканирующего трафика, направленного на /batch/v1 (сколько атакующих прощупывают эту брешь). Какой из трендов окажется быстрее, и определит, как эту историю будут вспоминать.
Связку из двух уязвимостей исследователи окрестили wp2shell. Первая — CVE-2026-63030, путаница в обработке батч-запросов REST API. Вторая — CVE-2026-60137, классическая SQL-инъекция в ядре. По отдельности каждая по-своему неприятна, но вместе они дают злоумышленнику полный контроль: анонимный запрос эскалируется до выполнения произвольного кода.
Нашёл первую брешь Adam Kues из Assetnote — подразделения Searchlight Cyber, занимающегося управлением поверхностью атаки. Отчёт он подал через программу HackerOne, которую ведёт сама команда WordPress. В своём материале, опубликованном под именем wp2shell, Kues написал прямо: атака «не требует никаких предварительных условий и может быть выполнена анонимным пользователем». SQL-инъекцию нашли независимо трое других исследователей — TF1T, dtro и haongo. Любопытно, что Searchlight Cyber решила придержать собственный технический разбор — вместо этого компания направила владельцев сайтов на чекер по адресу . Но сдержанность одной команды ничего не решила: другие исследователи прочитали публичный патч WordPress, восстановили полную механику атаки и выложили рабочий эксплойт на GitHub — в течение суток после релиза исправления.
Патчи вышли в пятницу: версии 6.9.5 и 7.0.2. WordPress включил принудительное автообновление через собственную систему, чтобы протолкнуть фиксы максимально широко. Обе правки уже вошли и в бета-версию 7.1 (beta2). При этом картина по версиям неоднородная. Ветка 6.8.0–6.8.5 несла только SQL-инъекцию без цепочки для RCE, и патч 6.8.6 закрыл именно её. А вот версии 6.9.0–6.9.4 и 7.0.0–7.0.1 содержали полную цепочку удалённого выполнения кода, закрытую в 6.9.5 и 7.0.2 соответственно. Дело в том, что путаница в батч-маршрутах, которая и открывает путь к RCE без авторизации, появилась только начиная с 6.9 — сама по себе версия 6.8 для этой атаки не пригодна. WordPress 6.9 вышла 2 декабря 2025 года, то есть все сайты с риском RCE работали на релизе младше восьми месяцев. Отдельная неприятность: WordPress так и не прояснил, доходит ли принудительное обновление до сайтов, где автообновления были заранее отключены владельцем. Так что проверять фактически установленную версию стоит вручную, не полагаясь на предположение, что патч прилетел сам.
Механика атаки распадается на две части. Корень SQL-инъекции — в параметре author__not_in внутри WP_Query: если вместо ожидаемого массива передать строку, проверка типов не срабатывает, и необработанные значения попадают прямиком в SQL-запрос. Вторая часть — путаница в маршруте /wp-json/batch/v1, который умеет обрабатывать сразу несколько под-запросов за один вызов, отслеживая их с помощью двух параллельных массивов. Ошибка в одном из под-запросов сдвигает эти массивы друг относительно друга на одну позицию — и в результате запрос обрабатывается под правами и обработчиком совсем другого запроса. Соединив эти две вещи, атакующий обходит список разрешённых действий на эндпоинте и протаскивает контролируемые им данные прямо в уязвимый SQL-запрос — без единой формы авторизации. Сам батч-эндпоинт существует с версии 5.6, вышедшей ещё в 2020 году, а вот эксплуатируемая путаница в нём — новинка версии 6.9.
Отдельного внимания заслуживает расхождение в оценках серьёзности проблемы. Собственный бюллетень WordPress называет цепочку RCE критической. Но в официальной записи CVE эта же уязвимость получила всего 7.5 балла — то есть «высокий», а не «критический» уровень. Дело в методике: оценка учитывает только доступ к данным, но не потерю целостности и доступности, которые логично было бы ожидать от полноценного выполнения кода. При этом сама SQL-инъекция как отдельная уязвимость оценена выше 9.1 балла — то есть формально «критичнее», чем связка, приводящая к захвату сайта целиком. Получается парадокс: баг, который WordPress называет критическим RCE, по системе CVSS выглядит менее опасным, чем его составная часть. Разумный подход — отслеживать оба CVE по отдельности, не полагаясь ни на один из ярлыков.
Есть и смягчающий фактор. По данным Cloudflare, которая одновременно с раскрытием выпустила правила для своего WAF, путь к выполнению кода работает только тогда, когда на сайте отсутствует персистентный объектный кеш. Проблема в том, что стандартная установка WordPress такого кеша не имеет — то есть риск для конфигурации «из коробки» остаётся полным. Сайты, использующие Redis или Memcached в качестве персистентного кеша, могут оказаться защищены от этого конкретного пути RCE — но это побочный эффект, а не официальное исправление, и от SQL-инъекции он не спасает вовсе.
На стороне детектирования готовится помощь: Rapid7 обещает добавить аутентифицированные проверки в InsightVM и Nexpose к 20 июля. Пока уязвимость не попала в каталог CISA KEV, который требует подтверждённых случаев эксплуатации — на 18 июля данных об активных атаках не поступало. Но контекст стоит держать в голове: массовая эксплуатация WordPress-сайтов — давно известный паттерн отрасли. До того как в июне её сервер был раскрыт и выведен из строя, группировка WP-SHELLSTORM успела скомпрометировать, по собственным заявлениям, свыше 17 000 сайтов через уязвимость в кеширующем плагине — уже известную, уже пропатченную и эксплуатируемую лишь при нестандартной конфигурации. wp2shell отличается тем, что публичен, пропатчен и при этом эксплуатируется при настройках по умолчанию — а значит, потенциальный масштаб риска выше.
Для тех, кто пока не может обновиться, предлагается несколько временных мер — все они прямо названы затычками и способны сломать легитимные интеграции. Первая — правило в WAF, блокирующее одновременно /wp-json/batch/v1 и rest_route=/batch/v1: блокировать нужно оба варианта, иначе прикрытие только пути /wp-json оставляет открытым доступ через строку запроса. Управляемый WAF от Cloudflare уже блокирует эту цепочку автоматически для сайтов, стоящих за ним. Вторая мера — полностью отключить REST API, что убивает любой неавторизованный доступ через него. Третья — установить короткий плагин-заглушку, опубликованный Searchlight, который отклоняет анонимные запросы к /batch/v1 на хуке rest_pre_dispatch.
В посте Searchlight фигурирует цифра свыше 500 миллионов сайтов на WordPress по всему миру — но это общая база установок, а не число реально уязвимых ресурсов. Круг сайтов с риском RCE ограничен теми, кто работает на версии 6.9 и выше, вышедшей 2 декабря 2025 года, и ни один из бюллетеней не назвал точное число затронутых площадок.
Поскольку код WordPress открыт, а в примечаниях к релизу были прямо названы изменённые файлы, раскрытие механизма бага стало практически неизбежным в тот момент, когда патч вышел в публичный доступ. Даже решение Searchlight придержать собственный подробный разбор ничего не изменило: другие исследователи восстановили логику атаки по диффу патча в течение суток и выложили рабочий эксплойт на GitHub. Отсюда вывод, который трудно оспорить: выпустить исправление безопасности, не раскрыв при этом саму уязвимость через сам патч, попросту невозможно. Единственная реальная защита — скорость внедрения патча против скорости разведки со стороны атакующих. По сути, дальше начинается гонка двух показателей: статистики обновления версий WordPress (сколько сайтов реально пропатчилось) против сканирующего трафика, направленного на /batch/v1 (сколько атакующих прощупывают эту брешь). Какой из трендов окажется быстрее, и определит, как эту историю будут вспоминать.
