Злоумышленники эксплуатируют новую неустранённую уязвимость в Magento Open Source и Adobe Commerce, которая позволяет выполнять вредоносный код на сервере интернет-магазина без входа в систему. Об этом сообщила нидерландская компания по безопасности электронной коммерции Sansec в уведомлении, опубликованном 5 сентября.
Sansec обнаружила уязвимость и назвала её StyleSmuggler. По данным компании, атаки начались 4 сентября. «Sansec публикует информацию раньше обычного, потому что магазины взламывают прямо сейчас», — заявили в компании.
Патча нет, затронуты все версии
По состоянию на 6 сентября Adobe не опубликовала ни уведомление, ни идентификатор CVE, ни исправление, ни временное решение. В индексе бюллетеней безопасности Adobe Commerce нет записей после обновления от 11 августа. Ближайшее плановое обновление безопасности Adobe назначено на 8 сентября, но неизвестно, закроет ли оно эту ошибку.
Sansec сообщает, что уязвимы все текущие версии, включая 2.4.9. Компания воспроизвела полную цепочку атаки без аутентификации на чистых установках Magento Open Source версий 2.4.7, 2.4.8 и 2.4.9. Первая жертва работала на версии 2.4.6-p15 с применёнными обновлениями безопасности Adobe за июль и август 2026 года — это последний уровень патчей для этой линейки.
Успешная атака даёт злоумышленнику возможность выполнять код на сервере магазина и устанавливает постоянный бэкдор. Sansec пока не опубликовала полную цепочку эксплойта, пообещав позже раскрыть детали цепочки, дроппера и вредоносной программы.
Как работает атака
Согласно описанию Sansec, атака проходит в два этапа. Сначала вредоносный PHP-код внедряется в файл, который Magento записывает сама, например при генерации отчёта об ошибке. Затем злоумышленник заставляет Magento выполнить этот файл, запуская стандартное письмо «Payment Transaction Failed Reminder» (напоминание о неудачной оплате). Код выполняется во время рендеринга сообщения, поэтому жертве не нужно его открывать, а атака может быть успешной даже в случае сбоя доставки письма.
Компания Disrex Group, хостинг-провайдер Magento, который обслуживал и реагировал на инциденты в двух взломанных магазинах, опубликовала собственный анализ механизма атаки. По их версии, директива во внедрённом тексте заставляет последовательность собственных классов Magento выполнить код, который подключает выбранный злоумышленником файл — отравленный лог. Затем PHP-дроппер последовательно перебирает шесть PHP-функций для запуска процесса, скачивает и запускает вредоносную программу.
Индикаторы компрометации
Вредоносная программа маскируется под фоновый процесс [kworker/u:8:0] — имя, принадлежащее потоку ядра Linux. Бинарный файл устанавливается в ~/.local/share/.gvfsd/gvfsd-user в домашнем каталоге пользователя сайта, а не в корне веб-сервера. Запись в cron перезапускает вредоносную программу каждые пять минут.
Disrex описывает бинарный файл как stripped-версию статически слинкованной программы на Rust размером около 1,9 МБ, собранную для x86-64 и arm64. Запись в cron добавляется напрямую в файл spool по пути /var/spool/cron/crontabs/, поэтому системный журнал не показывает замену crontab. В одном магазине одна и та же строка была добавлена 1728 раз, и вредоносная программа восстанавливала её в течение секунды после удаления.
Опубликованные индикаторы включают:
- Процесс:
[kworker/u:8:0], принадлежащий не-root пользователю - Файлы:
~/.local/share/.gvfsd/gvfsd-user,~/.local/share/.gvfsd/.gvfsd_<8hex>.lock,/tmp/.gvfsd_<8hex>.lock,/tmp/.kw_<random><random> - Cron:
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user - SHA-256:
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7(образец Sansec),8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef(на диске в магазинах Disrex),251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220(в памяти на одном магазине) - Домен:
247.cdnflare[.]xyz(хост загрузки вредоносного ПО) - IP:
99.84.67[.]186:443(C2 через WebSocket и TLS),88.216.72[.]181(источник атаки),5.181.86[.]133(массовая рассылка атак)
Временные меры защиты
Поскольку официального исправления нет, Sansec рекомендует временно отключить GraphQL до выхода патча Adobe. Однако это решение подходит не всем: headless и progressive web app витрины требуют GraphQL, тогда как большинство классических и Hyvä витрин — нет.
Disrex опубликовала правила nginx и Apache, блокирующие запросы с параметрами эксплойта в строке запроса URL. Но собственный тест на живом магазине показал ограничение: те же параметры, отправленные в теле POST или JSON, достигали PHP, поскольку nginx и Apache проверяют только строку запроса. Disrex описывает правила как остановку текущей кампании, а не закрытие уязвимости.
Основное временное решение Disrex — проверка трёх методов в сканерах кода dependency-injection Magento, предотвращающая их запуск вне командной строки. Ручная правка откатывается при каждом composer install, поэтому компания также распространяет её как composer-patches патч, который применяется при деплое и работает с версиями от 2.4.6 до 2.4.9.
Один из трёх файлов, ClassesScanner.php, вызывается через HTTP как минимум одним сторонним модулем — mageplaza/module-admin-permissions. Защита этого файла ломает админ-экран модуля, поэтому администраторам рекомендуют проверить каталог vendor перед его изменением.
Graycore, LLC опубликовала модуль Magento на GitHub и Packagist, который, по словам компании, укрепляет три точки цепочки: шаблон email-блока отказывает в backend-блоках, генератор URL проверяет класс перед созданием, а PHP-открывающие теги в отчётах об ошибках Web API разрываются. В README сказано: «Это укрепление, а не исправление» — другие пути через уязвимость остаются открытыми, а магазин может быть уже скомпрометирован.
Две серверные настройки, не зависящие от цепочки
Disrex рекомендует добавить proc_open в disable_functions PHP и смонтировать /tmp, /var/tmp и /dev/shm с опцией noexec, чтобы скачанный бинарный файл не мог запуститься. В одном из магазинов первые четыре из шести PHP-функций, которые перебирал дроппер, были отключены, но proc_open — нет, и именно через неё вредоносная программа запустила бэкдор.
Что делать при заражении
Для уже заражённого магазина Disrex рекомендует такой порядок действий: сначала сохранить доказательства, удалить запись cron до завершения процесса (процесс её восстанавливает), не перезагружать сервер (копия в /proc может быть единственным оставшимся бинарным файлом) и не запускать composer install для очистки (это перезапишет метки времени, показывающие, что было изменено). Затем необходимо очистить session storage, ротировать crypt/key в app/etc/env.php, а также все пароли администраторов, ключи API платёжных провайдеров и другие учётные данные интеграций.
Частые вопросы
Какие версии Magento и Adobe Commerce уязвимы?
Sansec сообщает, что уязвимы все текущие версии, включая 2.4.9. Компания воспроизвела атаку на чистых установках Magento Open Source 2.4.7, 2.4.8 и 2.4.9. Первая жертва работала на 2.4.6-p15 с последними обновлениями безопасности.
Как проверить магазин на наличие бэкдора?
Проверьте наличие процесса [kworker/u:8:0], принадлежащего не-root пользователю, и файлов ~/.local/share/.gvfsd/gvfsd-user в домашнем каталоге пользователя сайта. Также ищите файлы с именами .gvfsd_<8hex>.lock и .kw_<random> в /tmp. Sansec рекомендует свой сканер eComscan.
Почему сканер eComscan не обнаружил заражение на одном из магазинов Disrex?
Сканирование было направлено на корень документа магазина, а вредоносная программа установилась на один каталог выше — в домашний каталог учётной записи. Disrex с тех пор расширила путь сканирования.
Можно ли защититься, не дожидаясь патча Adobe?
Можно временно отключить GraphQL, но это сломает headless и PWA витрины. Также доступны неофициальные патчи от Disrex, ProxiBlue и Graycore, правила nginx/Apache и серверные настройки: добавление proc_open в disable_functions и монтирование временных каталогов с noexec.
Как злоумышленники получают доступ к серверу?
Уязвимость позволяет выполнять код без аутентификации. Атака проходит в два этапа: внедрение PHP-кода в файл, который Magento пишет сама, и запуск этого файла через стандартное письмо «Payment Transaction Failed Reminder».
Что делать, если магазин уже взломан?
Сохраните доказательства, удалите запись cron до завершения процесса, не перезагружайте сервер и не запускайте composer install. Затем очистите session storage, ротируйте crypt/key и все пароли и ключи API.
Затронуты ли российские сборки Magento?
Magento Open Source — свободно распространяемая платформа, широко используемая в России и СНГ. Уязвимость затрагивает все версии, поэтому локальным администраторам следует проверить свои магазины на индикаторы компрометации независимо от способа развёртывания. Официальный патч Adobe доступен через обычную процедуру обновления.
Есть ли признаки того, что атака на магазин была успешной?
Disrex отмечает, что TypeError от array_merge() с целочисленным аргументом в system.log сразу после include — свидетельство успешного эксплойта. Однако более скрытный вариант возвращает пустой массив и не оставляет следов в логе. Внезапные всплески писем «Payment Transaction Failed Reminder» — повод для расследования.
Чем бэкдор отличается от настоящего процесса ядра?
Настоящий поток ядра принадлежит root и не имеет резидентной памяти. Имя в скобках у пользователя сайта с реальным использованием памяти — признак вредоносной программы. Бинарный файл в памяти на одном магазине отличался от файла на диске, поэтому рекомендуется хешировать запущенный процесс из /proc/<pid>/exe.
Связана ли эта атака с другими известными инцидентами?
Это отдельная 0-day уязвимость в Magento и Adobe Commerce. Похожие атаки с использованием неустранённых уязвимостей в коммерческом ПО наблюдались и в других продуктах, например GeoServer и PaperCut. Недавние критические уязвимости в SAP Commerce Cloud также эксплуатировались сразу после выхода патча.
Источник: thehackernews.com