StyleSmuggler: активний zero-day у Magento та Adobe Commerce

StyleSmuggler — назва, яку Sansec дала повідомленій активно експлуатованій zero-day вразливості Magento Open Source та Adobe Commerce. За даними дослідників, неавторизований зловмисник може отримати віддалене виконання коду (RCE) на сервері магазину. Sansec заявила, що експлуатація почалася 4 вересня 2026 року, а розкриття інформації відбулося 5 вересня. 2223

Це динамічна ситуація, а не завершений бюлетень від постачальника. Практичний висновок для власників магазинів: не варто вважати публічно доступне розгортання Magento захищеним лише тому, що до розкриття були встановлені всі оновлення. Слід звузити доступну для атаки поверхню, зберегти докази й перевірити системи на компрометацію, перш ніж покладатися на будь-яке тимчасове пом'якшення.

Що було відомо в перші дні після розкриття

Sansec повідомила, що проблема зачіпає всі актуальні версії, зокрема Magento Open Source 2.4.9, і що повний неавторизований ланцюжок атаки було відтворено на чистих інсталяціях Magento Open Source 2.4.7, 2.4.8 та 2.4.9. 22 У публічних повідомленнях також ішлося про жертву на 2.4.6-p15 із встановленими оновленнями безпеки за липень і серпень 2026 року. Це вказує, що попередня актуальність патчів не усувала щойно розкриту проблему. 32

Станом на матеріали, опубліковані 6 вересня, Adobe не випустила окремих для StyleSmuggler CVE, бюлетеня безпеки, патча або обхідного рішення. 23 Для Adobe Commerce as a Cloud Service виробничий реліз був запланований на 8 вересня, але сам графік релізу не підтверджував, що він міститиме виправлення StyleSmuggler. 8

Ці дати відображають лише початковий період розкриття. Перед рішенням щодо патчів перевірте актуальні бюлетені безпеки та примітки до релізів Adobe.

Як, за повідомленнями, працює атака

За даними Sansec, зловмисник використовує властивості styles у неавторизованому введенні GraphQL, щоб обійти наявні захисні механізми й впровадити контрольований PHP-код у процеси Magento, пов'язані з шаблонами. Ланцюжок описано як двоетапний: спершу код записується до згенерованого Magento вмісту, наприклад звіту про помилку; далі отруєний вміст виконується під час рендерингу листа про невдалу оплату. 22

Сповіщення Payment Transaction Failed — це звичайна налаштовувана функція листів у Commerce. 18 У заявленому сценарії критичним моментом є серверний рендеринг шаблону, а не відкриття листа одержувачем. Це важливо для реагування: підозріла активність навколо невдалих оплат може бути релевантною, навіть якщо лист не було доставлено або ніхто його не відкривав.

У відкритих публікаціях після експлуатації описували встановлення постійного Linux-бекдора, маскування процесів під назви на кшталт kworker і закріплення через cron. 2035 Це корисні орієнтири для пошуку, але не вичерпний і не постійний перелік індикаторів: оператори атаки можуть змінити назви файлів і процесів, шляхи та мережеву інфраструктуру.

Які твердження поки не мають незалежного підтвердження

Деякі звіти з інцидентної розвідки містили додаткові твердження — зокрема про викрадення сесійних даних із Redis без помітного трафіку до сервера керування та про уникнення пошуку за var/report/ через отруєння var/log/system.log. У наданих матеріалах немає відтворюваного аналізу зразків шкідливого ПЗ або другого незалежного криміналістичного джерела, яке б підтверджувало саме таку поведінку.

Тому ці відомості слід розглядати як неперевірені розвідувальні твердження, а не як встановлені факти. Це не зменшує потреби в розслідуванні: просто збирайте ширший набір доказів, а не лише Magento-звіти — дані хоста, процесів, cron, вебсервера, PHP-FPM, Redis, DNS і міжмережевого екрана.

Негайні пріоритети стримування

1. Обмежте публічний доступ до GraphQL

Якщо вітрина може працювати без публічного GraphQL, тимчасово вимкніть або заблокуйте /graphql. Якщо GraphQL критично необхідний бізнесу, обмежте доступ на рівні CDN, WAF або зворотного проксі: лише для потрібних клієнтів, операцій і шаблонів запитів. У публічних рекомендаціях Sansec вимкнення GraphQL названо негайним заходом за відсутності офіційного виправлення. 22

Це компенсувальний захід, а не доказ того, що сервер чистий. Поєднуйте його з розслідуванням.

2. Обережно застосовуйте екстрені пом'якшення

Sansec повідомила, що її правила Shield блокують обидві відомі стадії атаки. 22 Disrex також заявила про випуск екстрених патчів для блокування відомого ланцюжка, але застерегла: вони не усувають уже наявне зараження. 35

Будь-який сторонній патч або правило WAF потрібно перевірити, протестувати в staging-середовищі та розгортати через контрольований процес змін. Зберігайте такий захист, доки офіційне виправлення не буде протестоване й не підтвердить закриття відповідного шляху атаки.

3. Збережіть докази до очищення

Якщо компрометація можлива, до видалення файлів або перезапуску сервісів збережіть релевантні журнали та знімок стану хоста й процесів. Насамперед перевірте:

• запити вебсервера та зворотного проксі до /graphql, особливо нетипові POST-запити з styles;
• журнали PHP-FPM, застосунку, cron, облікового запису процесів, DNS і міжмережевого екрана;
• нетиповий обсяг листів про невдалу оплату або незвичну активність рендерингу шаблонів;
• нові чи змінені завдання cron, особливо команди, запущені від імені вебслужби;
• неочікувані дочірні процеси PHP-FPM, процеси, що маскуються під системні утиліти, і незнайомі виконувані файли у доступних для запису або прихованих шляхах;
• відкриті сокети та вихідні з'єднання від облікових записів вебсервера і PHP-середовища.

Не обмежуйте збір даних директорією var/report/ чи журналами застосунку Magento. Навіть без навмисного втручання ці джерела можуть бути неповними.

Як зменшити наслідки успішного зламу

Поки інцидент розслідується, корисні такі загальні заходи посилення захисту:

• запускайте вебсервер і PHP-воркери від окремого непривілейованого облікового запису з мінімально необхідним доступом до файлової системи;
• зробіть код застосунку доступним лише для читання для облікового запису середовища виконання; дозвольте запис тільки там, де Commerce дійсно цього потребує;
• за можливості забороніть виконання файлів із каталогів, доступних для запису: тимчасових, кешу, завантажень, media, log, report і generated;
• після перевірки сумісності розгляньте параметри монтування noexec, nodev і nosuid для тимчасових файлових систем або розділів з інтенсивним записом;
• обмежте вихідний трафік із хостів застосунку явним списком дозволених напрямків і налаштуйте сповіщення про несподівану DNS- або UDP-активність;
• не допускайте публічного доступу до Redis; використовуйте приватну мережу, належну автентифікацію та захист транспортного рівня;
• сповіщайте про нові записи cron, неочікувані процеси, породжені PHP-FPM, і зміни в артефактах розгортання.

Ці заходи не замінюють виправлення на рівні застосунку, але можуть обмежити закріплення зловмисника та спростити виявлення аномалій.

Якщо знайдено індикатори

Будь-який позитивний індикатор розглядайте як можливу повну компрометацію сервера. Ізолюйте хост, збережіть криміналістичні дані та замініть облікові дані, що могли бути доступні із середовища застосунку: дані адміністратора Magento та інтеграцій, API-секрети, облікові дані бази даних і Redis, секрети розгортання та SSH, а також дані платіжних провайдерів. За потреби для вашого середовища анулюйте клієнтські сесії.

У разі підтвердженого зламу безпечніше відбудувати систему з перевіреного образу або довіреної резервної копії, ніж видалити видимий бінарний файл і повернути той самий хост у роботу. Патч-пом'якшення може заблокувати повторне зараження, але не доводить, що наявний бекдор, викрадення облікових даних чи механізм закріплення вже усунено.

Головний висновок

Ключовий урок StyleSmuggler: щойно розкрита активно експлуатована атака може обходити рівень патчів Magento, який до того вважався актуальним. У початкове вікно розкриття найкращою відповіддю було скоротити або прибрати публічний доступ до GraphQL, розгорнути перевірений тимчасовий захист, шукати ознаки компрометації в телеметрії застосунку й хоста та бути готовими застосувати й перевірити офіційне виправлення Adobe, коли воно з'явиться. 222335