ServiceNow выпустила исправления сразу для четырех багов в ServiceNow AI Platform, и три из них компания оценила на максимальные 10.0 по CVSS. Для русскоязычной IT-аудитории здесь важна не сама громкая цифра, а практическая деталь: облачные инстансы вендор уже обновил сам, а вот тем, кто держит self-hosted развертывания, патчи нужно ставить своими руками, иначе уязвимости ServiceNow могут остаться открытой дверью для атаки без логина и пароля.
О проблеме, как пишет The Hacker News, ServiceNow сообщила 27 августа 2026 года. В advisory перечислены четыре CVE. Первая, CVE-2026-18885, описана как code injection в GraphQL Composite Data API: при определенных условиях неаутентифицированный атакующий может выполнить произвольный код и получить доступ к данным инстанса или изменить их. Вторая, CVE-2026-18886, связана с некорректным контролем доступа в обработчике загрузки изображений для системной конфигурации; итогом может стать создание или изменение данных с последующей эскалацией привилегий. Третья, CVE-2026-74820, это SQL-инъекция через dynamic schema ORDER BY clause, позволяющая выполнять произвольные SQL-запросы к базовой БД экземпляра. Четвертая, CVE-2026-6876, получила 8.7 балла и касается sandbox escape в Now Platform с возможностью выполнения произвольного кода.
Самое неприятное в этой истории даже не набор техник, а профиль атаки. Для трех багов с оценкой 10.0 ServiceNow указала одинаковый вектор CVSS 4.0: атака доступна по сети, имеет низкую сложность, не требует привилегий и не требует действий пользователя. На нормальном человеческом языке это означает, что речь идет не о редкой лабораторной комбинации, а о дефектах, которые в неудачной конфигурации или неподготовленной среде можно превратить в очень прямолинейный путь к данным, логике платформы и, потенциально, к отказу сервисов. Отдельно стоит смотреть на сочетание GraphQL, SQL-инъекции и sandbox escape в одной волне исправлений: для корпоративной платформы, где живут процессы, каталоги услуг, интеграции и чувствительные внутренние данные, такой набор выглядит особенно токсично.
ServiceNow отдельно уточнила, что ее собственные hosted-инстансы уже получили security update, а партнерам и self-hosted заказчикам обновления просто предоставлены. Это важное разделение ответственности. Если у компании ServiceNow стоит как управляемый сервис, окно риска уже, вероятно, сокращено усилиями вендора. Если же инстанс разворачивается и обслуживается самостоятельно, вся привычная дисциплина patch management резко превращается из формальности в вопрос выживания. В advisory перечислены затронутые ветки: Xanadu до Patch 11 Hot Fix 7a, Yokohama до Patch 12 Hot Fix 3b и до Patch 13 Hot Fix 4, Zurich до нескольких патчей вплоть до Patch 12, а также Australia до Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 или Patch 5. При этом по CVE-2026-18886 для состояния «Any version before Australia Patch 5» указан статус unknown, тогда как по остальным трем этот же диапазон помечен как affected. Для администраторов это сигнал не спорить с формулировками, а сверять конкретную ветку и патч по advisory строка в строку.
Контекст тоже добавляет нервозности. Нынешнее уведомление вышло вскоре после истории с CVE-2026-6875, еще одной pre-auth sandbox escape в той же платформе. Searchlight Cyber сообщила о ней ServiceNow 1 апреля 2026 года, а публичный advisory появился 13 июля. После этого компания Defused заявила, что наблюдает эксплуатацию CVE-2026-6875 в реальных атаках, но затем выпустила коррекцию: перехваченный payload совпал с опубликованным proof-of-concept от Searchlight Cyber. То есть речь шла не о подтвержденной масштабной кампании, а о более скромном факте обращения известного PoC. Для защитников разница не академическая: одно дело активное массовое exploitation in the wild, другое дело тестирование опубликованной техники. Но осадок все равно остается, потому что платформа уже не впервые за короткий срок получает pre-auth проблемы вокруг sandbox-механизмов.
Есть и еще один штрих, который будет интересен тем, кто в компаниях привык опираться на NIST и CISA как на базовые внешние ориентиры. Оценки 10.0 в этом случае выставлены самой ServiceNow, которая выступает CVE Numbering Authority для собственных продуктов. С 15 апреля 2026 года NIST, как отмечается в материале, обогащает только те уязвимости, которые попали в каталог Known Exploited Vulnerabilities от CISA, затрагивают федеральный софт США или признаны критическими по Executive Order 14028. По состоянию на 28 августа 2026 года ни одна из четырех новых дыр в каталог CISA KEV не входила. Формально это не снижает риск, но меняет привычную логику приоритизации: командам безопасности приходится принимать решение не по внешнему «штампу срочности», а по техническому описанию, архитектурной роли ServiceNow внутри компании и по факту существования pre-auth цепочек.
Для разработчиков, платформенных инженеров и IT-руководителей вывод довольно приземленный. Если ServiceNow у вас завязан не только на тикеты, но и на внутренние workflow, автоматизацию, интеграции с HR, IAM, каталогами услуг и данными бизнес-подразделений, то компрометация инстанса может стать не отдельным security-инцидентом, а точкой входа в большой организационный бардак. Особенно неприятна SQL-инъекция в платформе такого класса: в enterprise-ландшафте подобные системы редко живут в изоляции и почти всегда являются центром оркестрации процессов. При этом сама ServiceNow заявила, что на текущий момент ей неизвестны случаи эксплуатации этих четырех уязвимостей, а The Hacker News на 28 августа не нашла публичного exploit-кода для трех новых CVSS 10.0. Это хорошая новость, но из той категории, которая действует недолго. Когда уязвимость описана достаточно конкретно, а список затронутых версий уже опубликован, окно для спокойной установки патчей обычно быстро сжимается.
Главный вопрос теперь не в том, выглядит ли оценка 10.0 слегка пугающей, а в том, насколько быстро крупные заказчики научатся относиться к корпоративным платформам вроде ServiceNow как к части attack surface, а не как к «внутреннему сервису, который трогают по остаточному принципу». Последние месяцы показывают неприятный тренд: если в системе есть GraphQL, сложная схема данных, песочницы и глубокий доступ к бизнес-процессам, то атакующие будут смотреть на нее не как на helpdesk, а как на короткий путь к инфраструктуре и данным.