Рекомендации клиентам Битрикс24 в связи с инцидентом у хостинг-провайдера

18 октября хостинг-провайдер FirstVDS сообщил об обнаружении атаки, произошедшей 17 октября. По данным провайдера, злоумышленники воспользовались уязвимостью в системе управления виртуализацией VMmanager 6, которую использовал хостер, и получили доступ к части его инфраструктуры.

Несмотря на то что уязвимость была обнаружена не в Битрикс24, а в инфраструктуре FirstVDS, для наших клиентов мог возникнуть косвенный риск, если на затронутых внешних серверах работали серверные части сторонних приложений и хранились данные доступа к порталам либо данные, ранее полученные из Битрикс24.

Что сообщает FirstVDS

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

В сообщении FirstVDS указано, что расследование инцидента продолжается. По состоянию на 19 октября 2026 года, 17:46 МСК, в этом сообщении не раскрыты технические детали эксплуатации уязвимости и полный перечень затронутых версий.

Почему вопрос не ограничивается FirstVDS

FirstVDS — публично известный пример эксплуатации этой уязвимости. Однако VMmanager 6 может использоваться и другими хостинг-провайдерами.

Серверная часть стороннего приложения для Битрикс24 может работать во внешней инфраструктуре, выбранной его разработчиком. Само по себе использование VMmanager 6 не доказывает компрометацию. Если серверная часть приложения размещена у провайдера, использующего VMmanager 6, клиенту следует запросить у разработчика результаты проверки конкретной инфраструктуры, на которой работает приложение. Разработчик при необходимости должен получить соответствующую информацию у хостинг-провайдера.

Что сделал Битрикс24

18 октября после публикации сообщения от FirstVDS Битрикс24 перевыпустил секреты (client_secret) OAuth-доступа на серверной стороне Маркета для потенциально затронутых сторонних приложений. Эта мера носит проактивный характер и сама по себе не означает, что конкретное приложение или его установка были скомпрометированы. Разработчики этих модулей в настоящее время обновляют данные секреты, что может влиять на их доступность. Текущий охват — 10 разработчиков. Расследование инцидента со стороны FirstVDS продолжается, мы следим за ситуацией, возможны дополнительные отзывы ключей.

Что это означает для клиентов

• Если приложение из Маркета перестало работать 18–19 октября, одной из возможных причин может быть введенное Битрикс24 ограничение доступа. Уточните у разработчика, затронута ли установка приложения на вашем портале. При этом локальные приложения и входящие вебхуки, созданные администраторами порталов, автоматически этой мерой не охвачены.

• Сроки и порядок восстановления работы конкретного приложения и необходимые действия уточняйте у его разработчика. Если разработчик не отвечает, обратитесь в техническую поддержку 1С-Битрикс.

Два риска, которые нужно проверить

Возможны два разных сценария:

1. Использование похищенных данных доступа для новых обращений к порталу. Отзыв секрета OAuth-доступа предназначен для снижения этого риска у потенциально затронутых установок приложений из Маркета.

2. Компрометация данных, ранее сохраненных приложением. Стороннее приложение могло законно получить данные из Битрикс24 и сохранить их во внешней инфраструктуре разработчика. Если такие данные находились на затронутом сервере, они могли быть скопированы во время атаки. Отзыв секрета приложения не удаляет ранее сохраненные копии данных с внешнего сервера стороннего модуля, из его резервных копий, журналов или хранилищ. Такой сценарий может не сопровождаться новыми REST-запросами к Битрикс24.

Что делать клиенту

1. Проверьте установленные приложения

Составьте список сторонних приложений, подключенных к вашему Битрикс24, и определите их разработчиков. Проверьте, к каким данным и инструментам портала у каждого приложения есть доступ.

Как проверить доступы приложения

2. Обратитесь к разработчику приложения

Уточните:

1. Где размещается серверная часть приложения и какой хостинг-провайдер используется?

2. Использует ли этот провайдер VMmanager 6?

3. Получал ли разработчик или провайдер уведомление о возможной компрометации конкретного сервера или узла?

4. Работало ли приложение для вашего портала на потенциально затронутом сервере?

5. Какие данные, ключи и токены хранились на этом сервере?

6. Какие данные вашего портала приложение ранее сохраняло во внешней инфраструктуре, включая резервные копии, журналы и временные файлы?

7. Проведена ли проверка инфраструктуры и можно ли безопасно продолжать использование приложения?

8. Какие действия уже выполнены и требуются ли дополнительные действия от вас?

Просите ответ по конкретному приложению и обслуживающему ваш портал серверу. Самого утверждения об использовании или неиспользовании определенного хостера недостаточно.

3. Локальное приложение, размещенное у хостера

Если серверная часть какого-либо вашего локального приложения или его данные доступа находились на потенциально скомпрометированном хостинге:

1. Изолируйте соответствующий сервер и отключите интеграции.

2. Для аннулирования сохраненных токенов удалите локальное приложение с портала: согласно документации Битрикс24, удаление приложения делает все сохраненные токены недействительными. Перед удалением оцените, какие зависимые процессы остановятся и что потребуется для восстановления интеграции.

3. Проверьте инфраструктуру на предмет компрометации, при необходимости перенесите приложение в проверенную среду.

4. Перевыпустите все секреты и токены.

4. Входящий вебхук

Если URL входящего вебхука хранился на потенциально скомпрометированном сервере, удалите прежний вебхук в Битрикс24, проверьте или перенесите серверную среду, затем создайте новый вебхук и передайте его URL в проверенную среду. Предварительно оцените, какие процессы перестанут работать после удаления.

5. Проверьте REST-активность

Администратор портала может открыть раздел Приложения → Разработчикам → Статистика и проверить число REST-запросов по приложениям, вебхукам, методам или событиям и датам. Доступна история не более чем за 14 дней. Сравните активность начиная с 17 октября с обычным уровнем за предыдущие дни.

Как проверить статистику REST-запросов

Статистика подходит только для предварительного поиска аномалий. Она не показывает, кто фактически использовал данные доступа, какие записи были прочитаны и какие сведения могли быть получены.

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