КИБЕРБЕЗОПАСНОСТЬ

Атака Magecart через аналитику Convertr затронула платежные страницы

24 октября злоумышленники внедрили скиммер в аналитику Convertr и получили доступ к данным карт покупателей бразильских интернет-магазинов.

✍️ Редакция iTech News | 28.10.2026 | ⏱ 3 мин | Источник: BleepingComputer
Атака Magecart через аналитику Convertr затронула платежные страницы

24 октября злоумышленники внедрили платежный скиммер в общий аналитический скрипт бразильской платформы Convertr. Атака Magecart опасна не количеством взломанных витрин, а точкой входа: один зараженный файл подгружался на страницах оплаты всех магазинов, использующих платформу. Для российских команд это очередное напоминание, что сторонний JavaScript в checkout — часть платежного контура, а не безобидная «метрика».

Как сообщает BleepingComputer, кампанию обнаружили 24 октября. Исследователи Sansec связывают ее с бразильской группировкой, которая действует как минимум с июля 2024 года и специализируется на заражении магазинов на Magento, OpenCart и WooCommerce. Convertr обслуживает десятки крупных модных брендов в Бразилии; через ее решения для интернет-магазинов и оплаты проходит около 2 млрд бразильских реалов продаж, или примерно $370 млн.

Атакующие изменили файл трекера Plausible — открытой альтернативы Google Analytics. Convertr размещала и администрировала этот экземпляр аналитики на собственной инфраструктуре. После подмены легитимный скрипт стал загружать код для перехвата данных прямо на checkout-страницах. Это классическая атака Magecart: скрипт работает в браузере покупателя и снимает реквизиты до того, как форма отправит их платежному провайдеру. Шифрование между браузером и сайтом здесь не спасает: вредоносный код уже находится внутри доверенной страницы.

Sansec предполагает, что первоначальный доступ мог быть получен через CVE-2026-8467 — уязвимость, позволяющую выполнить команды без аутентификации в устаревшей Community Edition Plausible. Это пока гипотеза, а не подтвержденная причина инцидента. Важно и другое: после захвата сервера злоумышленникам не пришлось ломать каждый магазин отдельно. Компрометация общего ресурса превратила аналитический трекер в канал доставки скиммера ко всем подключенным checkout-сценариям.

Код развивался по ходу кампании. Ранние варианты искали поля оплаты по универсальным шаблонам, а к 26 октября скиммер уже учитывал точные имена полей платежного API Convertr. Он собирал номер карты, срок действия, CVV, имя держателя и CPF — бразильский налоговый идентификатор. Последний пункт делает утечку особенно неприятной: речь идет не только о данных для спорной транзакции, но и о связке платежных и персональных сведений.

Convertr, по данным Sansec, удалила вредоносный код и обновила Plausible до исправленной версии. Компания также сообщила, что уведомляет затронутых продавцов и платежных провайдеров. При этом исследователи предупреждают о браузерном кеше: зараженный файл может продолжать выполняться до 24 часов после очистки сервера. Покупателям, которые вводили карту на страницах с адресом, содержащим checkout.convertr, с 24 октября рекомендуют связаться с банком и заблокировать карту; перед новой оплатой — очистить кеш браузера.

Для разработчиков и владельцев e-commerce это не история про экзотическую бразильскую платформу, а про инвентаризацию доверия. Скрипты аналитики, тег-менеджеры, виджеты поддержки и A/B-тесты получают тот же доступ к DOM, что и форма оплаты. В платежных сценариях полезно сокращать число внешних зависимостей, фиксировать версии и хеши скриптов, включать CSP и Subresource Integrity там, где архитектура это позволяет, а также мониторить изменения загружаемых ресурсов. Отдельно стоит проверять, не живут ли self-hosted сервисы на забытых версиях: удобство самостоятельного размещения быстро превращается в лишнюю поверхность атаки, если патчи остаются в бэклоге.

Инцидент с Convertr показывает, почему атака на цепочку поставки в вебе часто выгоднее взлома одного магазина: достаточно попасть в общий скрипт, чтобы оказаться в платежной форме сразу у многих продавцов. Следующий практический вопрос для отрасли — готовы ли команды рассматривать каждый JavaScript-ресурс на checkout как компонент с уровнем критичности платежного шлюза, включая обновления, аудит и план реагирования.

Поделиться: Telegram X LinkedIn