Уязвимость Gravity SMTP уже пытаются эксплуатировать вживую, а под ударом остаются до 100 тысяч WordPress-сайтов. Проблема формально получила средний рейтинг опасности, но на практике позволяет без авторизации вытащить из системы ключи API, токены и подробный технический профиль сервера — для админов, агентств и продуктовых команд это плохая новость без скидок на «medium».
О проблеме сообщает BleepingComputer со ссылкой на исследователей Wordfence. Речь идет о CVE-2026-4020 в плагине Gravity SMTP: уязвимы версии 2.1.4 и старше, исправление вышло еще 17 марта в релизе 2.1.5. По данным Defiant, компании-разработчика Wordfence, злоумышленники уже активно используют баг, а их WAF заблокировал более 17 млн запросов к уязвимому endpoint.
Технически история довольно простая и от этого не менее неприятная. В плагине оказался открыт REST API endpoint, у которого callback проверки прав всегда возвращал true. В результате любой неавторизованный GET-запрос мог получить JSON-отчет System Report, который генерирует сам плагин. То есть вместо аккуратной служебной диагностики для администратора наружу утекает вполне боевой набор данных для атакующего. В таком отчете могут оказаться ключи API, секреты и OAuth-токены для почтовых интеграций, учетные данные внешних email-сервисов вроде Amazon SES, Google, Mailjet, Resend и Zoho, сведения о конфигурации WordPress, список установленных плагинов и тем, версии ПО, параметры PHP и сервера, а также детали базы данных — вплоть до версии сервера и имен таблиц.
Вот почему уязвимость Gravity SMTP выглядит опаснее, чем намекает ее «средняя» оценка. Для атакующего это не просто утечка диагностического мусора, а короткий путь к двум полезным результатам. Во-первых, можно получить рабочие учетные данные почтовых сервисов и использовать их для отправки писем от имени жертвы — например, в фишинговых кампаниях, спаме или атаках на цепочку доверия с участием домена компании. Во-вторых, подробный системный отчет сильно удешевляет дальнейшую разведку: не нужно гадать, какие плагины стоят на сайте, какие версии крутятся на сервере и где искать следующую точку входа. Иными словами, один баг превращается в удобный трамплин для следующих.
По статистике Wordfence, заметный всплеск эксплуатации пришелся на 7 июня: только за этот день было заблокировано 4 млн запросов. Похожие объемы фиксировались и в последующие дни. Для владельцев сайтов это важно по двум причинам. Первая: речь не о лабораторной демонстрации, а о массовом сканировании интернета на вполне конкретную цель. Вторая: если патч вышел еще в марте, а волна атак пошла в июне, значит классическая связка «обновим потом, когда будет окно» снова работает на стороне злоумышленников. WordPress-экосистема здесь особенно уязвима не потому, что она слабее других платформ по определению, а потому что длинный хвост сайтов обновляется медленно, живет на чужом хостинге, обслуживается небольшими командами и обрастает плагинами быстрее, чем процессами безопасности.
Отдельный индикатор компрометации — запросы к /wp-json/gravitysmtp/v1/tests/mock-data в access log веб-сервера, особенно если рядом встречается параметр ?page=gravitysmtp-settings. Для разработчиков и DevOps это значит, что проверка не должна ограничиваться только обновлением плагина. Нужен хотя бы базовый разбор логов за последние недели, ревизия почтовых интеграций и ротация секретов, если сайт работал на уязвимой версии. Если в конфигурации использовались Amazon SES, Google или другие провайдеры доставки писем, лучше исходить из неприятного, но реалистичного сценария: учетные данные могли уже увидеть. В такой ситуации смена ключей и токенов важнее, чем спор о том, был ли конкретный запрос «настоящей атакой» или просто фоновым сканированием.
Для рынка это еще один сигнал, что категория bug class matters больше, чем формальная шкала severity. Неавторизованное раскрытие данных в плагине, который работает с почтовой инфраструктурой, почти всегда тянет за собой бизнес-риски за пределами самого сайта. Если через скомпрометированный SMTP-стек начинают уходить письма от имени компании, дальше страдают уже не только WordPress и веб-команда, но и deliverability, репутация домена, коммуникации с клиентами и внутренние процессы. Для агентств и интеграторов, у которых десятки клиентских сайтов на сопровождении, такие истории особенно болезненны: одна пропущенная уязвимость Gravity SMTP легко превращается в серию однотипных инцидентов, которые приходится разгребать пакетно.
Контекст тоже показательный. BleepingComputer отдельно упоминает, что буквально накануне Wordfence предупредила о другой проблеме в WordPress-плагине — критической уязвимости CVE-2026-8713 в Avada Builder, установленном на 1 млн сайтов. Там речь идет уже не о раскрытии данных, а о произвольном удалении файлов без авторизации с перспективой полного захвата сайта. Активной эксплуатации этой ошибки пока не наблюдали, но сама связка новостей говорит о неприятной норме для WordPress-мира: атакующие больше не ждут редких «суперкритичных» багов, им хватает и утечек конфигурации, и плохо закрытых служебных endpoint, и старых добрых path traversal. Если плагин популярен, окно между публикацией патча и автоматизированной эксплуатацией становится все короче.
Главный вывод здесь не в том, что очередной WordPress-плагин снова подвел. Скорее в том, что инфраструктурные плагины давно надо считать частью периметра, а не «мелкой админкой для отправки писем». Когда неавторизованный запрос к диагностическому endpoint может раскрыть ключи, токены и карту всей системы, спор о том, medium это или high, уже выглядит немного академическим. Для команд, которые поддерживают сайты как бизнес-критичный канал, вопрос теперь проще: сколько еще таких служебных механизмов у вас смотрят наружу и ждут не обновления, а первого чужого запроса.