Утечка данных 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 с кладбищем сторонних расширений для отслеживания, налогов, фулфилмента и email. Каждое из них — отдельная поверхность для атаки, нередко написанная командой из двух человек и редко входящая в ту же модель угроз, что и прошивка кошелька.

Инцидент с Coldcard, упомянутый в том же материале CoinDesk, где злоумышленник предположительно похитил не менее $120 миллионов в биткоине, — это совершенно другая история. Там были деньги. Здесь — метаданные. Но метаданные — это карта, а карта превращает оппортунистический фишинг в точечное выбивание средств. Если у меня есть имя, физический адрес и подтверждение, что человек владеет определённой маркой аппаратного кошелька, мне не нужно гадать, кому отправить письмо с поддельным обновлением прошивки.

Кто пострадает

39 798 клиентов несут основной риск. Их имена и адреса доставки теперь гуляют по тому каналу, в котором злоумышленник их продаёт, причём квалифицирующий признак («этот человек владеет SafePal») уже встроен. Стоит ожидать волны почтового фишинга, поддельных отправок устройств на замену, фиктивных звонков службы поддержки и особенно неприятного варианта, когда кто-то физически приходит по адресу, представляясь представителем компании. Рекомендация SafePal о том, что пользователи, попавшиеся на фишинг, должны считать кошелёк скомпрометированным, несёт в себе немалый вес.

Сам SafePal получает репутационный удар, который трудно измерить, но легко почувствовать. Когда весь ваш питч строится на тезисе «мы — компания по безопасности», утечка из системы заказов воспринимается болезненнее, чем та же утечка у продавца матрасов. Обязательство о 90-дневном хранении данных и независимый аудит — правильные шаги, и они были сделаны быстро, что тоже имеет значение.

Весь сегмент аппаратных кошельков также получает рикошет. Trezor ранее предупреждал 14 000 клиентов после того, как партнёр по фулфилменту пережил утечку данных. Утечка базы клиентов Ledger в 2020 году до сих пор фигурирует в каждом серьёзном анализе угроз. Здесь прослеживается паттерн, и он не связан с самими кошельками. Он связан с розничной инфраструктурой за ними. Любой CISO компании-производителя аппаратного кошелька, читающий это в понедельник утром, задаётся одним и тем же вопросом: как выглядит наш процесс обработки заказов и кто последний раз его аудировал?

Для читателей из iGaming и финтеха, которые могут считать это чужой проблемой: посмотрите на свои собственные системы, смежные с KYC. Платформы лояльности, письма с подтверждением депозитов, курьерские интеграции для физических карт. Та же форма риска, тот же класс уязвимостей, та же история происхождения «мы не воспринимали это как критически важное для безопасности».

Инструкция для команд безопасности

Три вещи, которые стоит сделать на этой неделе — в порядке убывания неловкости, если их пропустить.

Первое: пройдитесь по кодовой базе и сторонним плагинам в поисках эндпоинтов поиска объектов, которые доверяют сессии, но не проверяют право владения. Всё, что выглядит как GET /orders/:id, /tickets/:id, /documents/:id. Автоматизированные IDOR-сканеры поймают очевидные случаи. Ручной ревью поймает те, где проверка есть, но только для маршрута «просмотр», а не для маршрута «скачать PDF». Это скучная часть работы, и именно там живут баги.

Второе: относитесь к хранению данных как к инструменту безопасности, а не как к формальности ради соответствия требованиям. Решение SafePal перейти к 90-дневному хранению данных заказов — правильный инстинкт: данные, которых у вас нет, не могут утечь. Системы обработки заказов накапливают персональные данные так же, как подвалы накапливают коробки. Агрессивные TTL для записей о доставке, контактных данных и устаревших импортов клиентов уменьшают радиус поражения следующего бага в плагине, о котором вы ещё не знаете.

Третье: проведите учения по сценарию «наш список клиентов стал публичным, продукт в порядке». Коммуникации, юридический отдел, поддержка и разработка реагируют на это иначе, чем на событие потери средств, а большинство сценариев реагирования на инциденты написаны именно для случая потери средств. Кто составляет письмо? Кто мониторит фишинговые сайты? Кто общается с аудитором? SafePal удалил более 30 мошеннических доменов по следам этого инцидента — это значит, что у кого-то был готов процесс удаления. Если у вашей команды его нет, выстройте его до того, как он понадобится.

Бонус: если вы продаёте физические товары клиентам, которые ценят конфиденциальность, задайтесь вопросом: действительно ли вам нужен адрес доставки после того, как посылка вручена? В девяти случаях из десяти ответ — нет.

Ключевые выводы

• Утечка данных SafePal раскрыла данные заказов 39 798 клиентов в период с 2 марта 2025 года по 11 апреля 2026 года через уязвимость авторизации в плагине отслеживания заказов. Средства, ключи и сид-фразы не пострадали.
• Вероятный класс уязвимости — IDOR или схожий; реальная поверхность атаки — экосистема плагинов вокруг e-commerce, а не прошивка кошелька.
• Пострадавшие клиенты сталкиваются с повышенным риском целевого фишинга, поскольку утечка данных подтверждает одновременно личность и факт владения продуктом.
• Ответные действия SafePal (оперативное уведомление по email, сторонний аудит, ограничение хранения данными 90 днями, удаление более 30 фишинговых сайтов) — это шаблон, которому должны следовать другие производители.
• Возвращаясь к слесарю: замок настолько же конфиденциален, насколько конфиденциален список клиентов в подсобке. Проведите аудит подсобки.