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