У одной из компаний на платформе ServiceNow обнаружили странную активность: в журналы полезли запросы, которых там быть не должно. После проверки вендор подтвердил — неизвестные злоумышленники сумели получить более широкий доступ к части клиентских инстансов, чем им позволяли настройки.

Проблему закрыли обновлением 5 июня 2026 года. Пока речь не идет о публичном CVE-номере, но ServiceNow уже уведомила затронутых клиентов и отдельно указала: риск касается не всех, а только части установок.

Что случилось и почему это важно

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

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

Похожая логика уже всплывала в других инцидентах — например, когда уязвимость в LiteLLM попала под активную эксплуатацию: сначала виден только технический сбой, а затем атака быстро упирается в доступ к данным.

Три рабочих подхода к такой проблеме

1. Патч и срочная ревизия настроек

Это базовый путь: закрыть дыру, проверить, какие инстансы попадают под риск, и сравнить конфигурации с рекомендованными. Плюс здесь очевиден — быстрый эффект и понятная логика действий.

Минус тоже понятен: если компания годами жила на «слегка» кастомных настройках, одна заплатка не уберет накопленный технический долг. Тогда уязвимость закроют, но похожий сбой может вылезти уже в другом месте.

2. Жестче разделить доступ и логику ролей

Второй подход — не полагаться на один endpoint и не держать доступ слишком широким по умолчанию. Для корпоративных систем это особенно важно: одна роль должна видеть только то, что ей действительно нужно.

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

3. Наблюдаемость и аудит событий

ServiceNow как раз заметила аномальную активность и по ней вышла на проблему. Это еще раз напоминает: защита без нормального аудита почти не работает, особенно если атака выглядит как «обычный» запрос к таблице.

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

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

Кому какой сценарий подходит

Крупным компаниям и тем, кто держит критичные бизнес-процессы в SaaS-платформах, нужен полный набор мер: патч, аудит, разграничение доступа и контроль аномалий. Здесь нельзя надеяться на один «волшебный» апдейт.

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

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

Что делать прямо сейчас

  • Проверить, на каком релизе работает ваш инстанс ServiceNow.
  • Сверить конфигурацию endpoint-доступа с рекомендациями вендора.
  • Ограничить лишние роли и убрать избыточные права у интеграций.
  • Просмотреть журналы на предмет нетипичных запросов к таблицам.
  • Убедиться, что оповещения о подозрительной активности включены.
  • Проверить, получили ли ответственные сотрудники уведомление от вендора.
  • Пересмотреть, где у вас хранятся чувствительные данные и кто к ним ходит.
Поделиться: