Новооткрита уязвимост от тип нулев ден (zero-day) в Magento Open Source и Adobe Commerce се експлоатира активно от атакуващи за поемане на пълен контрол върху онлайн магазини, като все още няма налична официална корекция за сигурност.

Нидерландската фирма за сигурност на електронната търговия Sansec разкри уязвимостта, наречена StyleSmuggler, на 5 септември 2026 г., предупреждавайки, че неавтентифицирани киберпрестъпници могат да постигнат отдалечено изпълнение на код (RCE) върху уязвими инсталации и че атаките в реално време са започнали ден по-рано.

Компанията заяви, че публикува констатациите си по-рано, преди да завърши пълния си технически анализ, „тъй като магазините биват компрометирани точно в този момент“.

StyleSmuggler засяга всяка актуална версия на Magento и Adobe Commerce, включително последната версия 2.4.9, и не изисква никаква автентификация за експлоатация.

Sansec възпроизведе пълната верига от атаки без автентификация върху чисти инсталации на Magento Open Source 2.4.7, 2.4.8 и 2.4.9, потвърждавайки, че проблемът не е свързан с една остаряла версия.

Тревожно е, че първата идентифицирана жертва е използвала версия 2.4.6-p15 с напълно приложени корекции за сигурност от юли и август 2026 г., което означава, че напълно обновените магазини са били компрометирани също толкова лесно, колкото и пренебрегваните.

Към 6 септември Adobe не е издала бюлетин за сигурност, не е назначила CVE идентификатор и не е пуснала официално отстраняване на уязвимостта или временно решение, а най-новият бюлетин за сигурност на Commerce все още е от 11 август.

Експлойтът се разгръща на два отделни етапа, които злоупотребяват със собствените системи за рендиране на шаблони и имейли на Magento, вместо с една очевидна точка за инжектиране. На първия етап атакуващите внедряват зловреден PHP код във файл, който Magento сама записва по време на нормална работа (като доклад за неуспешно плащане), чрез манипулиране на свойствата на „styles“ в GraphQL заявка, за да заобиколят съществуващата санитаризация на входните данни.

Независим анализ от хостинг фирмата за Magento Disrex Group, която е обработила два компрометирани магазина, установи, че модифицирана директива във инжектирания текст принуждава верига от собствени класове на Magento да изпълни код, който е бил предназначен за изпълнение само през компилатора за внедряване на зависимости в командния ред, включвайки в крайна сметка инфектирания от атаката лог файл.

Вторият етап задейства изпълнението. Sansec установи, че StyleSmuggler умишлено кара Magento да изпрати стандартния си имейл „Напомняне за неуспешна платежна транзакция“, а злонамереният код се стартира в момента, в който Magento рендира това съобщение вътрешно, което означава, че никой не трябва да отваря или дори да получава имейла, за да успее атаката.

След като бъде задействан, PHP дропър преминава през шест различни PHP функции, докато намери такава, способна да създаде процес, след което изтегля и стартира персистентен зловреден код. Disrex описува зловредния софтуер като малък, статично свързан Rust двоичен файл от около 1,9 мегабайта, компилиран за x86-64 и ARM64 архитектури, маскиран като нишка на Linux ядрото с име „[kworker/u:8:0]“ и рестартиран на всеки пет минути чрез cron запис, записан директно във файла за планиране на crontab, за да избегне оставянето на нормални системни логове.

Откриването на инфекция е по-трудно, отколкото изглежда, тъй като зловредният софтуер активно избягва елементарни проверки. Истинска нишка на Linux ядрото е собственост на root и не консумира оперативна памет, така че всеки скобен процес „[kworker]“, работещ под потребителския акаунт на самия уебсайт с реално използване на памет, е сериозен сигнал за аларма.

Disrex също така откри, че двоичният файл, работещ в паметта, понякога се различава от файла, намиращ се на диска, което означава, че защитниците трябва да генерират хеш както на файла, така и на активния процес, за да бъдат изчерпателни.

В един компрометиран магазин зловредният код изобщо не е правил изходящи интернет връзки, а вместо това е отворил 28 едновременни връзки към собствения Redis екземпляр на сайта, за да чете Magento сесийни данни в реално време, което му е позволило да работи почти невидимо за мрежовия мониторинг.

На насоките за откриване на Sansec търсят маркиращ низ в директорията var/report на Magento, но Disrex установи, че и двата компрометирани магазина всъщност са били заразени през var/log/system.log, което означава, че администраторите трябва да проверят и двете локации.

Тъй като следващата планирана актуализация за сигурност на Adobe е насрочена за 8 септември и няма потвърждение, че тя ще отстрани тази уязвимост, собствениците на магазини са принудени да разчитат на временни мерки. Sansec препоръчва временно пълно деактивиране на GraphQL за магазини, които не разчитат на headless или progressive web app решения, тъй като класическите и Hyvä теми обикновено не се нуждаят от него.

Disrex, изследователят по сигурност ProxiBlue и доставчикът Graycore независимо публикуваха неофициални корекции на кода, които защитават конкретни класове и функции на имейл шаблони в Magento, въпреки че и трите страни подчертават, че това са мерки за защита, а не пълно отстраняване на уязвимостта, а Disrex конкретно предупреждава, че нейните правила блокират само текущия модел на трафик на атаката, но не и основната уязвимост.

Защитите на ниво сървър, които не зависят от разбирането на цялата верига на експлоайта, като деактивиране на PHP функцията proc_open и монтиране на временни директории с опция noexec, също са се доказали като ефективни за спиране на дропъра.