В плагине Avada Builder для WordPress нашли сразу две дыры, и для проекта с оценочно миллионом активных установок это уже не частная неприятность, а массовый операционный риск. Уязвимости Avada Builder позволяют либо читать произвольные файлы на сервере, либо вытаскивать чувствительные данные из базы, а значит под ударом оказываются и админ-доступы, и пароли, и весь сайт целиком.
О проблеме как пишет BleepingComputer, сообщил исследователь безопасности Rafie Muhammad, который отправил находки через программу Wordfence Bug Bounty Program. Речь идет о двух разных сценариях атаки. Первый получил идентификатор CVE-2026-4782 и затрагивает все версии Avada Builder до 3.15.2 включительно. Второй, CVE-2026-4798, касается версий до 3.15.1. Формально это две отдельные ошибки, но для владельца сайта разница академическая: обе ведут к утечке данных, только заходят с разных дверей.
С CVE-2026-4782 ситуация особенно показательная. Уязвимость связана с механизмом рендеринга шорткодов и параметром custom_svg: плагин недостаточно проверяет тип и источник файла, из-за чего пользователь с минимальными правами уровня subscriber может прочитать содержимое почти любого файла на сервере. В списке очевидных целей — wp-config.php, где обычно лежат учетные данные для подключения к базе и криптографические ключи. Получив такой файл, атакующий уже не просто «что-то посмотрел», а получает материал для захвата административной учетной записи и полного компромета сайта. Уязвимость оценили как среднюю по severity, потому что она требует аутентификации, но это тот случай, когда формальная классификация не слишком успокаивает: у многих WordPress-сайтов регистрация пользователей открыта, а значит порог входа для атаки низкий.
Вторая проблема, CVE-2026-4798, выглядит еще неприятнее в чисто практическом смысле: это blind SQL injection по времени, которую можно эксплуатировать без аутентификации. Причина классическая и потому особенно досадная: пользовательский параметр product_order попал в SQL-конструкцию ORDER BY без корректной подготовки запроса. Через такую ошибку можно поэтапно извлекать чувствительные данные из базы, включая хэши паролей. Правда, здесь есть важное условие: атака возможна только в том случае, если на сайте раньше был включен WooCommerce, затем его отключили, а таблицы в базе при этом сохранились. То есть сценарий не универсальный, но и не экзотический: в реальной эксплуатации отключенные плагины и оставленные после них таблицы — обычная часть наследия проекта, особенно если сайт пережил пару подрядчиков и несколько «быстрых запусков».
Хронология тоже говорит о многом. Wordfence получила отчеты 21 марта 2026 года, издателя Avada Builder уведомили 24 марта. Частичный фикс в версии 3.15.2 вышел 13 апреля, а полностью закрывающая обе проблемы версия 3.15.3 — только 12 мая. Иными словами, между первичным сообщением и полноценным исправлением прошло почти полтора месяца. Для экосистемы WordPress это не шок, а скорее будни, но для бизнеса, который считает CMS «чем-то из коробки», такие сроки — полезное напоминание: даже популярный коммерческий стек не избавляет от необходимости следить за патчами почти в режиме дежурной смены.
Отдельно стоит посмотреть на экономику находок. За первую уязвимость исследователь получил 3386 долларов, за вторую — 1067 долларов. Суммы не рекордные, но они хорошо показывают расстановку приоритетов: проблема с чтением файлов и возможным доступом к wp-config.php выглядит для защитников более опасной и более универсальной, чем SQL-инъекция с зависимостью от следов WooCommerce. Для разработчиков и техлидов здесь нет никакой новой магии, зато есть старая знакомая дисциплина: валидация источников файлов, строгая работа с путями, нормальная подготовка SQL-запросов и отказ от логики «ну это же только параметр сортировки».
Для русскоязычной IT-аудитории история важна не только как еще один инцидент вокруг WordPress. Она про типичный разрыв между ролями в команде. Разработчик видит «билдер для верстки страниц», маркетинг видит удобный визуальный инструмент, владелец бизнеса — способ быстрее выпускать лендинги и каталоги. Атака же видит код, который трогает файловую систему и базу данных. Когда такие плагины стоят на корпоративных витринах, интернет-магазинах, промосайтах и сайтах найма, проблема быстро переезжает из зоны «у CMS баг» в зону репутационных и операционных потерь. Утекшие хэши паролей, скомпрометированный админ, подмененный контент, фишинговые вставки, вредоносные редиректы — дальше сценарии давно известны.
Практический вывод здесь скучный, а потому особенно ценный. Если Avada Builder используется в инфраструктуре, обновление до 3.15.3 — это не задача «на ближайший спринт», а технический долг с понятной ценой просрочки. Параллельно стоит проверить, открыта ли регистрация пользователей, кому реально нужны права уровня subscriber, не остались ли на проекте следы от отключенного WooCommerce и насколько вообще команда понимает состав плагинов в продакшене. Уязвимости Avada Builder в очередной раз показывают, что главный риск WordPress часто не в самом движке, а в расширениях, которые годами копят лишние права, старые зависимости и иллюзию безобидности. Чем популярнее плагин, тем меньше он похож на «маленькую деталь» и тем больше — на полноценную часть периметра безопасности.