Хакеры начали атаковать магазины на Magento Open Source и Adobe Commerce через свежую необновлённую уязвимость. Она позволяет выполнить код на сервере без входа в админку и поставить скрытый бэкдор, который остаётся в системе после первой атаки.

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

Какую проблему решаем

Речь идёт о сценарии, когда злоумышленник получает контроль над сервером магазина и закрепляется там надолго. Sansec назвала уязвимость StyleSmuggler и сообщила, что атаки начались 4 сентября, а Adobe к 6 сентября ещё не выпустила ни бюллетень, ни исправление, ни временную меру.

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

Похожим образом устроены многие цепочки захвата инфраструктуры: сначала идёт скрытая точка входа, потом — закрепление и маскировка. О том, как такие атаки используют служебные процессы и журналы, мы уже подробно разбирали в материале о защите после инцидента PaperCut.

Что подготовить

Нужны доступ к серверу, права на просмотр журналов и список всех компонентов магазина: версия Magento, тип сборки, плагины, веб-сервер, cron-задачи, Redis и места, где хранятся логи. Если магазин обслуживает подрядчик, заранее попросите у него доступ хотя бы на чтение.

Ещё пригодятся свежая резервная копия и отдельный канал связи с командой разработки или хостингом. Если вы только собираетесь поднять рабочую среду для удалённой команды, сразу закладывайте шифрование трафика и защищённый канал для рабочих устройств, чтобы снизить риски при работе с админкой и внутренними сервисами вне офиса.

Пошаговые действия

Один. Проверьте версию и круг риска

Сначала выясните, на чём работает магазин: Magento Open Source или Adobe Commerce, а также точную версию и уровень патчей. Sansec сообщила, что под ударом находятся все текущие версии, включая 2.4.9, а в одном из подтверждённых случаев уязвимым оказался даже магазин с установленными июльскими и августовскими обновлениями 2026 года.

Это важная деталь: номер патча не гарантирует безопасность, если исправления ещё нет. Поэтому ориентируйтесь не только на номер версии, но и на фактические признаки компрометации.

Два. Ищите следы закрепления

Sansec описала вредоносный процесс под именем kworker/u:8:0, которое похоже на системный поток Linux. Обратите внимание на бинарник в каталоге ~/.local/share/.gvfsd/gvfsd-user, cron-запись с перезапуском каждые пять минут и любые новые файлы в домашних каталогах пользователей, а не в web root.

Отдельно проверьте var/report/ и var/log/system.log. По данным Disrex, заражение шло не только через маркер X_TRACE_, который упоминала Sansec, но и через system.log, поэтому искать нужно обе зоны.

Три. Сверьте журналы на признаки цепочки

В логах ищите странные заголовки вида X-TRACE- с набором шестнадцатеричных символов, а также ошибки TypeError после array_merge() с целым аргументом. Такие следы могут указывать на попытку включить подложенный файл и запустить PHP-код через штатные механизмы Magento.

Ещё один тревожный сигнал — резкое появление новых cron-заданий или повторяющихся строк в crontab. В одном из случаев вредоносная запись восстанавливалась за секунду после удаления и встречалась более тысячи раз.

Четыре. Ограничьте поверхность атаки

Пока разработчики ищут исправление, исследователи советуют временно отключить GraphQL, если это не ломает ваш магазин. Для классических витрин это часто допустимо, а для headless- и PWA-проектов — нет, поэтому решение нужно принимать вместе с разработчиком и хостингом.

Если вы работаете в браузере с админкой, внутренними панелями и тестовыми стендами, не смешивайте их с повседневным серфингом. Для таких задач удобно держать отдельный профиль доступа и заранее настроенный защищённый канал связи. Это особенно важно, если сотрудники заходят на серверы из дома, коворкинга или поездок.

Пять. Меняйте учётные данные и проверяйте сессии

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

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

Как проверить себя

После первичной проверки ответьте на три вопроса. Видите ли вы аномальные процессы и cron-задания, есть ли подозрительные записи в system.log и var/report/, а также совпадает ли версия Magento с той, которую уже затронула атака.

Если хотя бы на один вопрос ответ неясен, считайте инцидент незавершённым. Дальше нужны форензика, изоляция узла и полноценная смена паролей для всех сервисных учётных записей.

Что делать, если не получилось

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

Если магазин обслуживает подрядчик, попросите у него список всех изменений за последние 48 часов и снимок журналов. Параллельно подготовьте план отката из резервной копии, но только после сохранения доказательств инцидента.

Практический чек-лист

  • Проверить точную версию Magento Open Source или Adobe Commerce.
  • Просмотреть var/log/system.log и var/report/ на следы X-TRACE- и включения файлов.
  • Искать процесс kworker/u:8:0, файл gvfsd-user и новые cron-записи.
  • Сверить, не отключён ли GraphQL без согласования с разработкой.
  • Сменить пароли администраторов и сервисных аккаунтов.
  • Завершить все активные сессии и проверить список админов.
  • Сохранить журналы и образы подозрительных файлов до очистки.
  • Если вы управляете магазином через ноутбук вне офиса, держать рабочие подключения отдельно от личных.
Поделиться: