Уязвимость PolyShell в Magento: более половины магазинов уже под атакой

Критическая уязвимость PolyShell в Magento 2 позволяет злоумышленникам выполнять произвольный код и внедрять XSS-атаки через REST API. Всего за два дня после публичного раскрытия эксплойт был применен к более чем 56% потенциально уязвимых магазинов. Ситуация усугубляется отсутствием стабильного патча от Adobe: доступна лишь бета-версия исправления, что создает опасное окно для атак. Преступники используют инновационный метод эксфильтрации данных — WebRTC-скимер, который обходит строгие политики безопасности CSP, передавая украденные платежные данные по зашифрованным UDP-соединениям. Вредоносный скрипт маскируется под легитимный трафик и запускается в фоновом режиме, что подтверждено компрометацией сайта крупного автопроизводителя. Эксперты рекомендуют немедленно установить бета-патч с предварительным резервным копированием или внедрить компенсирующие меры: блокировку сканирующих IP-адресов, ограничение доступа к API и усиленный мониторинг сетевого трафика на предмет аномалий.

Массовая эксплуатация уязвимости PolyShell: более половины магазинов Magento под угрозой

В сфере электронной коммерции разворачивается новая волна кибератак, нацеленная на одну из самых популярных в мире платформ для создания интернет-магазинов. Атаки, использующие критическую уязвимость, получившую название PolyShell, уже охватили более 56% всех потенциально уязвимых установок Magento Open Source и Adobe Commerce версии 2. Это не просто теоретическая угроза, а активный процесс эксплуатации, который начался всего через два дня после публичного раскрытия информации об уязвимости.

Ситуация усугубляется тем, что злоумышленники применяют инновационные методы скрытной кражи данных, включая использование протокола WebRTC для обхода современных систем защиты. Эксперты компании Sansec, специализирующейся на безопасности e-commerce, фиксируют беспрецедентную скорость распространения атак и высокую эффективность используемых инструментов. Для владельцев магазинов, администраторов инфраструктуры и разработчиков это сигнал к немедленным действиям, так как отсутствие своевременного обновления может привести к полной компрометации системы, утечке платежных данных и потере контроля над учетными записями.

Техническая природа уязвимости PolyShell и механизм эксплуатации

Чтобы понять масштаб угрозы, необходимо разобраться в технической сути проблемы. Уязвимость PolyShell затрагивает архитектуру REST API в Magento версии 2. В нормальном режиме работы API позволяет клиентам взаимодействовать с корзиной покупок, добавляя товары и настраивая их параметры. Однако исследователи обнаружили критический пробел в логике обработки пользовательских опций (custom options) для товаров в корзине.

Злоумышленники могут использовать этот канал для загрузки файлов произвольного формата. Ключевая особенность атаки заключается в возможности передачи так называемых полиглотов — файлов, которые интерпретируются сервером по-разному в зависимости от контекста. Если конфигурация веб-сервера допускает выполнение загруженных скриптов или если файлы сохраняются в исполняемые директории, это открывает путь к удаленному выполнению кода (Remote Code Execution — RCE).

Помимо прямого взлома сервера, уязвимость также позволяет реализовать атаку типа Stored Cross-Site Scripting (XSS). Злоумышленник может внедрить вредоносный JavaScript-код в данные корзины, который будет сохранен на сервере и выполнен при посещении страницы администратора или другого привилегированного пользователя. Это приводит к перехвату сессий и полному захвату аккаунта владельца магазина.

Особенность PolyShell в том, что она использует легитимные механизмы платформы против нее самой. Поскольку REST API является стандартным интерфейсом для интеграции внешних сервисов, фильтрация вредоносных запросов становится крайне сложной задачей без глубокого понимания внутренней логики обработки файлов. Именно эта сложность делает уязвимость столь привлекательной для автоматизированных сканеров и ботнетов.

Динамика атак: от раскрытия до массового взлома

Хронология событий вокруг PolyShell демонстрирует классический сценарий «гонки вооружений» между исследователями безопасности и киберпреступниками. Публичное раскрытие информации об уязвимости произошло 17 марта 2026 года. Уже 19 марта, спустя всего 48 часов, компания Sansec зафиксировала начало массовой эксплуатации уязвимости в дикой природе интернета.

Статистика поражает своей скоростью: на момент последнего анализа эксперты обнаружили признаки атак на 56,7% всех магазинов, которые технически подвержены этой уязвимости. Это означает, что более половины владельцев сайтов на базе Magento версии 2, еще не применивших патч, уже стали жертвами сканирования или активных попыток взлома. Такой высокий процент проникновения свидетельствует о том, что инструменты для эксплуатации PolyShell были созданы практически мгновенно после публикации деталей уязвимости и сейчас активно распространяются среди хакерских группировок.

Adobe, владеющая платформой Magento, выпустила исправление в тестовой версии 2.4.9-beta1 еще 10 марта 2026 года. Однако критически важный факт заключается в том, что этот патч пока не перенесен в стабильную ветку разработки и недоступен для широкого круга пользователей в виде официального релиза для продакшена. Задержка между выпуском бета-версии и стабильного обновления создает опасное окно уязвимости, которое злоумышленники используют максимально эффективно.

Компания BleepingComputer пыталась получить комментарии от представителей Adobe относительно сроков выхода стабильного обновления, но на данный момент ответа не последовало. Эта неопределенность вынуждает администраторов принимать сложные решения: либо рисковать, устанавливая бета-версию на боевые серверы, либо оставаться без защиты в ожидании официального релиза.

Роль сканирования и целевой выбор жертв

Исследователи Sansec опубликовали список IP-адресов, которые активно сканируют интернет-пространство в поиске уязвимых магазинов. Эти адреса принадлежат ботам, настроенным на автоматическое обнаружение версий Magento, восприимчивых к PolyShell. Как только такой магазин находится, скрипт немедленно пытается отправить специально сформированный запрос через REST API для проверки наличия уязвимости и запуска эксплойта.

Такой подход позволяет преступникам быстро фильтровать тысячи сайтов, оставляя внимание только на тех, где защита отсутствует. Высокая доля пораженных магазинов (более 56%) говорит о том, что многие владельцы игнорируют рекомендации по обновлению ПО или не имеют ресурсов для оперативного мониторинга безопасности своих инфраструктур.

Новый вектор атаки: WebRTC-скимер для обхода CSP

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

Злоумышленники нашли способ обойти эти ограничения, используя протокол Web Real-Time Communication (WebRTC). Этот протокол изначально разработан для обеспечения связи в реальном времени (видео и аудио) прямо в браузере и использует зашифрованные UDP-соединения поверх DTLS (Datagram Transport Layer Security), а не традиционный HTTP.

Благодаря использованию UDP и шифрованию DTLS, трафик WebRTC выглядит иначе, чем обычный веб-трафик, и часто пропускается через правила CSP, даже если они строго ограничивают параметр connect-src. Это позволяет скимеру незаметно передавать украденные данные карты напрямую на сервер управления и контроля (C2), минуя большинство систем фильтрации сетевого трафика.

Архитектура вредоносного скимера

Разработанный злоумышленниками скимер представляет собой легкий JavaScript-лоадер. Его работа строится на нескольких хитрых приемах:

Обход сигнализации: Скрипт подключается к жестко закодированному C2-серверу, подменяя стандартный процесс сигнализации WebRTC. Он внедряет поддельный обмен SDP (Session Description Protocol), что позволяет установить соединение без участия легитимного сервера сигнализации.
Загрузка второй стадии: Через установленный зашифрованный канал злоумышленник передает вторую стадию полезной нагрузки. Это основной модуль, который выполняет кражу данных.
Обход CSP внутри браузера: Чтобы выполнить код, скимер использует существующий nonce (случайное число, используемое для валидации скриптов) или переключается на режим unsafe-eval, либо применяет прямую инъекцию скрипта, если политика безопасности сайта имеет уязвимости.
Уклонение от обнаружения: Выполнение вредоносного кода откладывается с помощью функции requestIdleCallback. Это позволяет скрипту работать только тогда, когда браузер находится в состоянии простоя, что значительно снижает нагрузку на систему и уменьшает вероятность обнаружения антивирусами или системами мониторинга производительности.

Такая архитектура делает скимер чрезвычайно трудно обнаружимым. Даже если администратор видит подозрительный JS-файл, его активность может быть скрыта за легитимным трафиком WebRTC, а само выполнение происходит в фоновом режиме, не вызывая видимых сбоев в работе сайта.

Реальные последствия: компрометация крупного автопроизводителя

Эффективность новой техники была подтверждена на практике. Исследователи Sansec обнаружили следы работы этого WebRTC-скимера на сайте электронной коммерции одного из крупнейших мировых автопроизводителей, рыночная капитализация которого превышает 100 миллиардов долларов. Это событие подчеркивает, что целью атак являются не только мелкие магазины, но и корпоративные гиганты с серьезными бюджетами на безопасность.

Несмотря на то, что эксперты уведомили компанию об обнаружении угрозы, ответ от представителей автопроизводителя не последовал. Это может указывать на несколько сценариев: либо компания не признает наличие проблемы, либо внутренние процессы реагирования на инциденты работают медленно, либо сайт уже был полностью скомпрометирован, и злоумышленники продолжают свою деятельность незамеченными.

Для бизнеса это служит тяжелым уроком: наличие строгих политик безопасности (CSP) и репутация крупной компании не гарантируют защиту от продвинутых атак, использующих нестандартные протоколы. Уязвимость PolyShell стала точкой входа, а WebRTC-скимер — инструментом, позволившим превратить эту точку входа в долгосрочный канал утечки конфиденциальных данных клиентов.

Практические рекомендации и стратегия защиты

В условиях отсутствия стабильного патча от Adobe и активной эксплуатации уязвимости, владельцам магазинов Magento необходимо предпринять ряд экстренных мер. Ожидание официального релиза может стоить слишком дорого, учитывая, что более половины уязвимых сайтов уже находятся под прицелом.

Первым и самым важным шагом является применение доступного исправления из версии 2.4.9-beta1. Хотя установка бета-версии на продакшен несет определенные риски нестабильности, риск полной потери данных и контроля над сайтом значительно выше. Перед развертыванием критически важно создать полную резервную копию базы данных и файлов системы, а также протестировать обновление на изолированном стенде.

Если установка бета-версии невозможна, необходимо внедрить компенсирующие меры защиты на уровне веб-сервера и WAF (Web Application Firewall):

Блокировка подозрительных IP: Использование списка IP-адресов, опубликованного Sansec, для блокировки сканирующих ботов на уровне фаервола.
Ограничение доступа к REST API: Настройка правил доступа к эндпоинтам API, позволяющих загружать файлы, только для доверенных источников или с обязательной дополнительной аутентификацией.
Усиление CSP: Пересмотр политик Content Security Policy с учетом новых угроз. Хотя WebRTC сложно заблокировать полностью, можно настроить мониторинг необычных соединений и ограничить использование unsafe-eval.
Мониторинг индикаторов компрометации (IoC): Регулярная проверка логов на наличие признаков активности скимера, таких как попытки подключения к известным C2-серверам или использование функций requestIdleCallback в подозрительных скриптах.

Для организаций, работающих в сегменте Linux-инфраструктуры и ценящих полный контроль над своим стеком безопасности, актуальным остается вопрос выбора надежной операционной среды. В этом контексте интерес представляет НАЙС.ОС — российский Linux-дистрибутив, зарегистрированный в реестре отечественного ПО, который обеспечивает прозрачность и возможность глубокой настройки системных компонентов для защиты от подобных угроз.

Выводы: значение новости для экосистемы безопасности

Атака PolyShell демонстрирует эволюцию методов киберпреступников. Они больше не довольствуются простым использованием известных эксплойтов; теперь они комбинируют уязвимости в популярном ПО с инновационными методами обхода защиты, такими как использование WebRTC для скрытой эксфильтрации данных.

Для сообщества open-source и разработчиков платформ электронной коммерции это сигнал о необходимости пересмотра процессов выпуска обновлений. Задержка между выпуском бета-патча и стабильной версии создает критическое окно уязвимости, которое используется злоумышленниками с максимальной эффективностью. Процесс валидации и тестирования должен быть ускорен, особенно в случаях критических уязвимостей, позволяющих удаленное выполнение кода.

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

Ситуация с PolyShell напоминает нам, что в современном цифровом ландшафте безопасность — это непрерывный процесс, требующий бдительности, готовности к быстрым изменениям и способности адаптироваться к новым тактикам противника. Игнорирование предупреждений или надежда на то, что «со мной такого не случится», в эпоху автоматизированных атак может привести к катастрофическим последствиям.