Уязвимость Check Point VPN эксплуатировали как минимум с 7 мая, а экстренное исправление вендор выпустил только 8 июня. Для компаний, которые держат удалённый доступ на этих шлюзах, это неприятный, но очень знакомый сценарий: патч уже есть, а у злоумышленников был почти месяц форы.
О проблеме сообщает The Register: Check Point закрыла критическую брешь CVE-2026-50751, связанную с обходом аутентификации в Remote Access VPN и Mobile Access. По данным компании, злоумышленник мог установить VPN-соединение без пароля пользователя. Это уже не история про «теоретический риск» из advisory: в одном из расследованных инцидентов аналитики увидели посткомпрометационную активность, связанную с аффилиатом Qilin ransomware.
Судя по описанию Check Point, уязвимость возникла из-за ошибки в логике проверки сертификатов. Под удар попали Mobile Access/SSL VPN, Remote Access VPN, а также Spark Firewalls, если они настроены на устаревший протокол обмена ключами IKEv1. Иными словами, проблема задела не какой-то редкий побочный сценарий, а вполне рабочие конфигурации удалённого доступа, которые в реальных инфраструктурах живут годами и часто не пересматриваются до первого серьёзного инцидента.
Хронология здесь важнее самого CVSS-балла. По словам вице-президента Check Point по исследованиям Лотема Финкельштейна, атаки начались 7 мая, а заметный рост активности пришёлся на начало июня. Подозрительное поведение вендор зафиксировал 4 июня и после этого начал расследование zero-day. 8 июня компания выпустила хотфикс. Формально речь идёт о «нескольких десятках организаций по всему миру», то есть не о массовой автоматизированной кампании по всем подряд. Но для целевых атак на сетевой периметр это как раз типичная картина: сначала тихая разведка и аккуратная эксплуатация, потом ускорение, когда рабочая цепочка уже обкатана.
Отдельно настораживает не только сам факт эксплуатации, но и профиль атакующих. Qilin давно работает не как хаотичная банда из старых мемов про ransomware, а как вполне прагматичная партнёрская модель с доступом через подрядчиков и аффилиатов. Если в цепочке уже замечена такая группа, речь идёт не просто о попытке «проверить, открывается ли дверь», а о вероятной подготовке к шифрованию, краже данных или двойному вымогательству. Для ИТ-директора это означает простую вещь: проверка факта установки патча без ретроспективного поиска следов компрометации здесь недостаточна.
На этом фоне интересно, что параллельно Check Point нашла ещё одну уязвимость, CVE-2026-50752, в Security Gateways и Spark Firewall. Она тоже связана с ошибкой в проверке сертификатов в устаревшем IKEv1, но уже в конфигурации site-to-site VPN и с другим сценарием последствий: потенциальная атака man-in-the-middle. О её эксплуатации «в полях» компания не сообщала. Это не делает вторую дыру второстепенной: обычно такие находки показывают, что проблема не в одном неудачном условии, а в более глубокой архитектурной или кодовой задолженности вокруг старых VPN-механизмов.
Для рынка тут вообще нет приятных новостей. Финкельштейн прямо увязал этих же вымогателей с вероятной эксплуатацией VPN-уязвимостей у других крупных игроков, включая Palo Alto Networks, Fortinet и F5. Получается уже не серия отдельных аварий, а устойчивый тренд: доступ через VPN и пограничные устройства по-прежнему остаётся одним из самых дешёвых и эффективных входов в корпоративную сеть. Пока компании годами откладывают миграцию со старых режимов, отключение устаревших протоколов и ревизию внешнего периметра, атакующие не видят причин менять тактику.
Что это значит для российских ИТ-команд, особенно у тех, кто всё ещё поддерживает гибридный офис, филиалы и подрядчиков на удалёнке? Во-первых, хотфикс нужно ставить не «в ближайшее окно», а сразу, если затронутые компоненты ещё в проде. Во-вторых, придётся проверить логи SmartConsole как минимум за период с 7 мая по 5 июня на предмет попыток VPN-аутентификации, связанных с известной инфраструктурой атакующих и подозрительными subject name сертификатов. В-третьих, если в окружении до сих пор жив IKEv1, особенно на Spark Firewall или в старых site-to-site-связках, это уже не просто технический долг, а понятный операционный риск с конкретной датой начала атак.
Для разработчиков и продуктовых команд история тоже не чужая. Когда компрометируют удалённый доступ, последствия быстро вылезают далеко за пределы сетевой команды: от утечки репозиториев и секретов до остановки CI/CD и инцидентов у клиентов. Поэтому нормальная реакция здесь начинается не с письма «мы обновились», а с короткого кризисного чеклиста: какие сервисные учётки доступны через VPN, где лежат ключи, что видно в EDR, кто и когда логинился нетипично, какие сегменты можно временно изолировать. Сетевой периметр давно перестал быть только зоной ответственности одного администратора.
Пожалуй, главный вывод неприятно банален: уязвимость Check Point VPN стала ещё одним напоминанием, что пограничные системы слишком часто живут по принципу «не трогай, пока работает», а атакующие работают ровно наоборот. Они трогают именно то, что годами считалось достаточно стабильным, чтобы его не пересматривать.