ServiceNow AI Platform: pre-auth RCE эксплуатируют в реальных атаках

Коротко о главном

18 июля 2026 года исследователи зафиксировали первые атаки на критическую уязвимость ServiceNow AI Platform (CVE-2026-6875, CVSS 9.5). Это побег из песочницы: неаутентифицированный злоумышленник обходит изоляцию скриптового движка и выполняет произвольный код прямо на инстансе. Патч для self-hosted вышел 13 июля — эксплуатация началась через пять дней. Кто использует on-premise или partner-hosted ServiceNow — обновляйтесь немедленно.

Уязвимость сидит в ядре скриптового движка, поэтому под ударом любой непропатченный self-hosted инстанс независимо от того, какие модули на нём установлены. Облачные (ServiceNow-hosted) инстансы вендор закрыл ещё в апреле 2026 года, вскоре после получения отчёта, — а вот у тех, кто держит платформу у себя, окно для обновления открылось только в июле и уже под активной атакой.

ServiceNow — это ITSM, HR, CMDB и рабочие процессы половины крупных предприятий; компрометация инстанса означает доступ к внутренним данным и учёткам, поэтому такой класс дефектов требует не разовой заплатки, а системного подхода к информационной безопасности и регулярного IT-аудита инфраструктуры. Ниже — что известно об уязвимости и как действовать командам разработки и эксплуатации.

Что именно случилось

CVE-2026-6875 — это sandbox escape в скриптовом движке ServiceNow AI Platform (до ребрендинга — Now Platform). Платформа исполняет серверный JavaScript в изолированной песочнице; уязвимость позволяет вырваться из этой изоляции и добиться выполнения кода на самом инстансе. Аутентификация и взаимодействие с пользователем не требуются — это pre-auth RCE, самый тяжёлый класс серверных дефектов. По оценкам, атака имеет высокую сложность, но результат — полный контроль над экземпляром.

Нашла проблему команда Searchlight Cyber (исследователь Адам Кьюс), сообщившая о ней ServiceNow в начале апреля 2026 года. Вендор оперативно закрыл собственные облачные инстансы, а формальные патчи для self-hosted и partner-hosted развёртываний выпустил 13 июля 2026 года. В числе мер ServiceNow представила механизм Guarded Script, ужесточающий правила исполнения кода в песочнице, чтобы закрыть саму возможность побега.

Эксплуатация в дикой природе

Первые попытки эксплуатации в реальных атаках исследователи из Defused зафиксировали в пятницу, 18 июля 2026 года — через пять дней после выхода патча для self-hosted. К выходным активная эксплуатация подтвердилась независимо. Атаки нацеливались на конечную точку /assessment_thanks.do — публично доступный обработчик, характерный для инстансов ServiceNow.

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

Кому это грозит

В зоне риска — организации, которые держат ServiceNow у себя (on-premise) или у партнёра, а не в облаке вендора, и не установили июльское обновление. Поскольку уязвимый код — это ядро скриптового движка, а не отдельный модуль, наличие или отсутствие конкретных приложений поверх платформы роли не играет: экспонирован сам инстанс. ServiceNow-hosted клиенты защищены апрельским фиксом, но подтвердить статус патча всё равно стоит.

Отдельный фактор риска — публичная доступность инстанса. Многие развёртывания ServiceNow смотрят в интернет для доступа сотрудников и подрядчиков, а значит, уязвимая конечная точка достижима для массового сканирования. Компрометация такого инстанса открывает путь к данным ITSM, конфигурационной базе (CMDB), интеграциям и хранимым учётным данным — то есть к богатой цели для дальнейшего продвижения по сети.

Что это значит для команд разработки и эксплуатации

Первое и главное — обновиться до пропатченного релиза, если это ещё не сделано. Для self-hosted это июльское обновление; медлить нельзя, эксплойт уже в обороте. Если немедленное обновление невозможно, ограничьте сетевую доступность инстанса и внешний доступ к подозрительным конечным точкам, но воспринимайте это лишь как временную меру до установки патча.

Второе — проверить инстанс на признаки компрометации за период с 13 июля. Ищите аномальные запросы к /assessment_thanks.do, неожиданное исполнение серверных скриптов, новые учётные записи и интеграции, исходящие соединения. Инцидент вокруг ServiceNow — хороший повод синхронизировать эту работу с командой, отвечающей за защиту инфраструктуры, и заложить регулярную практику ревью серверного кода и конфигураций, а не разовую реакцию на новость.

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

Как действовать: короткий чек-лист

Определите модель размещения. Уточните, где именно работает ваш ServiceNow: облако вендора, on-premise или partner-hosted. Для self-hosted и partner-hosted это приоритет номер один.

Установите июльский патч. Обновитесь до пропатченного релиза, устраняющего CVE-2026-6875; для облачных инстансов подтвердите, что апрельский фикс применён.

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

Проверьте следы компрометации. Проанализируйте логи с 13 июля: обращения к /assessment_thanks.do, аномальное исполнение скриптов, новые учётки, интеграции и исходящие соединения.

Включите это в постоянный процесс. Свяжите патч-менеджмент критических платформ и мониторинг с регулярным аудитом безопасности, чтобы следующий подобный дефект закрывался за часы, а не за недели.

Часто задаваемые вопросы

Что такое CVE-2026-6875? Это критическая уязвимость ServiceNow AI Platform класса sandbox escape: неаутентифицированный злоумышленник обходит изоляцию скриптового движка и выполняет произвольный код на инстансе. Оценка критическая — CVSS 9.5.

Мой ServiceNow в облаке — я под угрозой? Облачные (ServiceNow-hosted) инстансы вендор закрыл ещё в апреле 2026 года. Активная эксплуатация касается self-hosted и partner-hosted развёртываний без июльского патча. Статус обновления всё равно стоит подтвердить.

Уже есть атаки в реальном мире? Да. Первые попытки эксплуатации исследователи зафиксировали 18 июля 2026 года, к выходным активность подтвердилась независимо. Атаки нацелены на конечную точку /assessment_thanks.do.

Что делать прямо сейчас? Установить июльское обновление на self-hosted и partner-hosted инстансы, для облака подтвердить апрельский фикс, ограничить внешний доступ на время обновления и проверить логи на признаки компрометации с 13 июля.

Источники

ServiceNow — CVE-2026-6875: Sandbox Escape in ServiceNow AI Platform, Now Support (KB3137947), 2026 (первоисточник вендора).

BleepingComputer — Critical ServiceNow code execution flaw now exploited in attacks, 20 июля 2026 года.

Help Net Security — ServiceNow pre-auth RCE exploited in the wild (CVE-2026-6875), 20 июля 2026 года.