Атака на DebugBear: сервис просит удалить RUM-скрипт с сайтов, что проверить владельцам

Что произошло

Real User Monitoring измеряет скорость и Core Web Vitals в браузерах настоящих посетителей. Для этого на страницы ставят внешний JavaScript, который загружается с адреса вида cdn.debugbear.com/<идентификатор>.js.

29 октября 2026 года такой скрипт на сайте Polymarket оказался вредоносным. Polymarket в отчёте об инциденте пишет, что код был сделан специально против его пользователей. У части тех, кто в тот момент был на сайте, он через активную сессию продавал позиции и выводил средства.

Код пользовался уже открытой сессией, и пароль ему был не нужен.

Polymarket убрал скрипт, очистил кэши, сбросил все активные сессии и временно остановил торги. Компания сообщила, что возвращает пострадавшим 3,9 млн долларов, из них 1,2 млн — за потери во время паузы.

Что говорит DebugBear

В день атаки DebugBear написал, что затронут инцидентом безопасности, и попросил всех, кто пользуется RUM, удалить код со своих сайтов. В следующем обновлении компания уточнила, что DNS-записи скомпрометированы через регистратора домена, а почта на домен не доходит.

По первичному расследованию атака была нацелена на сайт одного клиента. Признаков взлома внутренних систем DebugBear не нашёл, но проверку продолжает.

Получали ли вредоносный код другие сайты, пока неизвестно. BleepingComputer разобрал копию скрипта: он получал команды и отправлял данные через поддомен data.debugbear.com. Сообщения о том, что скрипт снова безопасен, на странице DebugBear в LinkedIn нет.

Сайт компании 1 ноября по-прежнему отвечал ошибкой 530.

Сторонний скрипт выполняется на вашей странице с теми же возможностями, что и ваш собственный код.

Почему это касается не только Polymarket

Браузер не знает, что по прежнему адресу скрипта теперь отдают другой код. Если кто-то получил контроль над доменом поставщика, его CDN или аккаунтом регистратора, подменённый файл приходит на сайт через доверенную интеграцию.

Опасность зависит от того, где стоит скрипт. На страницах, где посетитель или администратор уже вошёл в систему, чужой код может делать то же, что и он сам. Отправлять запросы, менять данные, читать содержимое страницы.

Наш опыт

Мы проверили свой сайт, скрипта DebugBear на нём нет.

Проверка заняла пару минут. Достаточно поискать в коде главной и нескольких типовых страниц строку debugbear, а если теги ставятся через Google Tag Manager, то ещё и в его контейнере.

Наш комментарий

Скрипты скорости, аналитики и чатов обычно ставят «один раз и навсегда» и забывают о них. Этот случай показывает, что каждый такой скрипт — часть сайта со всеми его правами. Чем меньше их стоит на страницах входа, оформления заказа и в админке, тем меньше риск.

Паниковать всем клиентам DebugBear не нужно, подтверждена атака на один сайт.

Но рекомендацию самого поставщика стоит выполнить сейчас, а не после подробного отчёта.

Что сделать

• Найти скрипт. Проверить шаблон темы, плагины вставки кода, Google Tag Manager, Custom Code в конструкторе и серверные шаблоны.
• Удалить и очистить кэш. Кэш WordPress, плагинов оптимизации и CDN. Затем убедиться, что запросов к debugbear.com на страницах больше нет.
• Сбросить сессии. Начать с администраторов. Смена пароля не всегда завершает уже открытые сессии, на WordPress для этого меняют ключи безопасности в wp-config.php.
• Отозвать ключи. API-ключи и токены, которые могли быть видны на страницах со скриптом.
• Проверить изменения. Новые пользователи и роли, плагины, файлы, теги и задания по расписанию. Сравнить с чистой копией.
• При признаках взлома — закрыть сайт. На время очистки отдавать страницу обслуживания с кодом 503.

С чего начать

Откройте код главной и страницы входа и найдите в нём debugbear. Как закрыть сайт на время очистки и не выпасть из поиска, мы разбирали в новости о коде 503, а порядок проверки после взлома — в новости о взломе TeamUpdraft. Проверить сторонние скрипты и безопасность сайта помогаем в рамках технического аудита.