Критическая уязвимость Funnel Builder для WordPress уже используется в атаках: злоумышленники внедряют вредоносный JavaScript прямо в страницы оформления заказа WooCommerce и перехватывают данные банковских карт. Проблема затрагивает все версии плагина ниже 3.15.0.3, а с учетом аудитории более чем в 40 тысяч сайтов речь идет не о теоретической дыре, а о вполне рабочем канале кражи платежных данных.
Об инциденте сообщает BleepingComputer. Уязвимость обнаружили специалисты компании Sansec, которая занимается безопасностью e-commerce. По их данным, атакующие используют публично доступную и незащищенную checkout-toчку входа, через которую можно без авторизации менять глобальные настройки плагина. Дальше схема предсказуемая и оттого неприятная: в раздел External Scripts подсовывается произвольный код, и он исполняется на каждой странице оплаты.
Сам плагин Funnel Builder, разработанный FunnelKit, нужен владельцам магазинов на WooCommerce не для экзотики, а для вполне приземленных задач: кастомизации checkout-страниц, one-click upsell, посадочных страниц и роста конверсии. Именно поэтому история особенно токсична. Когда компрометируют плагин, который сидит в самой чувствительной точке воронки продаж, удар приходится не только по безопасности, но и по выручке, доверию покупателей и репутации магазина. И если обычный баг в теме оформления можно пережить, то уязвимость Funnel Builder бьет по месту, где пользователь уже достал карту.
Sansec пишет, что вредоносная нагрузка маскируется под фальшивый скрипт Google Tag Manager или Google Analytics с адресом analytics-reports[.]com/wss/jquery-lib.js. После загрузки он открывает WebSocket-соединение с внешним сервером wss://protect-wss[.]com/ws и получает оттуда уже специализированный платежный скиммер. Такой подход удобен для атакующего: в коде страницы можно спрятать относительно невинный на вид загрузчик, а реальную логику подтягивать по сети и менять на лету. Для администраторов магазина это худший вариант: даже если кто-то заметит лишний скрипт, не факт, что с первого взгляда поймет, что это не криво подключенная аналитика, а точка входа для кражи карт.
Набор похищаемых данных тоже без сюрпризов, но от этого не легче: номера карт, CVV, billing address и прочая информация о покупателе. Дальше у злоумышленников два стандартных пути монетизации. Первый: использовать карты для мошеннических покупок. Второй: продавать записи поштучно или пачками на carding-площадках. Для бизнеса это означает не только возвраты и chargeback, но и куда более неприятные последствия: расследование инцидента, уведомление платежных партнеров, разбор претензий от клиентов и долгий хвост репутационных потерь. В e-commerce такие вещи всплывают не в тот день, когда скрипт внедрили, а когда банк или покупатель начинает задавать неудобные вопросы.
Важно и то, что у этой истории на момент публикации нет официального идентификатора вроде CVE. Для инженерной команды это плохая новость в чисто практическом смысле. Во многих компаниях процессы приоритизации патчей, алерты сканеров и даже внутренние тикеты завязаны на CVE-номер, severity score и стандартный поток advisory. Здесь все проще и грубее: эксплойт уже в деле, а значит ориентироваться нужно не на формальную бюрократию вокруг уязвимости, а на фактический риск. Если магазин работает на WooCommerce и использует Funnel Builder, отсутствие красивого идентификатора не снижает угрозу ни на один процент.
Разработчик выпустил исправление в версии 3.15.0.3 14 мая 2026 года, за день до публикации материала. По данным Sansec, в advisory от вендора прямо сказано, что была выявлена проблема, позволявшая злоумышленникам внедрять скрипты. Рекомендация тоже без сложной магии: как можно быстрее обновить плагин через WordPress Dashboard и отдельно проверить путь Settings > Checkout > External Scripts на предмет посторонних вставок. Это важный нюанс: простое обновление не гарантирует, что зараженный магазин автоматически станет чистым. Если атакующий уже добавил вредоносный код в настройки, его нужно найти и удалить, а сам сайт после этого имеет смысл проверить шире, чем один экран с настройками.
Для русскоязычной IT-аудитории здесь есть несколько неприятных, но полезных выводов. Во-первых, WordPress и WooCommerce остаются не только удобной платформой для быстрого запуска продаж, но и постоянной зоной риска, если бизнес собирает платежные данные через пестрый набор плагинов. Во-вторых, атака снова показывает, что checkout-кастомизация, аналитические вставки и маркетинговые скрипты давно стали любимой маскировкой для вредоносов: там много стороннего JavaScript, а значит лишний файл не всегда выглядит подозрительно. В-третьих, агентствам, интеграторам и штатным командам поддержки магазинов пора относиться к плагинам в платежном контуре как к критической инфраструктуре, а не как к безобидным надстройкам для маркетинга. Если компонент умеет менять страницу оплаты, он уже заслуживает отдельного патч-менеджмента, мониторинга изменений и регулярной ревизии внешних скриптов.
История с Funnel Builder вряд ли станет последней в цепочке атак на экосистему WordPress. Чем больше бизнес выносит в плагины логику checkout, апсейлы, редиректы и аналитику, тем привлекательнее эта зона для злоумышленников: доступ к одной настройке может оказаться доступом к тысячам чужих карт. И главный вопрос теперь не в том, сколько еще магазинов успеют обновиться, а в том, сколько из них проверят не только версию плагина, но и сам факт компрометации.