Критична уразливість PolyShell, виявлена фахівцями Sansec, відкрила небезпечне вікно можливостей для атак на всі актуальні версії Magento Open Source та Adobe Commerce 2.x. Проблема дає змогу зловмиснику без будь‑якої автентифікації завантажувати на сервер довільні файли, що створює умови для remote code execution (RCE), хранимих XSS‑атак і подальшого захоплення облікових записів адміністраторів та клієнтів.
PolyShell: уразливість завантаження файлів і роль REST API Magento
Коренева причина PolyShell пов’язана з REST API Magento, яке обробляє додавання товарів до кошика з кастомними опціями. Для опцій типу file платформа приймає об’єкт file_info з Base64‑кодуванням вмісту файлу, MIME‑типом та ім’ям. Після декодування файл зберігається у директорії pub/media/custom_options/quote/ на сервері, ніби це звичайний медіа‑ресурс, завантажений покупцем.
Критичність уразливості полягає в тому, що цей механізм завантаження доступний без авторизації. Достатньо сформувати коректний запит до REST API — і шкідливий файл опиняється у файловій системі магазину. Подальші наслідки залежать від конфігурації веб‑сервера та політик обробки статичних файлів.
Polyglot‑файли та технічний ланцюжок експлуатації PolyShell
Назва PolyShell відсилає до використання polyglot‑файлів — файлів, які одночасно коректно інтерпретуються як, наприклад, зображення та як виконуваний скрипт. Якщо веб‑сервер налаштовано небезпечно, такий файл може прийматися системою як картинка, але за прямим зверненням по URL фактично виконувати код на стороні сервера або у браузері відвідувача.
Типовий сценарій атаки через PolyShell
Типовий ланцюжок експлуатації виглядає так: атакувальник імітує через REST API додавання товару в кошик і у полі file_info надсилає Base64‑кодування polyglot‑файлу. Magento зберігає файл у pub/media/custom_options/quote/, після чого зловмисник звертається до нього напряму через веб‑сервер, використовуючи публічно доступний URL.
Якщо веб‑сервер помилково дозволяє виконання скриптів у медіа‑каталогах або неправильно обробляє певні розширення, завантажений файл може працювати як веб‑шелл з можливістю віддаленого керування системою. У «м’якшому», але не менш небезпечному варіанті файл містить храмимий XSS‑пейлоад, який виконується у браузері адміністратора, викрадає сесії, перехоплює платіжні дані або змінює контент сторінок.
Реакція Adobe, бюлетень APSB25‑94 та ризики RCE/XSS для бізнесу
За даними Sansec, Adobe вже підготувала виправлення і включила його до бюлетеня безпеки APSB25‑94. Наразі патч доступний у передрелізній гілці 2.4.9, однак окремі оновлення для чинних продакшн‑версій ще не випущено. Це створює небезпечний період, коли вразливість відома, механізми експлуатації обговорюються у кримінальних колах, а значна частина магазинів залишається без офіційного захисту.
RCE в інтернет‑магазині фактично означає повний контроль над сервером: встановлення бекдорів, створення прихованих адмін‑обліковок, модифікацію платіжних скриптів та підміну реквізитів оплати. Храмима XSS дозволяє вбудувати шкідливий JavaScript у панель адміністрування або вітрину магазину, що призводить до викрадення сесій, компрометації облікових записів та витоку чутливих даних покупців.
Масовий дефейс Magento‑сайтів і кампанія Typical Idiot Security
Паралельно з виявленням PolyShell компанія Netcraft зафіксувала масову хвилю дефейсу сайтів на базі Magento. Починаючи з 27 лютого 2026 року, на понад 7500 веб‑ресурсах були розміщені текстові файли з «підписом» атакувальника. У більшості випадків використовувався нік Typical Idiot Security, під яким також публікувалися докази взломів в архіві Zone‑H для демонстрації активності в підпільній спільноті.
Серед постраждалих опинилися піддомени й регіональні вітрини відомих брендів, включно з Asus, BenQ, Citroën, Diesel, FedEx, Fiat, Lindt, Toyota, Yamaha, а також низкою державних та університетських доменів. Сам по собі дефейс часто сприймається як «косметична» підміна контенту, проте він свідчить про повний контроль зловмисника над можливістю розміщення файлів і нерідко є лише першим етапом глибшої компрометації інфраструктури.
Зв’язок з уразливостями неавтентифікованого завантаження файлів
Експерти Netcraft припускають, що в ході цієї кампанії використовуються саме уразливості завантаження файлів без автентифікації, подібні за характером до PolyShell. Дослідники відзначають паралелі з уразливістю SessionReaper, виявленою восени 2025 року, яка також дозволяла атакувати Magento‑сайти через слабкі місця в механізмах сесій та обробки завантажень.
Практичні рекомендації: як захистити Magento та Adobe Commerce від PolyShell
1. Обмежте доступ до директорій завантаження. Заблокуйте прямий доступ до pub/media/custom_options/ на рівні nginx або Apache (через deny all чи аналогічні директиви) та переконайтеся, що у цій директорії повністю заборонено виконання скриптів, зокрема .php і .phtml.
2. Проскануйте файлову систему на веб‑шелли та бекдори. Перевірте каталог pub/media/custom_options/quote/ і всі медіа‑директорії на наявність підозрілих файлів: нетипових розширень, дивних назв, коду всередині «зображень». Використовуйте спеціалізовані сканери безпеки для веб‑додатків та актуальні антивірусні рішення.
3. Посильте конфігурацію веб‑сервера. Забезпечте, щоб у каталогах із медіа‑файлами взагалі не оброблялися виконувані типи файлів, а тип контенту визначався сервером коректно й не міг бути нав’язаний зловмисником через заголовки або розширення.
4. Обмежте та моніторте REST API. За можливості обмежте доступ до чутливих endpoint’ів за IP‑адресами, застосуйте WAF (Web Application Firewall), увімкніть детальне логування та регулярно аналізуйте запити, пов’язані із завантаженням файлів. Аномальні спроби завантаження потрібно розглядати як потенційний інцидент безпеки.
5. Плануйте якнайшвидше оновлення. Після виходу стабільного патчу Adobe важливо без затримок оновити Magento / Adobe Commerce, попередньо перевіривши оновлення у тестовому середовищі. Практика показує: кожен день зволікання з установкою критичних оновлень суттєво підвищує ймовірність успішної атаки.
PolyShell та хвиля дефейсів, пов’язаних з уразливостями неавтентифікованого завантаження файлів, наочно демонструють, що слабкі ланцюги в обробці медіа й REST API можуть призвести до повної компрометації інтернет‑магазину. Власникам та адміністраторам Magento‑платформ варто переглянути модель загроз, посилити конфігурацію веб‑серверів, регулярно проводити аудит безпеки та уважно стежити за бюлетенями Sansec, Adobe і Netcraft. Чим раніше будуть впроваджені превентивні заходи й офіційні патчі, тим менший шанс опинитися серед скомпрометованих онлайн‑майданчиків.
