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

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

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

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

В сообщении FirstVDS указано, что расследование инцидента продолжается. По состоянию на 19 октября 2 026 года, 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‑запросов

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

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