Критическая уязвимость ServiceNow, получившая идентификатор CVE-2026-6875, вышла из разряда «надо запланировать обновление» в категорию «патчить вчера». По данным исследователей, первые попытки эксплуатации в реальных атаках заметили 18 июля, а значит для компаний на self-hosted-инсталляциях окно спокойной установки обновлений уже закрылось.
О начале эксплуатации сообщает BleepingComputer со ссылкой на threat intelligence-компанию Defused и исследователей Searchlight Cyber, которые и нашли проблему. Речь идет о ServiceNow AI Platform, ранее известной как Now Platform, корпоративной PaaS-платформе для автоматизации и встраивания ИИ в бизнес-процессы. Уязвимость ServiceNow опасна тем, что позволяет неаутентифицированному атакующему выйти из песочницы и добиться удаленного выполнения кода внутри платформы. Иными словами, это не баг из серии «что-то сломалось в одном модуле», а потенциальная точка входа в среду, через которую у крупных компаний часто проходят критичные workflow.
Searchlight Cyber сообщила, что передала информацию о проблеме 1 апреля 2026 года. Для облачных инстансов, которые хостит сама ServiceNow, исправления начали разворачивать еще в апреле. А вот обновления безопасности для self-hosted-версий под CVE-2026-6875 вышли только 13 июля, то есть за несколько дней до появления подтвержденной эксплуатации. За выходные исследователи Defused подтвердили: атаки уже идут «в дикой природе». По их словам, злоумышленники используют тот же pre-auth sink, который ранее был описан Searchlight Cyber, это endpoint /assessment_thanks.do, но обход песочницы у них реализован не тем маршрутом, который был показан в публичном proof-of-concept. Для защитников это неприятный, но типичный сценарий: даже если команда успела изучить опубликованный PoC и построить вокруг него временные детекты, реальная эксплуатация может приехать по соседнему пути.
Уязвимость ServiceNow здесь особенно чувствительна не только из-за оценки critical, но и из-за профиля самой платформы. ServiceNow утверждает, что ее AI Platform ежегодно обрабатывает более 100 млрд workflow и лежит в основе свыше 100 тыс. корпоративных AI-приложений у 85% компаний из списка Fortune 500. Когда компрометация возможна на уровне платформы, вопрос быстро выходит за пределы ИБ-отдела. Это уже риск для внутренних сервис-десков, HR-процессов, закупок, customer operations и интеграционных сценариев, в которых ServiceNow часто играет роль оркестратора между несколькими системами. Для российских ИТ-команд, которые работают в международных контурах или поддерживают зарубежные дочерние структуры, это еще и напоминание: enterprise-SaaS и PaaS остаются такой же частью поверхности атаки, как VPN, почта или гипервизоры.
Отдельно бросается в глаза коммуникационный разрыв между внешними исследователями и вендором. Defused прямо говорит о наблюдаемой эксплуатации, тогда как в официальном advisory ServiceNow на тот момент все еще указывала, что «в настоящее время не осведомлена об эксплуатации против инстансов ServiceNow». Позже представитель компании уточнил BleepingComputer, что по итогам внутреннего расследования ServiceNow не видит признаков того, что активность затронула именно те экземпляры, которые хостит сама компания. Это важная, но довольно узкая формулировка. Она не опровергает сам факт эксплуатации CVE-2026-6875, а лишь отделяет облачную инфраструктуру ServiceNow от self-hosted-сред клиентов. Для бизнеса разница принципиальна: если вы не на fully managed-инстансе вендора, рассчитывать на чужой SOC уже поздно.
Контекст тоже не добавляет спокойствия. Меньше месяца назад ServiceNow уже приватно раскрывала другой инцидент, связанный с неаутентифицированным доступом к данным клиентских инстансов через уязвимый API endpoint. Тогда компания позже заявила, что активность была связана не со злонамеренными атакующими, а с исследователями безопасности или customer-led research в рамках bug bounty. Формально это другой кейс, но для рынка картина складывается неприятная: за короткий промежуток времени вокруг одной и той же платформы всплывают сначала проблемы с неаутентифицированным доступом, а затем подтвержденная эксплуатация критической RCE. Для CISO и ИТ-директоров это повод не спорить о терминологии, а проверить инвентаризацию всех экземпляров ServiceNow, включая тестовые, региональные и давно забытые self-hosted-развертывания, которые любят переживать несколько оргструктурных реформ подряд.
Практический вывод для команд разработки и эксплуатации предельно приземленный. Если у компании есть self-hosted ServiceNow, обновление до исправленного релиза нужно считать аварийной задачей, а не пунктом ближайшего спринта. Параллельно имеет смысл проверить логи обращений к /assessment_thanks.do и соседним pre-auth-маршрутам, поднять ретроспективу хотя бы с 18 июля и сопоставить ее с любыми аномалиями в поведении инстанса. Поскольку исследователи уже видят альтернативный путь к той же primitive удаленного выполнения кода, ставка только на IOC или только на блокировку известного PoC здесь слабая. Нужны и патч, и охота за следами эксплуатации, и пересмотр временных правил детекта. Для продуктовых и платформенных команд урок тоже знакомый: ИИ-слой в enterprise-платформе не отменяет старую школу AppSec. Чем сложнее платформа и чем больше в ней встроенной логики, тем выше цена одной ошибки в boundary между «песочницей» и реальным кодом.
Главный вопрос теперь не в том, будет ли расти число попыток эксплуатации, а в том, насколько быстро компании признают, что уязвимость ServiceNow уже стала операционным риском, а не новостью из чужой ленты. На рынке, где одна платформа одновременно автоматизирует сервисные процессы, хранит чувствительные данные и связывает десятки внутренних систем, задержка с патчем быстро превращается в дорогую форму оптимизма. Подробности первичного отчета можно сверить в .