Уязвимость Ivanti Sentry с максимальной оценкой опасности перешла из разряда «срочно обновить» в режим полноценного инцидента: спустя сутки после выхода патча исследователи уже фиксируют атаки на внешние шлюзы. Для российских и русскоязычных ИТ-команд это еще одно напоминание, что окно между публикацией исправления и реальной эксплуатацией теперь измеряется не неделями, а часами.
Речь идет о CVE-2026-10520 — баге в Ivanti Sentry, который позволяет выполнить код с правами root на интернет-доступных узлах. Как пишет BleepingComputer, проблема связана с внедрением команд ОС. Ivanti закрыла дыру 10 июня 2026 года, выпустив версии Sentry R10.5.2, R10.6.2 и R10.7.1. На момент публикации патча компания утверждала, что не видит признаков эксплуатации в реальных атаках. Но уже на следующий день некоммерческая организация Shadowserver сообщила, что злоумышленники успели добраться до большинства видимых из интернета инсталляций.
Важно понимать, что Ivanti Sentry — это не очередной второстепенный компонент в корпоративном зоопарке. Раньше продукт был известен как MobileIron Sentry; он работает как защищенный шлюз между корпоративными бэкендами и удаленными мобильными устройствами. Если атакующий получает root на таком узле, история быстро выходит за пределы самого шлюза: дальше появляются шансы на перехват трафика, закрепление в инфраструктуре и движение внутрь сети. Именно поэтому уязвимость Ivanti Sentry выглядит особенно неприятно для компаний с мобильным доступом к почте, внутренним приложениям и MDM-контуром.
По данным Shadowserver, в их собственных сканах нашлось 19 уязвимых экземпляров Sentry, причем как минимум два из них уже были бэкдорированы. При этом исследователи отдельно оговорились: реальное число может быть выше, потому что часть инстансов недоступна для их поисковой инфраструктуры, вероятно из-за блокировок. Сигнал для администраторов довольно прямой: если внешний Sentry к этому моменту не обновлен, исходить стоит не из оптимистичного сценария «нас, возможно, не задело», а из более жесткого «компрометация уже могла произойти». Для SOC и инфраструктурных команд это означает не только срочный патчинг, но и проверку на пост-эксплуатацию: неизвестные учетные записи, подозрительные процессы, изменения конфигурации, артефакты веб-шеллов и нестандартные исходящие соединения.
Отдельный дискомфорт здесь создает скорость эскалации. В день выхода исправления Ivanti еще говорила об отсутствии подтвержденных атак, а уже 11 июня появилась информация о массовых попытках эксплуатации на фоне публичного proof-of-concept. Это хорошо описывает нынешнюю механику рынка уязвимостей: как только появляется патч, он становится дорожной картой не только для защитников, но и для атакующих. Разобрать diff, собрать рабочий эксплойт и пустить его в ход теперь могут очень быстро, особенно если речь о пограничном устройстве, доступном из интернета и встроенном в корпоративный периметр.
История выглядит еще менее случайной, если вспомнить бэкграунд Ivanti последних лет. Продукты компании давно находятся под повышенным вниманием атакующих именно потому, что они стоят на входе в корпоративные сети и часто дают удобную стартовую точку для более глубокой компрометации. BleepingComputer напоминает, что в январе Ivanti уже закрывала две критические уязвимости в Endpoint Manager Mobile, которые использовались как zero-day против «очень ограниченного числа клиентов». А в мае 2026 года американское агентство CISA потребовало от федеральных ведомств срочно обновить Ivanti-системы после предупреждения о другой активно эксплуатируемой уязвимости удаленного выполнения кода в EPMM.
Статистика у CISA тоже говорит сама за себя. За последние годы агентство внесло в перечень активно эксплуатируемых 34 уязвимости в различных продуктах Ivanti, и 12 из них использовались в атаках с вымогателями. На этом фоне нынешняя уязвимость Ivanti Sentry — не отдельная неприятная новость, а часть устойчивого тренда: инфраструктурные продукты, через которые идет удаленный доступ и управление устройствами, становятся для атакующих слишком выгодной целью. Для бизнеса вывод неприятный, но полезный: такие системы нельзя считать «настроили и забыли». Их нужно держать в коротком цикле обновлений, телеметрии и проверки компрометации, как VPN-шлюзы, почтовые прокси или внешние IAM-компоненты.
Для разработчиков и продуктовых команд здесь тоже есть практический вывод. Если мобильные приложения, внутренние API и служебные сервисы завязаны на Sentry или соседние MDM-компоненты, инцидент на шлюзе быстро превращается в проблему всей платформы. Значит, вопрос уже не только в патче от вендора, но и в архитектуре доверия: какие сервисы реально доступны через этот контур, какие секреты и токены там проходят, насколько быстро можно изолировать сегмент и перевыпустить доступы. Чем плотнее мобильный периметр сшит с внутренними системами, тем дороже обходится один пропущенный advisory.
Сейчас главный вопрос не в том, будет ли у этой истории продолжение, а в том, сколько компаний по-прежнему относятся к пограничным appliance как к «черным ящикам», которые достаточно просто обновлять по расписанию. Случай с Ivanti Sentry показывает обратное: если продукт стоит на внешнем краю сети и получает патч под активный интерес исследователей и атакующих, его нужно рассматривать как потенциальный инцидент сразу после публикации исправления, а не после появления официального признания от вендора.