WebRTC-скиммер крадёт платёжные данные, обходя защиту интернет-магазинов

Голландская компания Sansec обнаружила платёжный скиммер нового типа, который принципиально отличается от всего, что встречалось раньше. Вместо привычных HTTP-запросов для передачи украденных данных он использует каналы WebRTC — технологию, созданную для видеозвонков и обмена данными в реальном времени между браузерами. Это позволяет скиммеру полностью обходить директивы Content Security Policy (CSP) и ускользать от сетевых инструментов мониторинга, которые заточены именно под анализ HTTP-трафика.

Скиммер представляет собой самозапускающийся скрипт. При загрузке страницы оплаты он устанавливает WebRTC peer-соединение с жёстко прописанным IP-адресом 202.181.177[.]177 через UDP-порт 3479. Канал при этом шифруется протоколом DTLS. Через это соединение скрипт подтягивает JavaScript-код, который перехватывает платёжную информацию покупателя — номера карт, CVV, имена. Украденные данные утекают тем же маршрутом: по UDP, а не по HTTP. Для средств сетевой безопасности, инспектирующих именно HTTP-трафик, этот поток попросту невидим.
Скиммер был найден на сайте электронной коммерции одного из автопроизводителей. Он использовался совместно с эксплуатацией уязвимости под названием PolyShell, обнаруженной командой Assetnote из компании Searchlight Cyber. Затрагивает она платформы Magento Open Source и Adobe Commerce.
PolyShell кроется в функции ImageProcessor::processImageContent(). Эта функция принимает любой файл, который формально выглядит как «валидное» изображение: проверяется лишь то, что файл не пуст, имеет размер, корректный MIME-тип и не содержит заблокированных символов. Но вот соответствие расширения файла его MIME-типу не проверяется вообще. Этот пробел открывает дверь для загрузки так называемых полиглот-шеллов — файлов, которые одновременно являются и изображением, и исполняемым кодом.
Атакующие загружают вредоносный файл через HTTP POST-запрос к эндпоинту /rest/default/V1/guest-carts/{cart_id}/items. Аутентификация для этого не нужна. Файл оседает в директории pub/media/custom_options/quote/<ПЕРВЫЙ_СИМВОЛ>/<ВТОРОЙ_СИМВОЛ>/<ИМЯ_ФАЙЛА>. Если веб-сервер настроен с отклонениями от рекомендованных Adobe конфигураций Nginx или Apache — например, отсутствуют файлы .htaccess или убраны правила «deny all» для исполнения PHP — шелл становится доступным и работоспособным. При правильной конфигурации запрос к такому файлу возвращает ошибку 404.
Массовая эксплуатация PolyShell началась 19 марта 2026 года, всего через девять дней после того, как Adobe 10 марта 2026 года выпустила исправление в бета-версии 2.4.9-beta1. На момент публикации отчёта патч так и не добрался до стабильных продуктивных релизов. Исследователь Томаис Уильямсон (Tomais Williamson) из Assetnote описал техническую сторону проблемы.
Масштаб проблемы впечатляет. Sansec зафиксировала более 50 IP-адресов, участвовавших в сканировании уязвимых магазинов. Следы атак PolyShell были найдены на 56,7% всех уязвимых магазинов, которые компания проверяла. Это не единичные инциденты, а волна.
Рекомендации для владельцев магазинов на Magento и Adobe Commerce довольно конкретны. Первое — заблокировать доступ к директории pub/media/custom_options/. Второе — просканировать магазин на наличие веб-шеллов, бэкдоров и другого вредоносного ПО. Третье — убедиться, что конфигурация Nginx или Apache строго соответствует дефолтным рекомендациям Adobe, запрещающим исполнение неавторизованных PHP-файлов. Ожидание стабильного патча при таких темпах эксплуатации — риск, который каждый магазин берёт на себя сам.