Две критические уязвимости Check Point VPN получили предупреждение с редкой формулировкой: эксплуатация ожидается в ближайшее время. Для русскоязычных IT-команд это не абстрактный бюллетень безопасности, а повод проверить шлюзы удаленного доступа до того, как проверять их начнут другие.
Нидерландский Национальный центр кибербезопасности, NCSC, предупредил о высоком риске атак на CVE-2026-85102 и CVE-2026-85103, сообщает BleepingComputer. Публичного proof-of-concept на момент публикации не было, но агентство оценивает и вероятность эксплуатации, и возможный ущерб как высокие. В переводе с языка госструктур на язык админов: ждать удобного окна на следующей неделе может быть плохой идеей.
Обе проблемы затрагивают Check Point VPN и связаны с обработкой сертификатов при VPN-подключениях. CVE-2026-85102 описана как некорректная проверка данных сертификата во время VPN-negotiation. Удаленный атакующий потенциально может использовать ее для выполнения произвольного кода на Security Gateway. CVE-2026-85103 выглядит не мягче: это heap overflow в ASN.1-декодере VPN-сертификатов, который может привести к удаленному выполнению кода на Security Gateways и Security Management Servers.
Список затронутых версий широкий. В него входят R81.20, R82, R82.10, R81.10.x и R82.00.x, а также уже снятые с поддержки ветки R80, R80.10, R80.20, R80.30, R80.40, R81 и R81.10. Версия R82.20, по данным Check Point, не подвержена этим двум уязвимостям. Это важная деталь для команд, которые уже успели обновиться, но плохая новость для тех, у кого VPN-шлюзы живут в режиме «работает — не трогай».
Check Point выпустила исправления 9 сентября. Для R81.20, R82 и R82.10 обе уязвимости закрываются через Check Point LivePatch Take 24. Исправления также включены в R82.10 Jumbo Hotfix Accumulator Take 44 или новее, R82 Jumbo Hotfix Accumulator Take 126 или новее, R81.20 Jumbo Hotfix Accumulator Take 166 или новее, Spark R82.00.10 Build 2325 или новее и Spark R81.10.17 Build 4968 или новее. Набор выглядит скучно, пока не вспоминаешь, что именно такие списки обычно отделяют плановое обновление от ночного инцидента.
LivePatch в этой истории полезен, но не магический. В обсуждении Check Point Community говорится, что пользователи Check Point Live Patch должны были получить доступные защиты с 9 сентября, причем без перезагрузки сервера. Но автоматическая защита доступна не для всех версий и не для всех конфигураций: она относится к R82.10, R82 и R81.20. Поэтому простая проверка «у нас же включен live patching» не заменяет инвентаризацию версий, статуса патча и применимости конкретной защиты.
NCSC отдельно предупреждает о последствиях возможной эксплуатации: атакующий может получить полный контроль над системой, просматривать или менять конфиденциальные данные и нарушать работу сервисов. Для бизнеса это означает не только риск компрометации VPN-шлюза, но и удобную точку входа во внутреннюю сеть. VPN давно перестал быть скучной инфраструктурной железкой на краю периметра; для атакующих это дверь, за которой часто лежат доменные сервисы, панели управления, репозитории, CI/CD и другие вещи, которые лучше не показывать незнакомцам.
Практический минимум для администраторов сейчас довольно прямой: определить версии Check Point на Security Gateway и Security Management Server, сопоставить их с бюллетенями sk1000117 и sk1000118, установить соответствующий LivePatch или Jumbo Hotfix, а затем проверить, что защита действительно активна. Для тех, кто использует компонент Site-to-Site VPN, NCSC рекомендует ограничить VPN-правила конкретными доверенными IP-адресами. Это не замена патчу, но хороший способ уменьшить поверхность атаки, особенно если обновление требует согласований или тестирования.
История с уязвимостями Check Point VPN хорошо ложится в нынешний тренд: атакующие все чаще бьют не по пользовательским ноутбукам, а по инфраструктуре удаленного доступа, пограничным шлюзам и управленческим интерфейсам. Там меньше пользовательского шума, выше привилегии и больше шансов быстро перейти от одной системы к другой. Если прогноз NCSC сбудется, главным вопросом будет не наличие публичного PoC, а скорость реакции команд: кто успел закрыть периметр до первых массовых попыток, а кто снова будет читать логи уже после факта.