Уязвимость на 10 из 10 в Magento и Adobe Commerce: что произошло на самом деле

Сначала прямой ответ: 4 сентября 2026 года злоумышленники начали эксплуатировать незакрытую уязвимость в Magento Open Source и Adobe Commerce, зарегистрированную как CVE-2026-75650 с оценкой критичности 10.0 — максимально возможной. Уязвимость позволяет выполнять команды на сервере магазина без входа в систему и вообще без каких-либо привилегий, а Adobe выпустила исправление вечером 7 сентября. Получается три полных дня, в течение которых магазины были открыты без какой-либо защиты. Именно поэтому установить патч недостаточно: если ваш магазин работает на этой платформе, разумно исходить из того, что вас могли скомпрометировать ещё до появления исправления, а правильная реакция — искать признаки вторжения и менять ключи шифрования и все учётные данные, а не установить обновление и спокойно заниматься своими делами.

Кого именно это касается

Список необычно широк, потому что в него входит и самая новая версия, доступная на момент обнаружения:

  • Magento Open Source и Adobe Commerce: версии с 2.4.4 по 2.4.9, включая все патч-обновления до августа 2026 года.
  • Adobe Commerce B2B: версии с 1.3.3 по 1.5.3, вплоть до обновления августа 2026 года.
  • Всё, что старше 2.4.4: уже без поддержки и самая опасная категория, потому что официальный хотфикс её не покрывает.

Проще говоря: если на 1 сентября у вас был полностью обновлённый Magento, вы были уязвимы. Это не привычный сценарий халатности, о котором мы обычно предупреждаем, а настоящий zero-day, опередить который не было возможности ни у кого.

Как работает атака без пароля

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

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

Что злоумышленники оставили внутри

Здесь и видна разница между вандалом и организованной операцией. Обнаруженная вредоносная нагрузка — это не шумные записки вымогателей, а тихие инструменты закрепления в системе:

  • Бэкдор, написанный на Rust, который маскируется под один из процессов ядра операционной системы, чтобы не выделяться для того, кто бегло просматривает список процессов.
  • Замаскированный трафик управления через порт синхронизации времени, так что в сетевых журналах эта активность выглядит как обычная подстройка часов.
  • PHP веб-шеллы, записанные в папки кэша изображений товаров, — места, которые обычно никто не проверяет, потому что они забиты временными файлами.
  • Дополнительные средства удалённого доступа от второго злоумышленника с не связанными с первыми инструментами, а значит, уязвимость эксплуатировали сразу несколько групп.

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

Почему установки обновления недостаточно

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

Патч останавливает кровотечение. Смена ключей — вот что выставляет незваного гостя из дома.

Практический план действий для владельца магазина

  • Первое — убедитесь, что исправление действительно установлено, а не что кто-то сказал, что оно установлено. Попросите команду показать доказательство из журнала патчей на самом сервере, а не успокаивающее сообщение.
  • Второе — проверьте следы вторжения: подозрительные запущенные процессы с именами, имитирующими системные, PHP-файлы в папках с медиа и изображениями и необычные файлы отчётов об ошибках.
  • Третье — просмотрите журнал исходящих писем. Резкий всплеск писем-напоминаний о неудачной оплате — прямой признак попыток эксплуатации, и его может распознать любой руководитель операционного отдела без глубоких знаний в безопасности.
  • Четвёртое — смените каждый ключ без исключения, в первую очередь учётные данные платёжного шлюза. Для этого нужно запланированное окно обслуживания, а не импровизированное решение в часы пик.
  • Пятое — если ваша версия старше 2.4.4, перестаньте ждать официальный патч, который не выйдет. Составьте план обновления с реальной датой, а до тех пор поставьте магазин за межсетевой экран веб-приложений.
  • Шестое — задокументируйте, что вы сделали. Если окажется, что данные клиентов утекли, вам понадобится хронология того, что и когда вы делали.

Регуляторный аспект в Саудовской Аравии: данные клиентов — не только технический вопрос

Интернет-магазин, который хранит имена, адреса, номера мобильных телефонов и историю заказов клиентов, обрабатывает персональные данные, подпадающие под Закон о защите персональных данных. Утечка не остаётся внутренним делом магазина и его хостинг-провайдера: она порождает обязательства перед компетентным органом и перед самими субъектами данных. Поэтому сегодня владельцу магазина стоит спрашивать не только «пропатчен ли сервер», но и «могу ли я доказать, что данные моих клиентов не пострадали».

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

Как мы справляемся с такими инцидентами в Origami

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

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

Источники

  • Официальное объявление Adobe Commerce об обновлении безопасности APSB26-146 и срочном хотфиксе: experienceleague.adobe.com
  • Технический анализ Sansec по CVE-2026-75650 и индикаторам компрометации: sansec.io/research/stylesmuggler-0day
  • Каталог известных эксплуатируемых уязвимостей CISA: cisa.gov
  • Закон о защите персональных данных (PDPL) — Саудовское управление по данным и искусственному интеллекту (SDAIA): sdaia.gov.sa