stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) — набор инструментов IOC для Magento Open Source и Adobe Commerce. Обнаружение скомпрометированных магазинов, Rust-имплантов, PHP-веб-шеллов, артефактов персистентности и известных индикаторов компрометации.

Покрытие официального патча Adobe — проверьте это, прежде чем считать себя в безопасности

Если вы используете более старую, неподдерживаемую версию, Adobe не выпустит для вас исправление, даже если вы так же уязвимы. См. docs/PATCHING.md для ваших вариантов.

Эта информация быстро меняется. Перепроверяйте по первоисточникам перед действиями: рекомендация Sansec и бюллетень Adobe. См. docs/TIMELINE.md для журнала событий и указывайте источники, когда обновляете что-либо здесь.

Что такое StyleSmuggler на самом деле

Собственный параметр GraphQL styles в Magento и его сканирование файлов на основе внедрения зависимостей используются как двухэтапный, файловый примитив отложенного выполнения, а не как единая очевидная точка инъекции:

1. Отравление. Данные, контролируемые атакующим, попадают в генерируемый Magento файл журнала или отчёта (var/log/system.log через недопустимый код магазина, который Magento записывает дословно, или var/report/<hash>), протаскиваемые через параметр GraphQL styles[], мутированный заголовок запроса или (для второго, несвязанного атакующего ниже) заголовок Store:.
2. Детонация. Атакующий запускает стандартное письмо Magento «Payment Transaction Failed Reminder». Рендеринг этого письма (путь getProcessedTemplate в Magento) проходит по пути кода, который позволяет собственному DI/код-сканеру Magento выполнить include() отравленного файла, запуская PHP атакующего. Вам не нужно открывать письмо — рендеринга на стороне сервера достаточно — и цепочка может сработать, даже если доставка почты не удалась.

Простой признак раннего предупреждения без инструментов: искажённое письмо «Payment Transaction Failed Reminder» в вашем почтовом ящике с сырыми, неотрендеренными тегами {{var ...}} и адресом клиента, заканчивающимся на .invalid. Это часто первый видимый признак, до того как кто-либо проверит журнал.

Обновления Sansec подтвердили второй, независимый путь эксплуатации для той же кампании с Rust-имплантом: даже магазины, перенёсшие хранение сессий с Redis на базу данных, всё равно были скомпрометированы — вторая попытка того же оператора увенчалась успехом через несколько секунд, используя файл, загруженный через функцию пользовательских опций клиента Magento. Перенос хранения сессий сам по себе не является исправлением.

Отдельно, 7 сентября, Sansec обнаружил совершенно несвязанного атакующего, использующего ту же самую точку входа StyleSmuggler для гораздо более простой нагрузки: PHP web shell, размещённый в собственном кеше изображений продуктов Magento (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), которому предшествовал разведывательный зонд, скрывающий свою нагрузку в HTTP-заголовке Store: и экфильтрирующий результаты через DNS, а не через HTTP-ответ. По словам Sansec, это «готовый инструментарий» — не устойчивая кампания — но это означает, что один уязвимый хост может нести два несвязанных вторжения через одну уязвимость. Очистка Rust-импланта не означает, что ваш магазин чист.

Сам Rust-имплант также эволюционировал: за оригинальной сборкой, маскирующейся под [kworker/u:8:0] (4 сент.), последовала сборка v2.1.4, маскирующаяся под fc-cache (6 сент.), которая передаёт сигналы, замаскированные под NTP-трафик, а затем повторное развёртывание v2.1.5, маскирующееся под chronyd (7 сент.), того же импланта, с тем же ID агента — доказательство того, что атакующий активно итерирует, чтобы обойти любые публикуемые вами обнаружения. Sansec заявляет, что пока не видел доказательств того, что этот имплант был вооружён за пределами постоянства/разведки — не воспринимайте это как успокоение, учитывая работающий web shell несвязанного атакующего на том же пути доступа.

См. docs/FAQ.md для быстрых ответов, docs/VULNERABILITY.md для полного технического описания и источников, docs/PATCHING.md для применения официального исправления Adobe и docs/INCIDENT_RESPONSE.md для того, что делать, если сканер что-то найдёт.

Быстрый старт

1. Установите патч, если ваша версия покрыта:

2. Просканируйте на предмет существующей компрометации независимо от статуса патча — патчинг останавливает новую эксплуатацию, но не очищает существующий бэкдор или web shell:

Или версия на Python для структурированного (JSON) вывода, например, для передачи в SIEM:

Оба скрипта по умолчанию только для чтения — они обнаруживают и сообщают, но не убивают процессы и не удаляют файлы, если вы не передадите --remediate, потому что преждевременная очистка уничтожает криминалистические доказательства (см. docs/INCIDENT_RESPONSE.md).

Что проверяет сканер

• Известные артефакты постоянства в файловой системе для всех трёх наблюдаемых сборок Rust-импланта:
  • Сборка [kworker/u:8:0]: ~/.local/share/.gvfsd/gvfsd-user, его файлы блокировок, /tmp/.kw_*, /tmp/.gvfsd_*
  • Сборка fc-cache v2.1.4 (6 сент.): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • Сборка chronyd v2.1.5 (7 сент.): /tmp/.chrony-<8hex>/chronyd
• Самовосстанавливающиеся записи crontab, которые имплант записывает напрямую в spool cron — каждые 5 минут для сборки gvfsd-user, дважды в час (13,43 * * * *) для fc-cache
• Маскирующийся процесс с именем [kworker/u:8:0], fc-cache или chronyd, который не принадлежит root (или, для fc-cache/chronyd, не совпадает с реальным системным бинарником)
• SHA-256 бинарников на диске и живого образа /proc/<pid>/exe (они могут отличаться — наблюдалось, что имплант обновляет себя в памяти)
• Отравленные файлы журналов/отчётов (var/log/system.log, var/report/) на предмет внедрённого PHP, двух известных форм триггерных заголовков (X-TRACE-<10hex> и X-<12hex>), а также маркеров кампании второго, несвязанного атакующего (ss5_/ss6_<hex>) и DNS-canary домена (oast.site)
• Маркеры ответа о подтверждении выполнения (MG<20hex>::...::/MG<20hex>), оставленные в журналах, когда нагрузка действительно выполнилась
• PHP-файлы в pub/media — которых никогда не должно быть в правильно настроенном магазине Magento — соответствующие паттерну сброса web shell вторым атакующим
• Установленные соединения с опубликованными C2/хостами загрузки — включая сигналы сборки fc-cache/chronyd, замаскированные под NTP, на ntp.timesync.to:123/UDP (и запасные варианты), а также её обычные HTTP-вызовы к публичным сервисам определения IP
• Аномальные количества локальных подключений к Redis (наблюдался сбор сессий полностью через 127.0.0.1:6379 с нулевым исходящим C2-трафиком — тихая сеть не означает чистую) — и обратите внимание, что перенос сессий с Redis сам по себе не закрывает второй вектор эксплуатации через загрузку файлов

Полный список индикаторов с источниками: iocs/.

Патчинг и смягчение последствий

1. Примените официальный горячий фикс Adobe (VULN-39341 / APSB26-146), если ваша версия покрыта — см. docs/PATCHING.md для идентификаторов, где его получить и как применить. Теперь это приоритет, опережающий временные меры ниже.
2. Если вы не можете установить патч немедленно или ваша версия не покрыта, используйте временные меры в mitigations/:
   • Заблокируйте или ограничьте по скорости путь доставки styles[] в GraphQL (nginx / Apache)
   • Заблокируйте выполнение PHP в pub/media/pub/static (nginx / Apache) — точечная защита от техники web shell второго, несвязанного атакующего
   • Правила ModSecurity для проверки тела POST-запросов и fail2ban как реактивный запасной вариант
   • См. mitigations/README.md для ограничений области действия — ни одна из этих мер не закрывает вектор пользовательских опций клиента или доставку через заголовок Store: второго атакующего.
3. Запустите сканер компрометации независимо от статуса патча/мер. Патчинг и смягчение останавливают новую эксплуатацию; ни то, ни другое не очищает уже размещённый бэкдор или web shell.
4. Если сканер что-то нашёл, считайте хост полностью скомпрометированным, а не просто «с бэкдором». Выполнение кода от имени пользователя сайта раскрывает всё, что этот пользователь может прочитать, начиная с app/etc/env.php. Как минимум, после сдерживания: очистите хранилище сессий (Redis и/или БД), ротируйте crypt/key Magento, все пароли администраторов (и аннулируйте существующие административные сессии), пароль базы данных, все API-ключи платёжных провайдеров и другие интеграционные учётные данные в env.php, а также любые SSH/деплой-ключи, которые мог прочитать пользователь сайта. Также проверьте таблицу admin_user на наличие подставного аккаунта и pub/media/ / pub/static/ / каталоги тем на предмет размещённых web shell — как Rust-импланта, так и несвязанного второго атакующего — прежде чем считать магазин чистым. Полный упорядоченный список шагов: docs/INCIDENT_RESPONSE.md.

Структура репозитория

Часто искомые термины

CVE-2026-75650, APSB26-146, VULN-39341, Magento zero-day 2026, Adobe Commerce zero-day, StyleSmuggler patch, Magento GraphQL vulnerability, Magento styles parameter RCE, gvfsd-user malware, fc-cache Magento backdoor, chronyd Magento malware, Magento kworker process malware, Magento Redis session hijack, Magento unauthenticated RCE September 2026, Magento 2.4.9 exploit, Adobe Commerce backdoor removal, Magento pub/media web shell, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Источники и происхождение

Каждый индикатор в этом репозитории восходит к цитируемому, опубликованному источнику — в первую очередь к рекомендации Sansec (обновлявшейся как минимум до 2026-09-07 20:50 UTC), бюллетеню Adobe APSB26-146 и отчётам сообщества об инцидентах от реагирующих, которые обрабатывали живые заражения. См. цитату внизу каждого файла в iocs/.

Не рассматривайте что-либо здесь как исчерпывающее или окончательное. IOC (триггерные заголовки, строки user-agent, маскировки импланта и теперь маркеры кампании второго атакующего) уже менялись несколько раз в течение дней после раскрытия; ожидайте, что они изменятся снова. Сопоставляйте формы и поведение, а не только буквальные строки, везде, где скрипты вам это позволяют.

Вклад в проект

Видели вариант, новый хэш, новый адрес источника или ложное срабатывание? Откройте issue или PR с тем, что вы наблюдали и как вы это наблюдали. Пожалуйста:

• Замаскируйте идентифицирующие детали вашей организации перед публикацией.
• Не публикуйте здесь эксплойт-нагрузки или рабочие триггерные запросы — только индикаторы и логику обнаружения.
• Сообщайте о самой уязвимости в Sansec и Adobe PSIRT, а не в этот репозиторий.

Лицензия

MIT для кода в этом репозитории (см. LICENSE). Данные индикаторов предоставляются «как есть» для оборонительного использования, с указанием источников по всему тексту.

Отказ от ответственности

Это неофициальный, созданный сообществом оборонительный инструментарий, а не продукт Adobe или Sansec, и он не аффилирован ни с одним из них. Он предоставляется без гарантий. Официальный патч Adobe (APSB26-146) выпущен, но покрытие ограничено конкретными версиями продуктов — проверяйте бюллетень безопасности Adobe напрямую, прежде чем предполагать, что ваша установка покрыта или исправлена.