Безопасность
Уязвимость платформы ServiceNow AI ставит программное обеспечение для рабочих процессов агентов на график исправлений
CVE-2026-6875, критическая уязвимость обхода песочницы платформы ServiceNow AI, вызвала экстренные рекомендации по исправлению и спорные сообщения об эксплуатации после публичного раскрытия.
Автор: Лео В ·
Критическая уязвимость в ServiceNow Платформа ИИ вернула программное обеспечение для корпоративных рабочих процессов в центр обсуждения безопасности ИИ. CVE-2026-6875 описан в записи CVE как побег из песочницы это могло позволить неаутентифицированному пользователю в определённых обстоятельствах выполнять код в платформе ServiceNow. Компания ServiceNow сообщает, что решила эту проблему, развернув обновления на размещённых экземплярах и предоставив обновления безопасности клиентам и партнёрам с самостоятельным размещением. В бюллетене производителя говорится, что на данный момент ему не известно о случаях эксплуатации уязвимостей на экземплярах ServiceNow, в то время как несколько компаний по кибербезопасности опубликовали отчёты, утверждающие о попытках или активной эксплуатации после раскрытия информации. Этим разрывом как раз объясняется, почему клиентам следует сначала установить обновления, а затем обсуждать уровень уверенности.
Затронутые версии, указанные в публичных уведомлениях, включают версии для Бразилии, Австралии, Цюриха и Йокогамы до установки указанных исправлений или горячих патчей. The Канадский центр кибербезопасности призвал пользователей и администраторов ознакомиться с рекомендацией ServiceNow и применить необходимые обновления. CVE.report перечисляет CVSS 4.0 вектор с высоким воздействием на конфиденциальность, целостность и доступность. Проще говоря, это не косметическая проблема. ServiceNow часто находится рядом с процессами управления идентификацией, HR, IT-услуг, поставщиков и операционными рабочими потоками. Укрепление там может стать укреплением на уровне бизнес-процессов.
RedLeggВ бюллетене говорилось, что эта уязвимость может позволить управляемому атакующим JavaScript выйти за пределы заданных ограничений скриптов и выполняться с более широкими привилегиями платформы, что потенциально может привести к доступу к данным, созданию учетной записи администратора и злоупотреблению подключенными MID-серверы. MalloryПубличная страница уязвимости описывала аналогичное воздействие, включая возможное латеральное перемещение через подключенную инфраструктуру прокси или MID-серверов. Эти сторонние отчеты следует рассматривать как анализ безопасности, а не как подтверждение вендором каждого возможного пути атаки. Тем не менее, они полезны, поскольку переводят абстрактный язык CVE в вопросы для защиты.
Спорный статус эксплуатации не должен замедлять устранение. ServiceNow заявляет, что не осведомлена об эксплуатации. RedLegg и другие средства безопасности утверждают, что эксплуатация наблюдалась. Защитники не обязаны разрешать разногласия в публичных записях перед принятием мер, потому что уязвимый компонент доступен до аутентификации, является серьёзным и в некоторых развертываниях доступен из интернета. Правильным ответом является проверка уровня патчей, исследование логов и предположение, что публичные технические детали будут развиваться быстрее, чем календари изменения контроля.
Этикетка ИИ важна, потому что корпоративные агентские системы все больше зависят от таких платформ, как ServiceNow. Агент поддержки, который может создавать обращения, обновлять записи, запускать рабочие процессы или выполнять запросы к внутренним таблицам, полезен только в том случае, если граница платформы надежна. Если злоумышленник сможет выйти из песочницы на уровне рабочего процесса, агент перестанет быть единственным источником риска автоматизации. Платформа, на которой работает агент, становится поверхностью атаки.
Контрольный список по устранению проблем прямой. Размещенные у поставщика клиенты должны проверить, получили ли их экземпляры, управляемые поставщиком, обновление. Клиенты и партнеры с собственным размещением должны убедиться, что они используют исправленные версии. Команды по безопасности должны проверять неаутентифицированные запросы к затронутым конечным точкам, аудировать неожиданное создание административных учетных записей, проверять необычный доступ к таблицам, инспектировать выполнение скриптов и изменения рабочих процессов, а также проверять подключенную инфраструктуру на наличие неожиданных команд. Это не гламурная работа, но именно она предотвращает превращение агентских рабочих процессов в цепочки неконтролируемых привилегий.
Безопасность ИИ не ограничивается только внедрением подсказок или неправильным использованием модели. Обычные уязвимости корпоративного программного обеспечения становятся более значимыми, когда оно связано с автоматизацией. Чем больше компании интегрируют ИИ-системы в рабочие процессы, тем больше уязвимость в этой системе может повлиять на бизнес. Модель может быть полностью согласована и при этом работать на скомпрометированной платформе.
Роль ServiceNow в крупных организациях делает уязвимость особенно критичной. Платформа часто обрабатывает заявки, утверждения, запросы на доступ, учетные записи активов, HR-процессы и управление изменениями. Эти записи описывают, как функционирует организация. Если злоумышленник сможет их читать или изменять, последствия могут выходить за рамки кражи данных. Злоумышленник может узнать, какие системы уязвимы, кто утверждает доступ, какие существуют окна для обслуживания и где операционные команды уже перегружены. Метаданные рабочего процесса могут использоваться для разведки.
Функции ИИ добавляют еще один уровень, поскольку они могут упростить выполнение действий в рабочем процессе в масштабах. Агент, который подводит итоги происшествий или рекомендует следующие шаги, может быть неуязвимым компонентом, но он работает в той же среде разрешений. Поэтому командам по безопасности следует разделять два вопроса. Во-первых, патчена ли платформа против CVE-2026-6875? Во-вторых, ограничены ли автоматизации на основе ИИ только теми разрешениями и данными, которые им действительно необходимы? Патч исправляет известную ошибку. Он автоматически не решает проблему избыточных привилегий.
Общественное несогласие по поводу эксплуатации часто встречается в быстро развивающихся случаях уязвимости. У поставщиков может быть телеметрия, которая не показывает подтверждённых компрометаций в управляемой среде. Компании по безопасности могут видеть сканирование, попытки доказательства концепции или активность в клиентских средах, похожую на эксплуатацию. Оба утверждения могут быть сделаны добросовестно и при этом оставлять клиентов в неопределенности. Практический ответ — записывать состояние патча, сохранять журналы и проводить охоту на угрозу с ограничением по времени, а не ждать идеального общественного консенсуса.
Для специалистов по реагированию на инциденты временные рамки имеют значение. Как только серьезная CVE становится публичной, злоумышленники часто переходят от чтения описаний в уведомлениях к быстрому созданию проверочных инструментов. Даже неполные технические детали могут быть достаточными для поиска уязвимых экземпляров или тестирования конечных точек. Именно поэтому организациям не следует рассматривать обновления от поставщика как полный ответ, если у них есть собственные компоненты, коннекторы, MID-серверы или пользовательские скрипты. Подключенная инфраструктура может сохранять риск даже после того, как основной сервис был обновлен.
Экспозиция MID Server заслуживает особого внимания, поскольку он предназначен для того, чтобы соединять ServiceNow с внутренними системами. Компонент-мост может быть полезным и опасным по одной и той же причине: он достигает мест, куда внешняя платформа не может попасть напрямую. Если злоумышленник воспользуется уязвимостью платформы, чтобы воздействовать на MID Server, граница безопасности может сместиться с уровня SaaS во внутренние сети. Именно поэтому защитникам следует проверять не только логи ServiceNow, но и нижестоящие системы, которые приняли команды или запросы в уязвимый период.
Этот случай также показывает, почему командам платформ ИИ и традиционным командам безопасности необходима общая модель работы. Владельцы продуктов ИИ могут сосредотачиваться на поведении модели и опыте пользователя. Команды безопасности могут сосредотачиваться на CVE и окнах для установки патчей. На практике эти две области сливаются. Когда корпоративная платформа добавляет ИИ-агентов, права доступа, интеграции, ведение журналов и процесс выпуска становятся частью истории безопасности ИИ. Модель нельзя оценивать в отрыве от программного обеспечения, которое обеспечивает её охват.
Советы директоров и руководители должны рассматривать это как сигнал по вопросам управления. Планы внедрения ИИ часто делают акцент на производительности и ускорении рабочих процессов. Они также должны включать ответственность за экстренное исправление, инвентаризацию платформ с поддержкой ИИ, проверку сервисных аккаунтов и чёткую карту систем, которые могут действовать от имени пользователей. Уязвимость в платформе ИИ — это не просто IT-заявка. Она может повлиять на непрерывность операционной деятельности, если платформа координирует работу по всему бизнесу.
Самая здоровая реакция — это не паника. Это дисциплинированная срочность. Подтвердите исправленную версию, ищите признаки необычного доступа, уменьшайте ненужные разрешения, меняйте учетные данные там, где есть признаки их компрометации, и документируйте принятое решение. Командам по безопасности не нужно превращать каждую уязвимость CVE в кризис. Им нужно относиться к уязвимостям, выявленным до аутентификации, в платформах с привилегированными рабочими процессами как к событиям, заслуживающим явного владения и четкого закрытия.
Организации также должны обратить внимание на пользовательский код. Развертывания ServiceNow часто включают скрипты, интеграции, пользовательские таблицы и бизнес-правила, которые отражают годы внутренней работы. Уязвимость на уровне платформы может взаимодействовать с этими настройками таким образом, которого не может предсказать обычная инструкция. Команды безопасности должны спросить владельцев приложений, какие чувствительные таблицы, рабочие процессы и интеграционные аккаунты будут наиболее важны в случае злоупотребления привилегиями платформы. Такая приоритизация делает обзор журналов более полезным.
Эта уязвимость также подчеркивает важность сегментации среды. Инстансы разработки, тестирования и производства могут иметь разные сроки обновления и разный уровень раскрытия данных. Менее защищенный непроизводственный инстанс все еще может содержать реальные данные или учетные данные, если управление слабое. Развертывания AI-платформ иногда начинаются в тестовых средах, где контрольная защита слабее. Эти среды не следует игнорировать при исправлении, просто потому что они не являются основной производственной службой.
Общение с владельцами бизнеса имеет значение, потому что исправление платформ рабочих процессов может быть разрушительным. Некоторые команды могут беспокоиться, что обновления нарушат работу пользовательских автоматизаций или интеграций. Это беспокойство реально, но его необходимо сопоставить с серьезностью уязвимости платформы до аутентификации. Руководители по безопасности должны предоставить владельцам бизнеса четкое заявление о рисках, ожидаемое окно обслуживания и контрольный список проверки после установки патча. Неопределенная срочность вызывает сопротивление. Конкретная срочность обеспечивает планирование работы.
Этот случай также показывает, почему продавцам нужны быстрые обновления консультаций на простом языке. Клиентам нужен не только идентификатор CVE. Им нужны затронутые версии, исправленные версии, условия воздействия, шаги по смягчению последствий и уверенность в случае эксплуатации. Когда отчеты третьих лиц и заявления продавцов расходятся, ясность становится еще более важной. Зрелый процесс консультирования должен признавать, что известно, что неизвестно и что клиенты должны делать, пока продолжается расследование.
Для команд по управлению ИИ вывод заключается в том, чтобы расширить инвентаризацию. Недостаточно просто перечислять модели и чат-боты. Инвентаризация должна включать платформы, где функции ИИ могут запускать рабочие процессы, считывать записи или действовать через соединители. Эти системы могут оказаться более значимыми, чем отдельная модель, потому что они находятся ближе к выполнению бизнес-процессов. CVE-2026-6875 напоминает, что граница платформы может нарушиться раньше, чем будет протестирована граница модели.
Дело с ServiceNow также напоминает о том, что программы безопасности ИИ не могут ждать появления нового словаря. Контроли знакомы: управление патчами, принцип наименьших привилегий, сегментация, ведение журналов, реагирование на инциденты, взаимодействие с поставщиками и контроль изменений. Изменяется скорость и охват рабочих процессов, построенных поверх этих контролей. Уязвимая платформа, которая только хранила тикеты, уже была важна. Уязвимая платформа, которая хранит тикеты, координирует агентов, работает с идентификацией и запускает последующие действия, важнее. Слой ИИ увеличивает ценность старых контролей, а не заменяет их.
Самое безопасное закрытие инцидента будет основано на доказательствах. Командам по безопасности следует избегать объявления о победе только потому, что экземпляр сообщает о зафиксированной версии. Они должны задокументировать, когда был установлен патч, какие угрозы существовали до этого момента, какие журналы были проверены, была ли обнаружена подозрительная активность и какие учетные данные или интеграции на стороне были проверены. Эта документация будет иметь значение, если в будущем отчетность изменит представление об эксплуатации. Она также поможет руководству понять разницу между исправленной уязвимостью и завершенным анализом инцидента. Для регулируемых компаний эта письменная запись может также поддерживать аудиты, вопросы страховщиков и отчетность перед советом директоров после сообщения о высокоопасной уязвимости. Она предоставляет командам реагирования оправданный документ, а не воспоминания о поспешных сообщениях в Slack и обновлениях тикетов, и помогает будущим командам понять, почему были приняты определенные меры сдерживания. Эта дисциплина кажется скучной только до тех пор, пока второе расследование не потребует доказательств во время реального аудита позже.
CVE-2026-6875 следует рассматривать как предварительный обзор давления на патчи в будущем. AI-функции добавляются в системы, которые уже одобряют доступ, маршрутизируют инциденты, обновляют записи и подключают поставщиков. Злоумышленники будут нацеливаться на эти системы, потому что права доступа там ценны. Защитники должны оценивать каждую AI-платформу по тем же стандартам, которые они применяют к любой привилегированной деловой системе: скорость выпуска патчей, ведение журналов, изоляция и ясный путь инцидента на случай, если песочница выйдет из строя. Эти меры контроля должны иметь назначенных владельцев и проверенные пути эскалации до того, как выйдет предупреждение.
Темы: ServiceNow, CVE-2026-6875, платформa ИИ, безопасность предприятий