Adobe выпустила экстренный хотфикс для CVE-2026-75650 — критической уязвимости в Adobe Commerce и Magento Open Source, которая позволяет выполнять произвольный код удалённо и без аутентификации. Adobe оценивает проблему в 10,0 балла по CVSS и сообщает, что уязвимость уже эксплуатируется в реальных атаках. Австралийский центр кибербезопасности и Агентство кибербезопасности Сингапура также призвали затронутые организации немедленно установить исправление.

Редакционная иллюстрация кибербезопасности: интернет-магазин защищён патчем и щитом от сетевых угроз

Для владельца магазина важно различать две задачи: закрыть уязвимость и доказать, что сайт не был скомпрометирован ранее. Первая относится к обслуживанию программного обеспечения. Вторая — к реагированию на инцидент. Магазин, доступный для атак в период эксплуатации, нельзя считать чистым только потому, что теперь его версия выглядит исправленной.

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

Какие системы затрагивает CVE-2026-75650

CVE-2026-75650 — это ошибка нейтрализации данных в шаблонизаторе. Adobe классифицирует её последствия как выполнение произвольного кода, указывает, что аутентификация не требуется, и присваивает уязвимости базовую оценку 10,0 по CVSS 3.1. Такой балл отражает возможность сетевой атаки без специальных привилегий и взаимодействия пользователя, а также потенциально высокий ущерб для конфиденциальности, целостности и доступности.

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

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

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

Почему сроки меняют порядок действий

Adobe опубликовала бюллетень APSB26-146 7 сентября 2026 года и присвоила проблеме высший приоритет. В бюллетене сказано, что компания располагает информацией об эксплуатации уязвимости в реальных условиях. Sansec, разместившая исследование 5 сентября, сообщила, что наблюдала атаки начиная с 4 сентября, и на момент раскрытия описала проблему как уязвимость нулевого дня с удалённым выполнением кода без аутентификации. 13 сентября страница Sansec была обновлена; в ней говорится, что экстренное исправление вышло через три дня после первой подтверждённой эксплуатации.

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

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

Первое решение: установить исправление или ограничить доступ

Если магазин затронут и хотфикс можно безопасно применить, немедленно следуйте инструкциям Adobe по установке исправления для CVE-2026-75650. Sansec называет исправление Adobe хотфиксом VULN-39341, который поставляется как патч Composer. Конкретный пакет, поддерживаемый выпуск и способ развёртывания должны определяться примечаниями к выпуску Adobe и условиями поддержки магазина. Не используйте патч, скопированный из непроверенного сообщения на форуме, и не считайте обычный результат security:patch-status доказательством того, что экстренное исправление установлено.

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

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

С неподдерживаемыми ветками нужно обращаться особенно осторожно. Sansec сообщает, что проверенное Adobe покрытие хотфикса связано с поддерживаемыми выпусками 2026-August, и указывает: старые ветки также затронуты, но не проверены Adobe тем же образом. Если организация использует версию, снятую с поддержки, следует подключить сопровождающего Commerce или квалифицированного поставщика услуг реагирования, протестировать переход на поддерживаемую версию либо проверенный бэкпорт. Не стоит вносить непроверенное изменение в работающий магазин, который продолжает обслуживать заказы.

Установка хотфикса не завершает работу

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

Начните расследование с точной временной шкалы. Определите, когда каждый интернет-доступный экземпляр Commerce был уязвим, когда конечная точка /graphql была достижима, когда появились первые признаки подозрительных запросов, когда установили хотфикс и перезапускалось ли после этого приложение либо выполнялось ли повторное развёртывание. Включите журналы CDN, WAF, обратного прокси, балансировщика, веб-сервера, PHP-FPM, приложения, операционной системы, планировщика задач и облачного аудита. Используйте единый часовой пояс и сохраните исходные файлы до фильтрации или ротации.

Ищите признаки на нескольких уровнях, а не по одной сигнатуре. На периметре проверьте необычные запросы к GraphQL, серии запросов, не похожие на обычное поведение посетителей, неожиданные user-agent, повторяющиеся ошибки и трафик от хостинг-провайдеров или сетей, не связанных с легитимными клиентами. В приложении изучите изменения шаблонов, активность уведомлений о неуспешных платежах, неожиданные изменения CMS или конфигурации, новые учётные записи администраторов, изменения прав интеграций и необычные записи в каталоги отчётов, медиафайлов или кэша. На узле ищите новые процессы, новые задания планировщика, изменённые файлы запуска, неожиданные PHP-файлы и исходящие соединения, которые процесс Commerce обычно не устанавливает.

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

Не вставляйте конфиденциальные журналы, сведения о клиентах, данные сессий или значения секретов в публичные трекеры, когда просите о помощи. Передавайте Adobe, проверенному поставщику реагирования или соответствующему национальному органу кибербезопасности только минимальный объём очищенных данных. Сингапурская рекомендация направляет администраторов к бюллетеню поставщика и записи NVD, а австралийская указывает канал для помощи и сообщения об инцидентах.

Какие секреты может потребоваться сменить

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

В этот набор могут входить пароли администраторов, токены интеграций REST, SOAP и GraphQL, секреты OAuth-клиентов, реквизиты платёжного шлюза, пароли баз данных, ключи SSH, ключи развёртывания, облачные учётные данные и API-ключи сторонних расширений. Меняйте их в системах-источниках, а не только редактируйте значение в конфигурации Commerce. Например, изменение платёжного реквизита внутри магазина не делает старый ключ недействительным у платёжного провайдера: провайдер должен выпустить новый ключ или отозвать старый. Тот же принцип относится к облачному IAM, системе контроля версий, мониторингу, доставке и маркетинговым платформам.

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

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

Кто должен участвовать в реагировании

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

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

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

Командам безопасности следует рассматривать проблему одновременно как управление уязвимостью и реагирование на инцидент. Управление уязвимостью отвечает на вопрос, защищено ли программное обеспечение сейчас. Реагирование на инцидент выясняет, пострадала ли организация раньше. Разделение этих направлений предотвращает типичную ошибку, когда успешную установку патча принимают за завершённое расследование.

Какие выводы нельзя делать только по доступным данным

CVE-2026-75650 представляет серьёзную угрозу, но имеющиеся факты не позволяют утверждать всё подряд. Открытые сообщения подтверждают активную эксплуатацию и критический путь к выполнению кода без аутентификации. Они сами по себе не доказывают, что был взломан каждый магазин Magento, что у каждой жертвы украли платёжные данные или что за всей наблюдаемой активностью стоит одна конкретная группа. Такие выводы следует публиковать только при наличии доказательств из собственной среды.

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

Такая же осторожность нужна при оценке мер защиты. Правило CDN, сигнатура WAF, отключённая конечная точка или сетевое ограничение могут снизить риск, однако любой из этих механизмов может быть неправильно настроен или обойдён через альтернативный маршрут. Для компенсирующего контроля должны быть назначены ответственный, дата окончания действия и проверочный тест. Он не должен превращаться в постоянное оправдание для эксплуатации неподдерживаемой и неисправленной витрины.

Практическая последовательность реагирования

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

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

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

Главный урок для безопасности электронной торговли

Непосредственный вывод прост: нужно установить хотфикс Adobe. Более широкий вывод связан с разницей между чистым сигналом обновления и чистой средой. Уязвимая витрина может превратиться в проблему идентификационных и платёжных систем, если приложение имеет доступ к секретам, клиентским процессам и автоматизированным интеграциям. Граница безопасности проходит не только по пакету Commerce: в неё входят сервер, конвейер поставки, расширения, конечные точки, учётные данные и подключённые сервисы.

CVE-2026-75650 также показывает, почему экстренное исправление должно сопровождаться планом сохранения доказательств. Когда эксплуатация начинается до появления патча поставщика, организации нужно параллельно делать две вещи: сокращать оставшуюся поверхность атаки и выяснять, что происходило в период экспозиции. Такой подход даёт более спокойный и обоснованный результат, чем паническое отключение магазина или успокаивающее, но ничем не подтверждённое утверждение, будто после установки патча инцидент закончился.

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

Источники