Хакери Magecart перетворили Stripe на командний сервер: ідеальне маскування для крадіжки даних

Нова кампанія злому, розкрита компаніями Sansec та BleepingComputer у червні 2026 року, демонструє тривожний рівень маскування: хакерське угруповання Magecart перетворило власну інфраструктуру платіжної системи Stripe на командний сервер (C2) та канал витоку даних . Атака не завантажує код з жодного шкідливого домену. Натомість, завантажувач, корисне навантаження (скімер JavaScript) і викрадені платіжні дані передаються виключно через googletagmanager.com та api.stripe.com — два домени, настільки критично важливих для сучасної електронної комерції, що жоден інтернет-магазин їх не блокує і навіть не перевіряє уважно . Паралельно з цим активно використовується інша серйозна вразливість — CVE-2026-3300 у популярному плагіні Everest Forms Pro для WordPress, яка дозволяє неавтентифікованим зловмисникам виконувати довільний PHP-код і повністю захоплювати контроль над сайтом .

Як працює триетапна атака Magecart через Stripe

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

Етап 1: Ін’єкція завантажувача через Google Tag Manager

Спочатку зловмисники компрометують контейнер Google Tag Manager (GTM) на цільовому сайті. Вони впроваджують шкідливий тег, який завантажується на кожній сторінці, включаючи сторінки оформлення замовлення. Оскільки скрипт походить з домену googletagmanager.com — добре знайомого і цілком довіреного для систем аналітики, — він без жодних перешкод оминає типові Політики безпеки контенту (CSP) та блокувальники реклами, не викликаючи жодних сповіщень . Таким чином, GTM стає ідеальним та неблокованим механізмом доставки, свого роду троянським конем у світі веб-аналітики.

Етап 2: Отримання скімера з API Stripe

На цьому етапі замість того, щоб звертатися до якогось підозрілого стороннього сервера, тег GTM робить запит до api.stripe.com. Саме там зловмисники зберігають повноцінний шкідливий JavaScript-скімер. Вони розміщують його в полі метаданих клієнта (Customer metadata field) у власному обліковому записі Stripe, використовуючи секретний ключ тестового режиму (sk_test_...) для запису та подальшого зчитування коду . Скімер завантажується з домену, який власники магазинів не просто вважають безпечним, а й критично необхідним для роботи їхнього платіжного стеку. Через це мережевий моніторинг та CSP-правила вкрай рідко позначають такі API-виклики як підозрілі.

Етап 3: Ексфільтрація вкрадених даних назад до того ж облікового запису Stripe

Коли покупець вводить дані кредитної картки, особисту інформацію та платіжну адресу на сторінці оформлення замовлення, впроваджений скімер перехоплює ці дані. Після цього він відправляє їх назад до облікового запису зловмисників у Stripe через той самий API, записуючи інформацію у вигляді фіктивних записів клієнтів (Customer records) або нових метаданих . Оскільки весь трафік для витоку даних прямує назад до api.stripe.com, він ідеально зливається з легітимними платіжними API-викликами, які постійно генерує сайт. Це робить крадіжку даних по суті невидимою для журналів брандмауера та інструментів виявлення аномалій, адже відрізнити злочинний запит від звичайного — надзвичайно складно .

За даними дослідників, вся ця операція була активною щонайменше з 24 грудня 2025 року .

Чому секретні ключі тестового режиму настільки небезпечні

Секретні ключі тестового режиму Stripe (sk_test_...) надають повний доступ на читання та запис у межах ізольованого тестового середовища (sandbox). Вони дозволяють безкоштовно створювати необмежену кількість фіктивних клієнтів, транзакцій та полів метаданих . Оскільки ці ключі ніколи не ініціюють справжніх списань коштів, їх нецільове використання дуже легко проґавити. Зловмисники розраховують на те, що багато організацій сприймають тестові ключі як малоризикові та не перевіряють активність у «пісочниці» з тією ж ретельністю, що й бойовий трафік.

Окремою, але пов’язаною загрозою є витік «живих» (live) секретних ключів. Це дало б атакуючому прямий доступ до реальних даних транзакцій, можливість оформлювати повернення коштів та навіть переказувати гроші . І хоча ця конкретна кампанія використовує тестові ключі для більшої скритності, принцип залишається тим самим: API-ключі Stripe в будь-якому режимі — це надзвичайно потужні облікові дані, які ніколи не повинні з’являтися у клієнтському коді, змінних Google Tag Manager або публічних репозиторіях .

CVE-2026-3300: Критичне віддалене виконання коду в Everest Forms Pro

Поки кампанія Magecart через Stripe націлена на процеси оформлення замовлень, власники сайтів на WordPress стикаються з не менш нагальною загрозою — вразливістю у плагіні Everest Forms Pro, яка активно експлуатується з 13 квітня 2026 року .

CVE-2026-3300 — це вразливість, яка дозволяє неавтентифікованим зловмисникам віддалено виконати довільний код (Remote Code Execution, RCE). Вона стосується плагіна Everest Forms Pro, який має близько 4 000 активних встановлень . Вразливість оцінюється у 9.8 бала за шкалою CVSS і впливає на всі версії аж до 1.9.12 включно .

Помилка криється у функції process_filter() в аддоні «Calculation» (Розрахунки). Коли ввімкнено функцію «Complex Calculation» (Складні обчислення), плагін бере значення, введені користувачем у текстові поля форми, безпосередньо вставляє їх у рядок PHP-коду і передає результат у функцію eval() без належного екранування . При цьому функція sanitize_text_field(), яка застосовується до вхідних даних, не нейтралізує одинарні лапки та інші символи, що мають спеціальне значення в контексті PHP-коду. Це дозволяє зловмиснику «вирватися» за межі призначеного рядка та впровадити довільні команди .

Компанія Wordfence заблокувала понад 29 300 спроб експлойту і повідомляє, що після успішної атаки зловмисники часто створюють несанкціоновані облікові записи адміністраторів . Власникам сайтів слід звертати увагу на такі ознаки компрометації: поява нових адміністраторів з неочікуваними іменами, незвичні файли на сервері або підозрілі вихідні мережеві з’єднання .

Захисні заходи проти обох загроз

Блокування ланцюжка атаки Magecart через Stripe

• Наведіть лад з Google Tag Manager. Обмежте контейнери GTM лише схваленими та перевіреними тегами і вимагайте суворого процесу погодження змін перед їх публікацією .
• Посильте Політику безпеки контенту (CSP). Не додавайте api.stripe.com до директиви script-src, якщо це не є абсолютно необхідним. Якщо доводиться це зробити, використовуйте хеші цілісності підресурсів (Sub-Resource Integrity, SRI). Блокування вбудованих скриптів (inline scripts) забезпечить додатковий рівень захисту .
• Проводьте аудит активності в тестовому середовищі Stripe. Відстежуйте у своїй панелі Stripe dashboard незвично велику кількість створення об’єктів Customer або записів метаданих із використанням ключів тестового режиму. Ставтеся до аномалій у «пісочниці» з тією ж серйозністю, що й до аномалій у бойовому режимі.
• Регулярно змінюйте та захищайте API-ключі. Ніколи не вставляйте секретні ключі Stripe — ні тестові, ні бойові — у клієнтський JavaScript, змінні GTM або публічні репозиторії . Негайно змініть будь-який ключ, який міг бути скомпрометований .
• Розгорніть моніторинг на стороні клієнта. Використовуйте перевірки цілісності на стороні браузера, які виявляють несанкціоновані маніпуляції з DOM на сторінках оформлення замовлення .

Усунення вразливості Everest Forms Pro

• Негайно оновіть плагін. Встановіть версію Everest Forms Pro 1.9.13 або новішу, яка містить виправлення .
• Вимкніть ризиковану функцію, якщо оновлення неможливе. Як тимчасовий захід, вимкніть функцію «Complex Calculation» у налаштуваннях плагіна. Це запобіжить експлуатації через неекранований ввід у eval() .
• Перевірте сайт на ознаки злому. Шукайте невідомі адміністративні облікові записи, неочікувані файли, підозрілі виклики eval() та вихідні мережеві з’єднання з незнайомими IP-адресами. Після усунення вразливості критично важливо виконати повну перевірку цілісності файлів ядра, теми та плагінів WordPress .