Патчи безопасности Magento: как ставить и проверять

Каждый второй вторник месяца Adobe выпускает исправления безопасности для Adobe Commerce и Magento Open Source. В октябре 2026 года среди них оказалась BlockStrap — уязвимость с оценкой 10.0, которая позволяет выполнить код на сервере магазина без авторизации. Обновиться «как обычно», одной командой Composer, в этот раз было нельзя: месячные исправления теперь приходят отдельными файлами патчей, и их нужно ставить по своим правилам. Разбираем, какие бывают исправления, как читать бюллетень, как ставить патчи и, главное, как убедиться, что они действительно применились.

Какие бывают исправления

Сейчас у Adobe три вида исправлений безопасности, и путать их опасно.

• Security-only релизы -pN (например, 2.4.8-p5). По политике Adobe они выходят раз в год для всех поддерживаемых веток и ставятся через Composer. Такой релиз включает все исправления безопасности, вышедшие до него.
• Ежемесячные изолированные патчи. Выходят во второй вторник месяца (Patch Tuesday) между релизами -pN. Это не пакет Composer, а файл с изменениями кода — только исправления конкретных уязвимостей. В бюллетенях исправленные версии обозначают по месяцу, например 2.4.9-2026-oct.
• Внеплановые хотфиксы. Когда уязвимость атакуют или вот-вот начнут атаковать, Adobe выпускает отдельный хотфикс, не дожидаясь месячного цикла. Так было в сентябре 2026 года с CVE-2026-75650 (StyleSmuggler, бюллетень APSB26-146).

Важная деталь: хотфикс не входит в месячный патч. В бюллетене октября Adobe прямо пишет, что хотфикс для CVE-2026-75650 нужно поставить отдельно, в дополнение к октябрьским исправлениям.

Как читать бюллетень APSB

Бюллетени Adobe называются APSBГГ-NNN и публикуются в Adobe Trust Center. Смотреть стоит на четыре вещи.

1. Приоритет. Priority 1 — действовать как можно быстрее, в течение 72 часов; Priority 2 — в течение 30 дней; Priority 3 — на усмотрение администратора. Приоритет — оценка Adobe, а не гарантия: BlockStrap получила Priority 2, хотя исследователи Sansec за сутки нашли четыре пути атаки.
2. CVSS. Оценка от 0 до 10. Всё, что выше 9, — повод не ждать конца месяца.
3. «Authentication required to exploit?» Если в этой колонке «No», атаковать может любой посетитель сайта, без входа в админку. Это самые опасные уязвимости.
4. Затронутые и исправленные версии, а также примечания: нужен ли модуль B2B, есть ли обязательный хотфикс из прошлых бюллетеней.

Шаг 0: стенд и резервная копия

Adobe настоятельно советует сначала ставить патчи на тестовом стенде и иметь свежую резервную копию. На практике это значит:

• копия магазина с той же версией Magento, PHP и модулей, что на продакшене;
• резервная копия базы и кода перед установкой — на стенде и на продакшене;
• код магазина в Git, чтобы патч был отдельным коммитом и его можно было откатить;
• понятное окно работ и режим обслуживания: bin/magento maintenance:enable перед изменениями и bin/magento maintenance:disable после.

Шаг 1: перейти на последний релиз -pN

Изолированные патчи тестируются только на последнем security-only релизе своей ветки. Если магазин на 2.4.8-p2, а последний — 2.4.8-p5, сначала нужно обновиться до p5 через Composer: поменять версию пакета Magento в composer.json, выполнить composer update, затем bin/magento setup:upgrade, bin/magento setup:di:compile и bin/magento setup:static-content:deploy. Сторонние модули тоже проверяем на совместимость: чаще всего обновление ломают именно они.

Шаг 2: поставить изолированные патчи по порядку

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

• Файлы скачиваются с repo.magento.com для вашей версии; для 2.4.6 и старше нужны ключи доступа Composer.
• В архиве лежат отдельные файлы для компонентов: Community Edition, Adobe Commerce, B2B, Page Builder. Ставятся только те, что у вас установлены. Порядок для Adobe Commerce: CE и EE прошлого месяца, затем CE и EE текущего; файлы B2B — после CE и EE.
• На своём сервере и для Magento Open Source файл кладут в корень проекта и применяют командой patch -p1 < имя_патча.patch (если не подходит — -p2), затем сбрасывают кеш.
• На Adobe Commerce Cloud файлы кладут в папку m2-hotfixes в корне проекта, коммитят и пушат — патч применится при деплое. Но если исправление уже пришло в пакете Cloud Patches, изолированный патч ставить не нужно: Adobe предупреждает, что это может сломать установку.

Мы применяем патчи не прямо на сервере, а через репозиторий — например, через cweagans/composer-patches или папку патчей в проекте. Так патч переживёт следующий composer install, и его видно в истории.

Шаг 3: проверить, что патч действительно применился

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

• Commerce Version Tool. Инструмент Adobe для проверки патчей: php vendor/bin/patch-status из корня проекта. Он показывает applied_patches, missing_patches и статус по каждой CVE в vulnerability_status: PROTECTED, VULNERABLE или UNKNOWN. Если команда php vendor/bin/patch-status --version не находит инструмент — значит, не стоит июльский патч 2026 года, с которым он появился.
• Quality Patches Tool на Cloud. Отдельный патч проверяется командой vendor/bin/magento-patches -n status с фильтром по имени патча — нужный статус «Applied».
• Проверка на продакшене. Запустите проверку там, где работает магазин, а не только на стенде, и сравните результат.

Пример, почему это важно: 16 октября Adobe обновила октябрьский патч для 2.4.8-p5, оставив прежнее имя файла. Магазины с первой версией патча Commerce Version Tool может показать как UNKNOWN, а в missing_patches появится 248p5-2026-10-002-CE. По словам Adobe, первая версия уже закрывала саму уязвимость, но рекомендация — откатить старый файл и поставить новый.

Шаг 4: проверить магазин после установки

Патчи безопасности меняют ядро, а BlockStrap, например, исправлялась в движке шаблонов писем. После установки проверяем то, что приносит деньги:

1. Оформление заказа целиком: корзина, доставка, оплата каждым подключённым способом, страница «Спасибо».
2. Письма: подтверждение заказа, регистрация, сброс пароля. Если письма перестали приходить или пришли с пустыми блоками — проблема в шаблонах.
3. Вход в админку, сохранение товара, работа кастомных модулей и интеграций (ERP, склад, CRM).
4. Логи var/log и логи веб-сервера в первые часы после выкладки.

Если магазин могли взломать

Если уязвимость с оценкой 9–10 была открыта, когда по ней уже шли атаки, одного патча мало: он закрывает дверь, но не выгоняет того, кто уже вошёл. В таком случае мы проверяем сервер на следы взлома (новые файлы PHP, изменения в шаблонах, неизвестные администраторы, внедрённый в оформление заказа JavaScript), меняем ключ шифрования Magento и все связанные доступы: токены интеграций, ключи платёжных шлюзов, пароли администраторов и доступы к серверу.

Чек-лист

• Подписаться на бюллетени Adobe и проверять их каждый второй вторник месяца.
• Держать магазин на последнем релизе -pN своей ветки.
• Ставить месячные патчи и хотфиксы по порядку, через репозиторий, сначала на стенде.
• Проверять результат через patch-status на продакшене.
• После выкладки — тестовый заказ и проверка писем.

Подробнее о BlockStrap и октябрьском бюллетене — в нашей новости.

Мы работаем с Magento больше десяти лет и ставим патчи безопасности на магазины клиентов каждый месяц. Возьмём это на себя: проверим, каких патчей не хватает, поставим их на стенде, проверим оформление заказа и письма, выкатим на продакшен с планом отката и подтвердим результат через Commerce Version Tool.

Источники: политика ежемесячных изолированных патчей Adobe, инструкция Adobe по установке изолированного патча, статья Adobe об исправлениях APSB26-153, обновление патча для 2.4.8-p5, бюллетень APSB26-153.