История с уязвимостью ServiceNow за несколько дней успела пройти путь от тревожного алерта до неловкого уточнения: активность, которую часть клиентов могла принять за реальную атаку, по версии самой компании, оказалась связана с исследователями bug bounty. Для ИБ-команд и администраторов корпоративных платформ это не курьез, а напоминание: в облачной инфраструктуре грань между исследованием и инцидентом иногда исчезает быстрее, чем успевает собраться кризисный чат.
ServiceNow 10 июня опубликовала дополнительное уведомление по инциденту, а до этого через закрытую статью в базе знаний предупредила клиентов об аномальной активности, сообщает Dark Reading. Компания писала о некой проблеме безопасности, которая могла дать доступ шире задуманного, а неавторизованный пользователь сумел выполнить запросы к определенным таблицам инстансов у части клиентов. Формулировки были достаточно серьезными, чтобы многие восприняли ситуацию как возможный компромисс: речь шла не о теоретической дыре, а о наблюдаемой активности в боевых средах.
Технических подробностей в первом сообщении было немного. ServiceNow ограничилась описанием меры, внесенной в обновление от 5 июня: конфигурацию одного из эндпоинтов изменили так, чтобы доступ к нему был только у аутентифицированных пользователей. Отдельно компания уточнила, что проблема касается клиентов на релизе Australia, а также тех, кто внес определенные конфигурационные изменения в инстансах на более ранних релизах. Важная деталь для заказчиков: если компания не связывалась с конкретным клиентом напрямую, дополнительных действий от него на тот момент не требовалось. Иначе говоря, это был не массовый пожар по всей базе ServiceNow, а история про ограниченный круг сред и условий.
На следующий день картина стала менее драматичной, но не менее показательной. В публичном уведомлении ServiceNow сообщила, что по итогам расследования считает наблюдаемую активность результатом работы исследователей безопасности или собственных исследований клиентов. По данным компании, 3-4 июня 2026 года клиенты начали делиться с ней сабмишенами в свои bug bounty-программы о проблеме, которая при определенных обстоятельствах могла позволить неаутентифицированному пользователю получить нежелательный доступ к информации в инстансах ServiceNow. Эти сообщения, как утверждает вендор, были похожи на конфиденциальный репорт, отправленный в bug bounty-программу самой ServiceNow еще 22 апреля 2026 года.
Еще одна важная дата в этой цепочке событий - 7 июня. Именно тогда, по словам ServiceNow, два исследователя безопасности отправили отчет в ее bug bounty-программу. Компания добавила, что находится с ними в контакте, а сами исследователи заявили: их активность велась исключительно ради баг-баунти-репортов, без использования или сохранения данных. Формулировка аккуратная и юридически выверенная, но смысл понятен: то, что выглядело как потенциальное вторжение, с высокой вероятностью оказалось исследовательской активностью, причем распределенной сразу по нескольким организациям. Из-за этого некоторые клиенты могли получить похожие сабмишены от тех же исследователей и, мягко говоря, напрячься.
С практической точки зрения история неприятна по двум причинам. Первая: если в корпоративной SaaS-платформе появляется путь, по которому неаутентифицированный пользователь может добраться до данных, даже ограниченно и при особых условиях, это уже достаточно серьезный повод для экстренного обновления и уведомлений. Вторая: когда такую активность производят не злоумышленники, а багхантеры, у служб безопасности возникает почти неразрешимая дилемма. Реагировать надо как на атаку, потому что телеметрия и наблюдаемое поведение могут выглядеть одинаково. Но постфактум выясняется, что тревога была связана с внешним исследованием, которое вроде бы помогает экосистеме, а не ломает ее.
Именно на этой серой зоне сделал акцент Ensar Seker, CISO компании SOCRadar. В комментарии Dark Reading он отметил, что такие ситуации встречаются нечасто, но и исключением их не назовешь. По его словам, большинство исследователей bug bounty понимают рамки программ и стараются их соблюдать, потому что от этого зависят их репутация, будущий доступ и вознаграждение. Но в больших облачных средах граница между легитимным исследованием и несанкционированным тестированием может размываться, особенно если найденный путь неожиданно выводит исследователя за пределы изначальной цели или открывает доступ к производственным ресурсам.
Для русскоязычной IT-аудитории здесь несколько прямых выводов. Если ваша компания использует ServiceNow как часть критичных бизнес-процессов - от ITSM до внутренних workflow, - смотреть нужно не только на CVE и громкие слова в алертах, но и на то, какие именно релизы и настройки у вас развернуты. В этой истории компания прямо указала на релиз Australia и определенные изменения конфигурации в более ранних версиях. Второй вывод касается процессов реагирования. Когда вендор сообщает об аномальной активности, а потом корректирует версию событий, это не повод обвинять его в панике. Скорее это демонстрация того, как в реальности работает расследование: сначала фиксируется риск и вводятся ограничения, потом по мере валидации гипотез уточняется, кто именно стоял за активностью.
Для bug bounty-рынка этот случай тоже показателен. Индустрия любит повторять, что внешний ресерч делает продукты безопаснее, и в целом это правда. Но когда исследование затрагивает сразу несколько организаций и пересекается с продакшн-данными, выигрывают те программы, где заранее прописаны не только рамки, но и каналы срочной координации между исследователем, заказчиком и платформенным вендором. Иначе bug bounty легко превращается в упражнение по управлению репутационным ущербом: формально все искали уязвимость, а фактически SOC, владельцы платформы и клиенты живут несколько суток в режиме потенциального breach.
ServiceNow отдельно сообщила Dark Reading, что защитное обновление для размещенных у нее клиентских инстансов уже применено, затронутые заказчики были уведомлены напрямую, а круг пострадавших оказался нешироким. Это важное уточнение, но оно не снимает главный вопрос: как поставщикам крупных облачных платформ выстроить такие правила исследования, при которых поиск уязвимости ServiceNow не будет внешне неотличим от реальной атаки. Чем больше корпоративный софт опирается на единые облачные сервисы, тем дороже становится любая ошибка классификации - и для исследователей, и для вендора, и для клиентов, которые должны решить за минуты, перед ними багхантер или уже чужой оператор в инфраструктуре.