ServiceNow признала инцидент, из-за которого злоумышленники смогли запрашивать данные из клиентских инстансов через API без аутентификации. Для тех, кто хранит в платформе заявки, HR-данные, внутреннюю документацию и следы security-расследований, такая утечка данных ServiceNow выглядит не как рядовой баг, а как напоминание: сервис-деск давно стал одним из самых удобных входов в корпоративную кухню.
О проблеме, как пишет BleepingComputer, компания сообщила не публичным постом на главной, а через закрытый support bulletin и индивидуальные кейсы поддержки. По данным из бюллетеня, 5 июня 2026 года ServiceNow развернула обновление безопасности на hosted-инстансах клиентов. Оно закрыло уязвимость, которая при определенных условиях позволяла неаутентифицированному пользователю получить больше доступа к инстансу, чем предполагалось. После обновления доступ к проблемному API-эндпоинту ограничили только для аутентифицированных пользователей.
Самый неприятный фрагмент во всей истории не в наличии бага, а в том, что его успели использовать. ServiceNow подтвердила, что атакующие успешно выполняли запросы к таблицам клиентских инстансов. Какие именно данные были извлечены, компания не раскрыла. Но специфика платформы делает список гипотез коротким и тревожным: тикеты IT-поддержки, данные сотрудников, внутренние инструкции, сведения об активах, отчеты об инцидентах безопасности, настройки рабочих процессов и конфигурационные детали корпоративных систем. Если кто-то до сих пор считает, что сервисные заявки неинтересны атакующим, достаточно вспомнить, сколько паролей, токенов, ключей API и служебных пояснений команды по привычке оставляют в переписке во время troubleshooting.
Публичных технических деталей ServiceNow почти не дала, поэтому обсуждение быстро переехало в сообщества администраторов. По сообщениям на Reddit, проблема могла быть связана с REST-эндпоинтом /api/now/related_list_edit/create. Один из комментаторов утверждал, что для него был выставлен параметр requires_authentication=false, из-за чего неаутентифицированные запросы получали доступ к данным инстанса. Тот же источник связывал обновление от 5 июня с переключением этого параметра в true. Формально это не официальный разбор вендора, но даже такой уровень детализации уже достаточен, чтобы понять масштаб организационной проблемы: когда ошибка в конфигурации API добирается до production в enterprise-платформе, последствия редко ограничиваются красивой строчкой в changelog.
Отдельно ServiceNow указала, кого считает зоной риска. Инцидент в первую очередь затрагивает клиентов на платформенном релизе Australia, а также тех, кто работал на более старых релизах и внес определенные изменения в конфигурацию инстансов. Какими именно были эти изменения, компания в публичном пересказе не уточнила. Зато дала понятный operational signal: affected customers уже получили support cases. Если кейс не пришел, вендор на текущий момент не считает организацию затронутой. Это полезный ориентир, но не индульгенция. В историях с API и журналированием лучше исходить не из формулы нас не уведомили, значит все чисто, а из реальных логов и ретроспективы запросов.
У администраторов уже появились и базовые индикаторы компрометации. В частности, коллеги советуют просмотреть логи на обращения к /api/now/related_list_edit и отдельно проверить запросы с IP-адреса 51.159.98.241. ServiceNow также рекомендует анализировать, какие записи могли быть доступны через уязвимый путь, пересмотреть тикеты и другие объекты на предмет чувствительной информации, ротировать учетные данные и токены, которыми обменивались в support- и workflow-процессах, а также убедиться, что логирование API вообще включено. Последний пункт особенно показателен: многие компании всерьез занимаются EDR, SIEM и identity, но по-прежнему относятся к служебным SaaS-платформам как к черному ящику, где аудит либо настроен по остаточному принципу, либо включается уже после инцидента.
Для разработчиков, продуктовых команд и IT-руководителей эта история важна по двум причинам. Во-первых, утечка данных ServiceNow еще раз показывает, что атаки все чаще идут не в лоб через периметр, а через операционные платформы, где бизнес сам складывает в одно место знания о системах, людях и процессах. Во-вторых, границы между ITSM, HR, SecOps и внутренней автоматизацией давно размылись: одна уязвимая точка в API может неожиданно открыть доступ не к абстрактной базе, а сразу к картине всей компании. Для бизнеса это означает простой вывод: тикетные системы и workflow-платформы нужно включать в тот же класс контроля, что и IAM, репозитории кода или секрет-хранилища. Иначе одна неудачная настройка превратит служебный инструмент в каталог корпоративных слабых мест.
Пока ServiceNow не сообщила, будет ли присвоен CVE, как долго продолжалась подозрительная активность и был ли подтвержден фактический вывод данных за пределы клиентских инстансов. Но даже без этих ответов инцидент уже фиксирует неприятный тренд: чем больше бизнес завязывает критические процессы на крупные SaaS-платформы, тем дороже обходятся не только уязвимости в коде, но и ошибки в логике доступа к API. Для рынка это плохая новость не потому, что очередной вендор снова что-то пропустил, а потому, что сервисные системы окончательно стали источником данных, за которыми охотятся наравне с почтой, VPN и облачными панелями.