ServiceNow подтвердила инцидент безопасности: неизвестные атакующие использовали уязвимость ServiceNow, чтобы получить более глубокий несанкционированный доступ к части клиентских инстансов. Для компаний, которые держат на платформе сервис-деск, ITSM и внутренние процессы, это плохая новость не только про утечку данных, но и про неприятный вопрос к вендору: почему проблема, о которой внутри знали как минимум с апреля, дошла до реальной эксплуатации в июне.
О происшествии, как пишет The Hacker News, ServiceNow сообщила в клиентском advisory, доступном не всем публично. По данным компании, 5 июня 2026 года она развернула защитное обновление для размещенных у нее клиентских инстансов. Речь шла об ошибке, которая «в определенных обстоятельствах» позволяла неаутентифицированному пользователю получить больше доступа к экземплярам ServiceNow, чем предполагалось. Исправление свелось к изменению конфигурации одного из endpoint'ов: доступ к нему ограничили только для аутентифицированных пользователей. CVE у этой проблемы пока нет, что само по себе выглядит неловко для инцидента, который уже успели использовать на практике.
Самое важное в этой истории не формулировка advisory, а подтвержденный факт эксплуатации. ServiceNow заявила, что зафиксировала аномальную активность, связанную с этой уязвимостью, и увидела признаки успешных запросов к таблицам инстансов у «подмножества клиентов». Иначе говоря, речь не о гипотетической дыре из баг-баунти-отчета, а о кейсе, где атакующие уже добрались до данных. Компания добавила, что затронутые клиенты уведомлены напрямую. Представитель ServiceNow отдельно подчеркнул, что инцидент не был массовым и коснулся ограниченного числа заказчиков, но формулировка про «subset of customer instances were queried successfully» звучит достаточно прямо: доступ к данным удалось получить.
Под ударом оказались не все подряд. По словам ServiceNow, проблема относится к клиентам на релизе Australia, а также к тем, кто внес определенные изменения в конфигурацию инстансов на более ранних релизах. Это важная деталь для тех, кто живет в enterprise-реальности и привык считать managed SaaS зоной пониженного риска. Даже если платформа хостится у вендора, набор ваших собственных настроек и отклонений от базовой конфигурации может неожиданно стать частью поверхности атаки. В переводе на язык CIO и руководителей эксплуатации: «облако» не отменяет необходимости понимать, какие именно нестандартные настройки у вас живут в проде и как они влияют на безопасность.
Хронология тоже выглядит показательно. По данным ServiceNow, вредоносная активность началась 2 июня 2026 года. Уже 3-4 июня клиенты стали отправлять в свои bug bounty-программы сообщения о проблеме, которая в некоторых случаях позволяла неаутентифицированному пользователю получить нежелательный доступ к информации в инстансах ServiceNow. Эти сообщения, как уточнила сама компания, были похожи на конфиденциальную заявку, поступившую в ее bug bounty-программу еще 22 апреля 2026 года. А на Reddit пользователь под ником d3s7iny заявил, что его команда безопасности сообщила о проблеме ServiceNow и что внутри компании о ней знали с 7 апреля, но примерно два месяца считали не срочной и планировали закрыть в одном из будущих обновлений.
Это уже не просто техническая деталь, а вопрос к процессу triage у крупного SaaS-вендора. Если версия про апрельское внутреннее знание верна, получается неприятный сценарий: уязвимость, позволяющая анонимному пользователю получить лишний доступ, некоторое время жила в категории «не горит», пока не превратилась в инцидент с реальными запросами к клиентским таблицам. Да, пост на Reddit не равен официальному postmortem, и без полной внутренней переписки ServiceNow здесь рано раздавать окончательные оценки. Но сам факт, что компания в итоге признала успешную эксплуатацию на части инстансов, делает дискуссию о приоритетах исправления вполне предметной.
Для технических команд здесь несколько практических выводов. Первый: уязвимость ServiceNow затронула не только вопрос патча, но и вопрос конфигурационного дрейфа. Если организация сидит на Australia или на старых релизах с кастомными изменениями, надо не просто проверить, что обновление от 5 июня применено, а поднять весь список нестандартных настроек, связанных с внешними endpoint'ами и моделью аутентификации. Второй: стоит отдельно посмотреть журналы активности за период как минимум с 2 июня, а лучше и раньше, если есть подозрение, что разведка или попытки эксплуатации начались до официально подтвержденной даты. Третий: если ServiceNow у вас обслуживает кадровые процессы, тикеты поддержки, данные по внутренним активам или рабочие сценарии автоматизации, любой лишний доступ к таблицам может оказаться болезненнее, чем кажется на словах «частичный инцидент».
Для бизнеса история тоже неприятная, хотя и без громких слов про «катастрофу». ServiceNow давно воспринимается как инфраструктурный слой для внутренних процессов крупных компаний. Когда у такой платформы находится дыра, через которую можно без логина выйти на данные в клиентских инстансах, это бьет по доверию сильнее, чем очередная локальная ошибка в нишевом продукте. Особенно если до публичного признания уже успели появиться обсуждения на Reddit и сообщения от исследователей. Рынок SaaS в последние годы и так живет в режиме «не спрашивайте, где ваш периметр, покажите лучше ваши логи и матрицу доступа». Теперь к этому добавляется еще один старый, но неприятно живучий тезис: managed-сервис не делает управление риском чужой проблемой.
Уязвимость ServiceNow в этой истории важна не только как единичный баг, а как симптом. Чем больше корпоративные платформы превращаются в центр рабочих процессов, тем дороже обходится любая ошибка в аутентификации, endpoint'ах и логике доступа к данным. И главный вопрос после этого инцидента звучит уже не про конкретный июньский патч, а про то, как быстро крупные вендоры умеют переводить «не срочную» находку в режим реального кризиса, пока это еще можно сделать без чужого несанкционированного запроса к клиентским таблицам.