Нулевой день StyleSmuggler атакует Magento и Adobe Commerce
Исследователи Sansec сообщили об активной эксплуатации неустранённой уязвимости StyleSmuggler в Magento Open Source и Adobe Commerce. Атака не требует авторизации, позволяет выполнить код на сервере интернет-магазина и установить постоянный бэкдор. Sansec воспроизвела полную цепочку на чистых Magento Open Source 2.4.7, 2.4.8 и 2.4.9; среди первых пострадавших был магазин на 2.4.6-p15 с июльскими и августовскими обновлениями Adobe 2026 года.
Атаки, по данным Sansec, начались 4 сентября. На 6 сентября Adobe не выпустила бюллетень, идентификатор CVE, патч или официальный обходной путь. Компания также не подтвердила перечень затронутых редакций Adobe Commerce, хотя Sansec считает уязвимыми все актуальные версии Magento Open Source.
Как развивается атака
По описанию Sansec, злоумышленник сначала внедряет PHP-код в файл, который создаёт сам Magento, например при формировании отчёта об ошибке. Затем платформа принудительно обрабатывает этот файл через штатное уведомление «Payment Transaction Failed Reminder». Код выполняется во время рендеринга письма, поэтому открывать сообщение не требуется, а доставка почты может завершиться ошибкой без остановки атаки.
Компания Disrex Group, отреагировавшая на два инцидента, независимо подтвердила эксплуатацию. Её специалисты указывают, что следы внедрения могут находиться не только в var/report, но и в var/log/system.log. В частности, они наблюдали заголовки вида X-TRACE- с десятью шестнадцатеричными символами, а позднее — вариант без слова TRACE. Проверка только точного маркера может пропустить изменённый вариант.
Схема напоминает, как атаки на SAP Commerce Cloud после патча показывает скорость появления атак на платформы электронной коммерции после публикации технических деталей. В этом случае кампания началась до появления исправления от разработчика, поэтому версия продукта сама по себе не гарантирует защиту.
Признаки закрепления и ограничения защиты
Sansec описала бэкдор как процесс с именем [kworker/u:8:0], запущенный от имени пользователя сайта. Бинарный файл размещается в домашнем каталоге пользователя, а запись cron перезапускает его каждые пять минут. Настоящие потоки ядра Linux принадлежат root и не имеют резидентной памяти; процесс с таким именем у пользователя сайта и с потреблением памяти требует проверки.
Disrex обнаружила, что вредоносная программа может читать сессии Magento из Redis. В одном случае в cron было 1 728 одинаковых строк, а удалённая запись восстанавливалась менее чем за секунду. Исследователи также предупреждают: хеш файла на диске может не совпадать с бинарником, который уже выполняется в памяти, поэтому проверять следует и путь /proc/<pid>/exe.
Что делать до выхода патча
Sansec рекомендует временно отключить GraphQL тем, кто не использует её защитный продукт. Disrex отмечает, что это особенно болезненно для headless- и PWA-витрин, тогда как классические витрины и Hyvä обычно от GraphQL не зависят. Правила для nginx и Apache могут блокировать известные параметры в строке запроса, но Disrex установила, что те же данные в POST- или JSON-теле доходят до PHP.
Для уже заражённого сервера Disrex советует сначала сохранить доказательства, затем удалить cron-задание и только после этого останавливать процесс: иначе он создаст задание заново. Не следует перезагружать сервер, поскольку исполняемый файл может остаться только в памяти, и запускать composer install, который перезапишет важные временные метки. После проверки нужно очистить хранилище сессий и сменить ключ шифрования Magento, пароли администраторов, ключи платёжных провайдеров и другие учётные данные интеграций.
Практический вывод для владельцев магазинов: до официального исправления необходимо оценить зависимость витрины от GraphQL, проверить логи, cron, процессы и Redis, а при обнаружении индикаторов действовать как при полноценном инциденте, а не ограничиваться удалением одного файла.