Cloudflare выпустил экстренную защиту от zero-day RCE в Magento и Adobe Commerce

Cloudflare выпустил экстренное правило WAF для Adobe Commerce и Magento Open Source 10 сентября 2026 года. Причина — активно эксплуатируемая уязвимость CVE-2026-75650, которую Cloudflare называет StyleSmuggler. Проблема позволяет неаутентифицированному атакующему добиться удалённого выполнения кода.

Для владельцев интернет-магазинов это не тот случай, когда можно ограничиться просмотром новостей и отложить обновление. Cloudflare прямо описывает новую сигнатуру как немедленную edge-защиту и виртуальный патч, но одновременно требует срочно обновить сам Adobe Commerce/Magento и проверить потенциальную компрометацию.

Что произошло 10 сентября

В официальном changelog Cloudflare появилась emergency-запись о новом правиле Cloudflare Managed Ruleset для CVE-2026-75650. Правило сразу работает с действием Block и предназначено для обнаружения атак на Adobe Commerce и Magento Open Source.

Cloudflare сообщает, что уязвимость связана с некорректной нейтрализацией специальных элементов в шаблонизаторе. Специально сформированные значения style-свойств могут использоваться для внедрения PHP payload, выполнения системных команд и закрепления вредоносного кода на сервере.

Adobe подтверждает эксплуатацию CVE-2026-75650

Adobe выпустила бюллетень APSB26-146 7 сентября и присвоила обновлению приоритет 1. В документе указано, что уязвимость критическая, может привести к выполнению произвольного кода и уже эксплуатируется в реальных атаках.

В список затронутых входят поддерживаемые ветки Adobe Commerce, Adobe Commerce B2B и Magento Open Source до соответствующих августовских сборок 2026 года включительно. Поэтому проверять нужно не только крупные проекты Adobe Commerce, но и обычные магазины на Magento Open Source.

Что делает новое правило Cloudflare WAF

WAF находится перед origin-сервером и анализирует входящие HTTP-запросы. Новая сигнатура пытается распознать запросы, характерные для эксплуатации этой конкретной RCE, и заблокировать их до того, как они попадут в Magento.

• правило добавлено в Cloudflare Managed Ruleset;
• оно предназначено именно для CVE-2026-75650;
• действие нового правила — Block;
• защита работает на edge и снижает риск успешной эксплуатации через публичный веб-трафик.

Это полезно для проектов, которым требуется время на тестирование hotfix, но такой слой нельзя считать окончательным исправлением.

Почему WAF не заменяет обновление Magento

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

Cloudflare прямо рекомендует применить hotfix из APSB26-146. Практически правильный порядок — включить защиту на edge как срочную меру, затем обновить origin, проверить магазин после обновления и только после этого считать техническую часть исправления завершённой.

Почему после патча нужна ротация секретов

Отдельно важно, что Cloudflare рекомендует немедленно заменить потенциально раскрытые encryption keys, integration tokens и системные учётные данные. Причина проста: патч закрывает путь для новой эксплуатации, но не отменяет действия атакующего, если тот уже получил выполнение кода.

После RCE злоумышленник потенциально может читать конфигурационные файлы, получать доступ к секретам интеграций, создавать постоянные механизмы доступа или модифицировать приложение. Поэтому исправление уязвимости и incident response — разные задачи.

Как проверить, что Cloudflare действительно защищает магазин

Само использование Cloudflare DNS недостаточно. Запись должна быть проксирована через Cloudflare, Managed WAF должен быть включён для нужной зоны, а пользовательские overrides не должны переводить критическую сигнатуру в Skip или Log.

После включения правила полезно проверить Security Events и убедиться, что запросы к origin нельзя отправить напрямую по известному IP в обход edge. Если origin доступен из интернета напрямую, WAF перестаёт быть полноценной границей защиты.

Что проверить после установки hotfix

Для интернет-магазина недостаточно убедиться, что главная страница открывается. Нужен smoke-test критического пользовательского пути: каталог, карточка товара, корзина, checkout, авторизация, личный кабинет, платежная интеграция, вебхуки и административные операции.

Также стоит проверить фоновые задания, интеграции с ERP/CRM, кэширование и кастомные модули. Security-fix часто устанавливается срочно, поэтому риск регрессии лучше закрывать коротким, но системным чек-листом.

Что делать, если есть признаки компрометации

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

Похожий принцип «WAF как дополнительный слой, а не замена исправлению» я разбирал в материале о Cloudflare WAF и критических RCE в Next.js. Для проектов на WordPress полезен и отдельный чек-лист по практической безопасности сайта: подход к обновлениям, резервным копиям и контролю доступа одинаково важен для любой CMS.

Итог

Релиз Cloudflare от 10 сентября — хороший пример оперативной виртуальной защиты: новое WAF-правило закрывает известный вектор CVE-2026-75650 на edge сразу после подтверждения активной эксплуатации. Но основной приоритет остаётся прежним: установить обновление Adobe, проверить магазин на следы вторжения и ротировать секреты, которые могли быть доступны атакующему.

Если веб-проекту нужна техническая проверка после критического обновления, настройка Cloudflare/WAF или аудит цепочки deployment и резервного восстановления, можно обсудить задачу с A.S Groups.