Витік даних SafePal: 39 798 записів клієнтів розкрито через уразливість плагіна
Кожен слюсар знає неприємну правду: найміцніший замок у світі не допоможе, якщо база даних клієнтів у підсобці розповідає злодіям, у яких будинках є щось цінне. SafePal щойно переконалась у цьому на власному досвіді. Гаманці витримали, плагін — ні, і тепер приблизно 40 000 людей, які купили апаратний гаманець саме для того, щоб залишатися непомітними, опинились у чиємусь списку.
Що сталося
У неділю виробник апаратних гаманців SafePal оголосив про витік даних, що торкнувся 39 798 клієнтів, які розміщували замовлення з 2 березня 2025 року по 11 квітня 2026 року. Як CoinDesk повідомив, викриті записи містили імена, фізичні адреси та контактні дані. Цього достатньо для дуже цільової фішингової кампанії або гірших дій.
Компанія чітко зазначила, що саме не потрапило у відкритий доступ: жодних сід-фраз, приватних ключів, банківських даних, посвідчень особи, паролів, номерів платіжних карток і, що найважливіше, жодних криптовалютних коштів. Самі гаманці залишилися недоторканими. Це був витік із магазину, а не зі сховища.
SafePal простежила першопричину до «уразливості авторизації» у плагіні відстеження замовлень клієнтів. Простіше кажучи, трекер, імовірно, дозволяв одному клієнту читати деталі замовлення іншого, маніпулюючи запитом. Змінив число — побачив чужий чек.
SafePal у той самий неділь розіслала листи всім постраждалим клієнтам з адреси [email protected], залатала уразливість, залучила незалежну стороню компанію для аудиту виправлення та всього ланцюжка обробки замовлень, а також зобов'язалась зберігати персональні дані в цій системі лише 90 днів із моменту збору надалі. Крім того, компанія виявила та видалила понад 30 шахрайських вебсайтів і фішингових посилань, пов'язаних із цим інцидентом, і розмістила інструмент перевірки на власному сайті, щоб користувачі могли перевірити, чи входять вони до числа постраждалих. Користувачам, які коли-небудь передавали сід-фразу або приватний ключ у відповідь на фішинговий запит, рекомендовано вважати гаманець скомпрометованим і перемістити активи.
Технічна анатомія
«Уразливість авторизації» у плагіні відстеження замовлень — це ввічливий спосіб описати те, що майже напевно є IDOR або близьким різновидом цієї вразливості. Insecure Direct Object Reference роками тримається у верхній частині списку OWASP і продовжує потрапляти у виробничі системи, бо це тип помилки, який виникає тоді, коли забувають написати код, а не коли пишуть поганий код.
Схема до прикрості проста. Клієнт входить у систему, звертається до ендпоінта на кшталт /api/orders/482913 і отримує своє замовлення. Сервер перевіряє наявність сесії, але ніколи не перевіряє, чи ця сесія є власником того ідентифікатора замовлення. Збільшив число — отримав чуже замовлення. Автоматизував цикл — отримав 39 798 замовлень. Будь-який фахівець, який перевіряв нову інтеграцію з e-commerce, знає, що саме цей режим відмови перевіряють першим, і саме він залишається непоміченим, коли плагін підключила команда зростання, якій просто потрібно було налаштувати сповіщення про доставку до запуску продукту.
Плагіни — повторюваний антагоніст у цій історії. Виробники апаратних гаманців цілком виправдано приділяють велику увагу прошивці, захищеному елементу та ланцюжку постачання самого пристрою. E-commerce стек, який фактично продає цей пристрій, зазвичай є інсталяцією Shopify або Magento з цвинтарем сторонніх розширень, що відповідають за відстеження, оподаткування, виконання замовлень та електронну пошту. Кожне з них — окрема поверхня аутентифікації, нерідко написана командою з двох осіб і майже ніколи не охоплена тією самою моделлю загроз, що й прошивка гаманця.
Інцидент із Coldcard, згаданий у тій самій публікації CoinDesk, де зловмисник нібито вивів щонайменше 120 мільйонів доларів у bitcoin, — це зовсім інша історія. Там були гроші. Тут — метадані. Але метадані — це карта, а карта перетворює опортуністичний фішинг на цільове виманювання. Дайте мені ім'я, фізичну адресу і підтвердження того, що людина володіє певним брендом апаратного гаманця, — і мені не потрібно гадати, кому надсилати лист із підробленим оновленням прошивки.
Хто постраждає
39 798 клієнтів несуть основний ризик. Їхні імена та адреси доставки тепер поширюються в будь-якому каналі, через який зловмисник продає дані, а кваліфікаційна ознака («ця людина є власником SafePal») вже вбудована. Очікуйте хвилю поштового фішингу, підроблених відправлень замінних пристроїв, фейкових дзвінків підтримки та особливо неприємного варіанту, коли хтось з'являється за фізичною адресою, представляючись представником виробника. Рекомендація SafePal вважати гаманець скомпрометованим для тих, кого обманули через фішинг, несе в собі значне навантаження.
Сама SafePal отримує удар по репутації, який важко виміряти, але легко відчути. Коли вся ваша пропозиція — «ми компанія безпеки», витік з системи замовлень сприймається гірше, ніж такий самий витік у роздрібного продавця матраців. Зобов'язання щодо 90-денного зберігання даних і незалежний аудит — це правильні кроки, і вони були зроблені швидко, що також важливо.
Ширша категорія апаратних гаманців також отримує рикошет. Trezor раніше попереджав 14 000 клієнтів після витоку даних у партнера з виконання замовлень. Витік бази даних клієнтів Ledger у 2020 році досі цитується в кожному серйозному аналізі загроз. Є закономірність, і вона стосується не гаманців. Вона стосується роздрібної інфраструктури за ними. Будь-який CISO виробника апаратних засобів, який читає це в понеділок вранці, має те саме запитання: як виглядає наш pipeline замовлень і хто востаннє його перевіряв?
Для читачів із сфер iGaming та фінтех, які можуть вважати це чужою проблемою, — погляньте на власні системи, суміжні з KYC. Платформи лояльності, листи підтвердження депозитів, інтеграції кур'єрів для фізичних карток. Та сама форма ризику, той самий клас помилок, та сама початкова точка «ми не вважали це критичним з погляду безпеки».
Посібник для команд безпеки
Три дії, які варто виконати цього тижня, у порядку «соромно, якщо пропустите».
По-перше, виконайте grep по своїй кодовій базі та сторонніх плагінах на предмет ендпоінтів пошуку об'єктів, які довіряють сесії, але не перевіряють право власності. Усе, що має вигляд GET /orders/:id, /tickets/:id, /documents/:id. Автоматизовані IDOR-сканери виявляють очевидні випадки. Ручна перевірка виявляє ті, де перевірка існує, але лише для маршруту «перегляду», а не для маршруту «завантажити PDF». Це нудна частина, і саме там живуть помилки.
По-друге, розглядайте зберігання даних як засіб безпеки, а не як завдання з відповідності вимогам. Перехід SafePal до 90-денного зберігання даних замовлень — правильний інстинкт: дані, яких у вас немає, не можуть витекти. Системи обробки замовлень накопичують PII так само, як підвали накопичують коробки. Агресивні TTL для записів про доставку, контактних даних та імпортів застарілих клієнтів зменшують радіус ураження від наступної помилки плагіна, про яку ви ще не знаєте.
По-третє, проведіть tabletop-вправу для сценарію «наш список клієнтів є публічним, наш продукт — у порядку». Комунікації, юридична служба, підтримка та інженерія реагують на це інакше, ніж на подію втрати коштів, а більшість планів реагування на інциденти написана саме для випадку втрати коштів. Хто складає лист? Хто відстежує фішингові сайти? Хто спілкується з аудитором? SafePal видалила понад 30 шахрайських доменів після цього інциденту, що означає: у когось вже був готовий процес видалення. Якщо у вашої команди його немає — побудуйте його до того, як він знадобиться.
Бонус: якщо ви продаєте фізичні товари клієнтам, які цінують конфіденційність, запитайте себе, чи справді вам потрібна адреса доставки після того, як посилку вручено. У дев'яти випадках із десяти відповідь — ні.
Ключові висновки
- Витік SafePal розкрив дані замовлень 39 798 клієнтів за період з 2 березня 2025 року по 11 квітня 2026 року через уразливість авторизації в плагіні відстеження замовлень. Кошти, ключі та сід-фрази залишились недоторканими.
- Імовірний клас помилки — IDOR або подібний; екосистема плагінів навколо e-commerce є реальною поверхнею атаки, а не прошивка гаманця.
- Постраждалі клієнти стикаються з підвищеним ризиком цільового фішингу, оскільки витік підтверджує як особу, так і факт володіння продуктом.
- Реакція SafePal (швидке сповіщення електронною поштою, аудит стороньою компанією, обмеження зберігання 90 днями, видалення 30+ фішингових сайтів) є шаблоном, який мають наслідувати інші виробники.
- Повертаючись до слюсаря: замок настільки ж конфіденційний, наскільки конфіденційна база даних клієнтів у підсобці. Перевірте підсобку.
Часті запитання
П: Чи були вкрадені криптовалютні кошти або приватні ключі під час витоку SafePal?
Ні. SafePal підтвердила, що жодні криптовалютні кошти, сід-фрази, приватні ключі, банківські дані, посвідчення особи, паролі або номери платіжних карток не були скомпрометовані. Розкриття обмежилось іменами, фізичними адресами та контактними даними з системи відстеження замовлень.
П: Як клієнти SafePal можуть перевірити, чи торкнувся витік їхніх даних?
SafePal опублікувала на своєму вебсайті інструмент перевірки, за допомогою якого клієнти можуть дізнатись, чи входять їхні дані замовлення до числа розкритих. Постраждалих користувачів також безпосередньо сповістили електронним листом з адреси [email protected] у неділю, коли було оголошено про витік.
П: Що робити користувачам, які розміщували замовлення SafePal у зазначений період?
Вважайте, що ваше ім'я та адреса доставки відомі зловмисникам, і сприймайте будь-які небажані листи, дзвінки, листи або пропозиції щодо заміни пристрою під брендом SafePal як імовірний фішинг. Будь-хто, хто коли-небудь передавав сід-фразу або приватний ключ у відповідь на фішинговий запит, має дотримуватись рекомендації SafePal і негайно перемістити активи до нового гаманця.
Портали Salesforce Зливали Дані 17 Місяців, Поки Ніхто Не Дивився
Кампанія City-Forum 17 місяців витягувала записи з порталів Salesforce і ServiceNow, перш ніж хтось помітив. Ця цифра має налякати кожного CISO.
VMware vCenter CVE-2026-59310 під глобальною атакою APT-угруповання
Критична вразливість vCenter перейшла від оголошення до глобальної APT-експлуатації за п'ять днів, а persistence через reverse_ssh означає, що лише патч не позбавить вас атакуючого.
eBPF-сенсори та 18-хвилинне вікно атаки на Kubernetes
AKS-кластери зондують через 18 хвилин після створення, EKS — через 28. Це знищує логіку «щотижневого сканування» й робить eBPF критично важливим на рівні runtime.




