Уязвимость GlobalProtect из линейки Palo Alto Networks вышла из разряда «почините при случае» в режим срочного инцидента. Баг CVE-2026-0257, который в начале месяца оценивали как умеренный, уже используют в реальных атаках, а значит для компаний с PAN-OS это не абстрактный риск из бюллетеня, а вполне практичная попытка зайти во внутреннюю сеть через VPN.
Об этом сообщает BleepingComputer со ссылкой на обновлённое предупреждение Palo Alto Networks. Речь идёт об обходе аутентификации в GlobalProtect portal и gateway: при определённой конфигурации злоумышленник может установить несанкционированное VPN-подключение к устройству. Изначально вендор считал проблему менее опасной, потому что она срабатывает не «из коробки», а только если на устройстве включены authentication override cookies и использована конкретная схема сертификатов. Но 30 мая 2026 года Palo Alto изменила оценку на High после сообщений об активной эксплуатации против непропатченных систем.
Технически история неприятная именно тем, что ломается не пароль и не MFA в лоб, а логика доверия внутри самого механизма аутентификации. По данным Rapid7, атаки начались не позднее 17 мая 2026 года. Исследователи зафиксировали успешную эксплуатацию у нескольких клиентов MDR, хотя признаков дальнейшего бокового перемещения из VPN-устройств они не увидели. Первая активность, которую Rapid7 связала с эксплуатацией, пришла 18 мая с инфраструктуры Vultr, вторая волна была замечена 21 мая и шла уже через Dromatics Systems. Сам сценарий выглядел так: атакующие подделывали authentication override cookie, ориентируясь на локальную учётную запись администратора, и пытались пройти в GlobalProtect gateway без знания реальных учётных данных.
Ключевая деталь в том, почему уязвимость GlobalProtect вообще стала рабочей, связана с проверкой этих cookies в PAN-OS. Устройство расшифровывает cookie приватным ключом и затем доверяет расшифрованному содержимому, не выполняя проверку подписи. Если один и тот же сертификат используется и для HTTPS-сервисов, и для authentication override cookies, злоумышленник может получить открытый ключ через HTTPS-сессию и на его основе собрать поддельный cookie, который система примет как легитимный. Rapid7 даже собрала proof-of-concept, показывающий, что можно вытащить публичные сертификаты, сгенерировать forged cookie для произвольного пользователя и пройти аутентификацию на непропатченном шлюзе. Для администраторов это важный момент: проблема не в какой-то экзотической криптоатаке, а в комбинации небезопасной логики проверки и неудачной конфигурации, которая вполне могла считаться допустимой.
Есть и ещё один штрих, который должен немного отрезвить тех, кто любит сортировать уязвимости по CVSS и откладывать средние на потом. Да, изначально баг выглядел условным: нужен включённый override, нужна конкретная настройка сертификатов, нужна цель, у которой всё это совпало. Но реальный мир как раз и устроен так, что в крупных инфраструктурах подобные компромиссные настройки живут годами, потому что когда-то так было удобнее мигрировать пользователей, проще стыковать старые системы или быстрее запускать удалённый доступ. В результате «medium при особых условиях» превращается в прямой входной канал в корпоративную сеть. Для российских компаний это особенно актуально в сегментах, где Palo Alto стоит на периметре у распределённых команд, подрядчиков и филиалов: VPN-шлюз остаётся одной из самых ценных точек для атакующего, потому что даёт доступ не к одной машине, а к маршруту внутрь.
Отдельно показательна реакция регуляторов. По состоянию на 29 мая 2026 года CVE-2026-0257 уже внесли в каталог CISA Known Exploited Vulnerabilities. Для федеральных агентств США дедлайн на устранение установлен на 1 июня 2026 года. Обычно это хороший индикатор реального приоритета: если уязвимость попадает в KEV, обсуждение уровня «насколько она теоретически опасна» заканчивается, и начинается разговор о том, сколько непропатченных устройств ещё торчит в интернете. Вендор рекомендует немедленно установить обновления безопасности. Если патчирование прямо сейчас невозможно, в качестве временного снижения риска Palo Alto советует отключить authentication override либо использовать для этой функции отдельный сертификат, не разделяемый с другими сервисами на устройстве.
Для ИБ-команд и инфраструктурных администраторов здесь довольно прямой список выводов. Во-первых, проверить нужно не только версию PAN-OS, но и конкретную конфигурацию GlobalProtect: включён ли authentication override, каким сертификатом он подписан и не используется ли этот же сертификат для HTTPS. Во-вторых, факт отсутствия lateral movement у части пострадавших не должен успокаивать: если атакующий уже может поднять VPN-сессию, дальше всё зависит не от уязвимости, а от сегментации сети, контроля доступа и обнаружения аномалий внутри периметра. В-третьих, этот кейс снова показывает, что VPN и прочие edge-устройства остаются короткой дорогой в корпоративную инфраструктуру. В последние годы рынок регулярно получает похожие сюжеты от разных вендоров: сначала уязвимость выглядит «нишевой», потом находится рабочая эксплуатация, а затем выясняется, что именно такие пограничные системы патчатся медленнее всего, потому что их боятся трогать без окна обслуживания.
Уязвимость GlobalProtect вряд ли станет последней историей, где решающим фактором окажется не сама ошибка в коде, а старая добрая смесь из спорной конфигурации, переиспользованных сертификатов и привычки откладывать обновления периметра. Для бизнеса вопрос уже не в том, опасен ли этот баг, а в том, сколько ещё инфраструктурных компромиссов сейчас выглядят «приемлемо», пока кто-то не превратит их в рабочую цепочку атаки.