Атака на Polymarket заставила платформу прогнозных рынков временно остановить торги: в кошельке, который исследователи связывают со злоумышленниками, отследили около 28,6 млн POL — примерно $2,57 млн на момент инцидента. Причиной оказался не взлом смарт-контракта и не фишинговая рассылка, а вредоносный JavaScript, попавший на сайт через стороннего поставщика. Для команд, которые подключают внешнюю аналитику и RUM-скрипты, это очередное неприятное напоминание: код из CDN получает доступ к браузеру пользователя ровно с теми же последствиями, что и собственный фронтенд.
Инцидент произошёл 29 октября. По данным BleepingComputer, Polymarket около 14:05 по восточному времени перевёл биржу в режим cancel-only — пользователи могли отменять заявки, но не открывать новые — и приостановил действия relayer-сервиса. В 14:37 компания сообщила, что проблему исправили, однако торги ещё держали на паузе из предосторожности. Примерно через час после начала остановки сервис вернулся к работе, а в 15:05 инцидент был отмечен как устранённый.
Polymarket заявил, что один из его сторонних провайдеров был скомпрометирован и информация передана правоохранительным органам. Платформа пообещала полностью возместить потери пострадавшим трейдерам, но не раскрыла ни число затронутых аккаунтов, ни фактический объём похищенных средств, ни механизм компенсаций. Это важная оговорка: $2,57 млн — сумма переводов, замеченных в блокчейне по подозрительному адресу, а не подтверждённый Polymarket итог ущерба.
Исследователи Hudson Rock нашли адрес предполагаемого атакующего кошелька, зашитый в скрипт. По наблюдениям из блокчейна, средства с него ушли на три других адреса. Сам кошелёк незадолго до остановки площадки, между 13:50 и 13:56 по восточному времени, выполнил серию операций с контрактом токенов рынка прогнозов Polymarket. На момент проверки Hudson Rock на нём оставалось криптоактивов примерно на $2,19 млн.
Вредоносный файл раздавался с домена cdn.debugbear[.]com. Он относится к инфраструктуре DebugBear — сервиса мониторинга производительности, чьё RUM-решение добавляет JavaScript на сайты клиентов для сбора данных о загрузке страниц и пользовательском опыте. Компания DebugBear признала продолжающийся инцидент и попросила клиентов убрать код RUM со своих сайтов. Её сайт в момент публикации материала был недоступен и показывал ошибку Cloudflare; связь недоступности с мерами локализации компания не пояснила.
Технически сценарий выглядел особенно опасно, потому что скрипт работал уже внутри доверенного контекста страницы Polymarket. Он проверял, авторизован ли посетитель, использовал действующую торговую сессию и оценивал балансы кошелька и открытые позиции. Дальше логика зависела от способа авторизации: у одних пользователей код пытался продать позиции на рынке прогнозов, у других — перевести соответствующие токены на кошелёк злоумышленника. Скрипт также стремился конвертировать доступные криптоактивы в форму, которую можно отправить атакующему через штатные механизмы платформы.
Это атака на Polymarket класса supply-chain, но на клиентской стороне. В такой модели злоумышленнику не обязательно получать доступ к базам данных самой площадки или ломать серверную авторизацию: достаточно внедриться в цепочку поставки скрипта, которому сайт уже доверяет. Если этот код способен читать состояние страницы, обращаться к API от имени залогиненного пользователя и инициировать действия через интерфейс, граница между «сторонней метрикой» и привилегированным компонентом продукта исчезает.
Вредоносный JavaScript, по данным исследователей, связывался с data.debugbear.com: оттуда он мог получать инструкции и туда же передавал сведения о целевых аккаунтах, адресах кошельков, балансах и результатах операций. Использование одной инфраструктуры и для доставки скрипта, и для управления атакой, и для вывода данных указывает как минимум на серьёзность компрометации окружения поставщика. В производственной сборке Polymarket также обнаружили метаданные с сообщением коммита об удалении DebugBear RUM; метка времени — 13:59, за несколько минут до публичной реакции сервиса.
Для разработчиков вывод не сводится к совету «меньше ставить аналитики». Внешний скрипт нужно учитывать как полноценную зависимость с доступом к данным и действиям пользователя. Особенно в продуктах с кошельками, платежами, персональными кабинетами и административными функциями. Полезный минимум — инвентаризация всех подключаемых тегов, ограничение их областей действия, контроль версий и доменов загрузки, CSP с жёстким списком разрешённых источников, а также отдельная оценка риска для каждого скрипта, способного работать рядом с авторизованной сессией. Subresource Integrity помогает лишь там, где загружается неизменяемый файл с заранее известным хешем; для динамических RUM-вставок этого обычно недостаточно.
Бизнесу здесь стоит проверить и процесс реагирования. Polymarket быстро ограничил операции, удалил интеграцию и восстановил работу, но вопросы о числе пострадавших и размере потерь пока остаются открытыми. Обещание компенсации снижает репутационный удар, однако не заменяет понятного плана: как отзываются сессии, как фиксируются спорные транзакции, кто принимает решение о возмещении и каким образом пользователи узнают, что именно произошло с их активами.
Главный вопрос после инцидента — насколько многие компании по-прежнему считают браузерные скрипты для аналитики безобидным дополнением, а не частью критического периметра. Атака на Polymarket показывает, что при наличии авторизованной сессии компрометация такого поставщика может превратить мониторинг скорости сайта в инструмент вывода средств. Разбор вредоносного файла и детали операции опубликованы в материале .
