ServiceNow выпустила патчи для трёх уязвимостей максимальной критичности в AI Platform, и это тот случай, когда формулировка «максимальной» не выглядит маркетинговым драматизмом. Все три проблемы допускают атаку без аутентификации, при низкой сложности и без участия пользователя, а значит уязвимости ServiceNow быстро переходят из разряда «поставим в ближайшее окно» в разряд «чинить надо вчера».
О проблеме 28 августа сообщило BleepingComputer. Речь идёт о CVE-2026-18885, CVE-2026-18886 и CVE-2026-74820 в ServiceNow AI Platform, которая раньше называлась Now Platform. По описанию вендора, первая брешь позволяет выполнить произвольный код, вторая связана с внедрением кода и ведёт к повышению привилегий, третья открывает доступ к данным инстанса или их изменению через SQL injection. Для платформы, на которой крутятся корпоративные рабочие процессы, автоматизация и AI-сценарии, набор максимально неприятный: от захвата логики до работы с данными напрямую.
Масштаб здесь тоже не абстрактный. ServiceNow называет AI Platform enterprise-grade PaaS-платформой для встраивания ИИ в ключевые бизнес-процессы и утверждает, что она обслуживает более 100 тысяч корпоративных AI-приложений у 85% компаний из Fortune 500. То есть речь не о нишевом SaaS, который живёт в углу у пары стартапов, а об инфраструктурном слое для крупных предприятий. Если в такой платформе есть pre-auth-уязвимости с низким порогом эксплуатации, это автоматически история не только для ИБ-команд, но и для разработчиков внутренних сервисов, владельцев платформ и CIO, которые обычно узнают о подобных вещах уже в момент неприятного разговора с советом директоров.
ServiceNow заявила, что на момент публикации не видит признаков активной эксплуатации этих трёх багов против клиентских инстансов. Но расслабляться здесь трудно, потому что контекст у компании уже довольно плотный. В тот же день вендор отдельно закрыл ещё одну серьёзную проблему, CVE-2026-6876, уязвимость класса sandbox escape в той же AI Platform. Она получила высокий уровень опасности и, по данным ServiceNow, может позволить атакующему с базовыми привилегиями добиться удалённого выполнения кода на целевой системе. Формально это уже не та же категория риска, что у трёх pre-auth-дыр, но практический вывод для администраторов один: если инстанс не обновлён, спорить о приоритетах поздно.
Патчи выпущены для нескольких веток и релизов платформы. Обновления получили Xanadu Patch 11 Hot Fix 7a, Yokohama Patch 12 Hot Fix 3b и Yokohama Patch 13 Hot Fix 4, целый набор сборок Zurich, включая Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m для m-branch, Patch 10 Hot Fix 3 для standard, а также Patch 11 и Patch 12. Для линии Australia закрытия доступны начиная с Patch 2 Hot Fix 3 и далее до Australia Patch 5. Облачную платформу ServiceNow исправила со своей стороны, а владельцам self-hosted-инстансов прямо рекомендовала как можно быстрее ставить соответствующие обновления или переходить на уже исправленный релиз. Для компаний с собственной инсталляцией это стандартный, но неприятный сюжет: пока SaaS-клиенты спят спокойнее, on-prem и self-hosted снова получают весь набор обязанностей взрослой жизни.
Особенно важно, что история не выглядит единичным всплеском. Два года назад злоумышленники уже использовали связку из трёх уязвимостей ServiceNow — CVE-2024-4879, CVE-2024-5178 и CVE-2024-5217 — вместе с публично доступными эксплойтами, чтобы атаковать частные компании и государственные структуры по всему миру и красть данные. А в июле 2026 года компания Defused сообщила, что атакующие уже эксплуатируют другую критическую брешь в ServiceNow AI Platform — CVE-2026-6875, pre-auth sandbox escape. Наконец, месяц назад ServiceNow частным образом раскрывала инцидент, в котором исследователи безопасности или исследование со стороны клиента использовали уязвимость неаутентифицированного доступа через API-эндпоинт и могли запрашивать данные из клиентских инстансов. Иными словами, уязвимости ServiceNow давно перестали быть темой только для вендорских бюллетеней: за ними явно следят и исследователи, и атакующие.
Для русскоязычной IT-аудитории практический вывод довольно прямой. Если ServiceNow используется как платформа для ITSM, HR, customer workflows или AI-автоматизации, обновление надо рассматривать не как рутину, а как срочную задачу с понятным риском компрометации. Разработчикам и платформенным командам стоит проверить кастомные интеграции и всё, что завязано на AI Platform, особенно если в инфраструктуре есть self-hosted-инстансы, собственные расширения и доступ из смежных систем. ИБ-командам имеет смысл не ограничиваться патчем: нужны проверка логов на аномальные запросы, ревизия публично доступных интерфейсов и пересмотр сценариев сегментации. Проблема таких платформ в том, что они часто становятся слишком удобной точкой входа: в одном месте собраны процессы, данные, привилегии и автоматизация. Для атакующего это не просто сервис, а готовый мультиинструмент.
На более широком уровне история с ServiceNow хорошо показывает, куда смещается риск в корпоративном AI-стеке. Чем активнее вендоры встраивают ИИ в базовые бизнес-процессы, тем меньше разница между «уязвимостью в AI-платформе» и «уязвимостью в центральной операционной системе компании». Поэтому уязвимости ServiceNow здесь важны не только сами по себе: они напоминают рынку, что AI в enterprise давно живёт не в песочнице для экспериментов, а в продуктивной инфраструктуре, где одна неаутентифицированная дыра может быстро превратиться в проблему для безопасности, данных и управления доступом сразу.