Плагин Bricksforge для WordPress попал под активную эксплуатацию: Patchstack сообщил о попытках использовать критическую уязвимость CVE-2026-85097 с оценкой 10.0. Ошибка позволяет неавторизованному атакующему загрузить и выполнить PHP-код на уязвимом сайте.

Проблема затрагивает версии Bricksforge до 3.1.8.9 включительно. Разработчики выпустили исправление в версии 3.1.8.10, а специалисты заметили первые попытки атаки 7 октября 2026 года в 21:47 UTC.

История инцидента

Bricksforge — это плагин для WordPress, который используют вместе с визуальным конструктором Bricks. Он добавляет анимации, расширенные формы и другие функции для оформления сайта.

По данным Patchstack, атакующие бьют по механике загрузки временных файлов. Плагин проверяет MIME-тип при первом аплоаде, но позже доверяет метаданным, которые присылает клиент. В итоге поле url внутри параметра temporaryFileUploads проходит без достаточной проверки.

Схема выглядит грубо, но работает: злоумышленник получает nonce через открытый AJAX-эндпоинт, загружает файл-двойник, который выглядит как изображение, а потом подсовывает форму с нужным путём и PHP-расширением в URL. После этого код исполняется уже на сервере.

Что пошло не так в защите

Слабое место — не в самом факте загрузки файла, а в доверии к данным, которые пришли от клиента позже. Если сервер проверил GIF или PNG один раз, это не значит, что дальше можно полагаться на присланный путь и имя файла.

Здесь сработала типичная ошибка веб-разработки: разрыв между проверкой содержимого и последующей обработкой метаданных. Именно так атакующий получает возможность подменить конечный путь и добиться выполнения произвольного кода.

Похожую логику мы уже видели в других историях про уязвимые веб-системы, где сначала всё выглядит как обычная ошибка валидации, а через пару шагов она превращается в полный захват сайта. Для сравнения полезно посмотреть разборы про дыру в SonicWall SMA 1000, которую начали обстреливать после патча и про дыры в AhsayCBS, которые превратили резервное ПО в точку атаки.

По наблюдениям Patchstack, атака шла с 63 уникальных IP-адресов. Исследователи отдельно отметили две группы: одна массово слала одинаковые запросы, другая перебирала варианты PHP-расширений и кодировок. Это похоже на автоматизированную эксплуатацию через распределённую инфраструктуру.

Уроки для читателя

Для владельцев WordPress-ресурсов вывод простой: один патч закрывает дыру, но не спасает от уже случившегося заражения. Если сайт работал на Bricksforge уязвимой версии, обновление нужно ставить немедленно, а затем проверять журналы и содержимое каталога /wp-content/uploads/bricksforge/tmp/.

Нужно смотреть не только на версию плагина, но и на признаки посторонней активности: повторные отправки форм, неожиданно созданные PHP-файлы, странные запросы к /wp-json/bricksforge/v1/form_submit и к admin-ajax.php. Если сайт уже скомпрометирован, одного обновления мало — вредоносный код может остаться в системе.

Здесь уместна обычная цифровая гигиена: обновления, резервные копии, контроль прав доступа и двухфакторная аутентификация для админов. Для команд, которые ведут сайты удалённо, полезно держать под рукой и инструмент для защищённой удалённой работы, и менеджер паролей, и 2FA — не как моду, а как базовый набор.

Отдельно стоит помнить: если на сайте стоит несколько плагинов, уязвимость в одном из них может стать входом для всей инфраструктуры. Не зря в свежих атаках на WordPress злоумышленники параллельно использовали и XSS-дыры в других расширениях, чтобы закрепиться в админке и создать скрытые учётки.

Практические выводы и чек-лист

  • Обновить Bricksforge до версии 3.1.8.10 или новее.
  • Проверить логи на запросы к /wp-json/bricksforge/v1/form_submit и admin-ajax.php.
  • Осмотреть каталог /wp-content/uploads/bricksforge/tmp/ на наличие PHP-файлов и подозрительных загрузок.
  • Поиcкать повторные формы с параметром temporaryFileUploads и нетипичные имена файлов.
  • Проверить список администраторов WordPress и убедиться, что там нет лишних учёток.
  • Сменить пароли у админов и включить 2FA.
  • Сделать резервную копию и сверить её с чистой версией сайта.
  • Ограничить права записи для тех каталогов, где это не нужно.
  • Использовать защищённый канал для админ-доступа к сайту на удалённой работе: связь для удалённых задач.

Если сайт уже показывает следы вмешательства, обновление плагина нужно считать только первым шагом. Дальше идёт ручная проверка файлов, логов и админов — без неё легко оставить злоумышленнику лазейку на сервере.

Поделиться: