Статья CVE-2026-0257 Palo Alto GlobalProtect: bypass VPN-аутентификации и эскалация severity за 16 дней

Когда 13 мая Palo Alto Networks опубликовала advisory по CVE-2026-0257, у нас баг попал в бэклог с пометкой "при случае проверить". Невысокий начальный приоритет, нестандартная конфигурация authentication override cookies, ограниченная поверхность - ну, знаете, типичный "потом посмотрим". К 29 мая был опубликован технический анализ с PoC, CISA добавила CVE в каталог KEV, а Palo Alto присвоила CVSS 7.8 с пометкой urgency: Red. За 16 дней баг, на который махнули рукой, превратился в активную угрозу с EPSS 0.87 - Top 0.3% вероятности эксплуатации среди всех зарегистрированных уязвимостей.

Разбираю механику cookie forgery, exploit chain от публичного ключа до VPN-сессии и на что смотреть при detection.

Бизнес-логика атаки: зачем bypass аутентификации GlobalProtect нужен злоумышленнику​

GlobalProtect - VPN-решение Palo Alto Networks, встроенное в PAN-OS. На периметре enterprise-сетей это точка входа для удалённых сотрудников, а для атакующего - initial access без единого пароля. Без MFA. Без credential stuffing. Без фишинга. Подробнее - в нашем подробном разборе cve эксплойт разработка.

По данным CrowdStrike Global Threat Report 2025, значительная доля вторжений использует действительные учётные данные. С точки зрения SIEM - это валидный логин с валидным cookie. По данным Verizon DBIR 2025, значительная часть утечек связана с кражей credentials. Здесь красть нечего, потому что credentials не нужны.

В терминах MITRE ATT&CK цепочка выглядит так: Exploit Public-Facing Application (T1190, Initial Access) - подделка cookie даёт initial access через периметровое устройство. Через VPN-туннель атакующий получает Valid Accounts (T1078, Defense Evasion / Persistence / Privilege Escalation / Initial Access) и External Remote Services (T1133, Initial Access / Persistence) - легитимный сетевой доступ ко внутренней инфраструктуре. После установки VPN-туннеля дальнейшие действия - стандартный post-exploitation: lateral movement, credential abuse. Но это уже за рамками самой CVE-2026-0257.

Анатомия Palo Alto Networks уязвимости: CWE-565 и отсутствие верификации cookie​

Как работают authentication override cookies в PAN-OS​

В GlobalProtect есть функция "authentication override" - портал или шлюз выдаёт аутентифицированному пользователю зашифрованный cookie, чтобы при следующем подключении не вводить пароль заново. По сути - bearer token: предъяви cookie, получи доступ.

Согласно имеющимся публикациям, cookie содержит имя пользователя, домен, host ID, версию клиентской ОС, удалённый адрес и timestamp (cookie имеет конечное время жизни). Всё шифруется публичным ключом сертификата, назначенного для auth override; расшифровка выполняется приватным ключом на стороне шлюза.

Обработка реализована в сервисе GlobalProtect. Ниже - условные имена функций, иллюстрирующие логику (точная структура бинарника и имена символов зависят от версии PAN-OS):

• Обработка логина - при POST-запросе на /ssl-vpn/login.esp проверяется наличие HTTP-параметра portal-userauthcookie или portal-prelogonuserauthcookie. Если параметр есть - управление уходит в логику cookie-аутентификации.
• Cookie-аутентификация - принимает зашифрованный cookie, расшифровывает, затем использует извлечённые данные (username, domain, timestamp) для авторизации.
• Расшифровка cookie - декодирует cookie из base64, расшифровывает приватным ключом. После расшифровки содержимое доверяется имплицитно: никакой проверки подписи, HMAC или integrity check не выполняется.

Вот тут и зарыта собака. CWE-565 - Reliance on Cookies without Validation and Integrity Checking. Система полагается на то, что если cookie удалось расшифровать - значит, он легитимный. Классический CAPEC-114 (Authentication Abuse).

Повторное использование сертификата - корень VPN bypass​

Проблема становится эксплуатируемой при конкретном условии: сертификат для шифрования auth override cookies совпадает с сертификатом HTTPS-сервиса портала или шлюза GlobalProtect.

Почему это критично: публичный ключ HTTPS-сертификата доступен любому, кто подключается к порталу. Атакующий вытягивает его стандартным openssl s_client -connect target:443, получает публичный ключ и шифрует им поддельный cookie с произвольным username - включая admin. Сервер расшифровывает cookie приватным ключом, видит валидные поля, не проверяет целостность - и авторизует сессию.

Когда техника работает:

• GlobalProtect portal или gateway включён
• Authentication override cookies включены (НЕ дефолтная настройка)
• Сертификат для auth override совпадает с HTTPS-сертификатом портала/шлюза
• Cloud Authentication Service (CAS) отключён

Когда техника НЕ работает:

• Auth override cookies отключены (дефолт)
• Выделенный сертификат для auth override (не совпадает с HTTPS-сервисом)
• CAS включён (для этого сценария есть отдельная CVE-2026-0265, CWE-347, другой вектор)
• Cloud NGFW и Panorama не затронуты
• Пропатченные версии PAN-OS

[Применимо: внешний пентест, GlobalProtect portal/gateway доступен из интернета, PAN-OS 10.2.x-12.1.x до исправлений]

Эскалация CVSS: почему критическая уязвимость VPN 2026 сначала получила medium​

Разбор CVSS-вектора CVE-2026-0257 - отдельный урок того, как метрика может дезориентировать команды безопасности.

Текущий вектор (CVSSv4): AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:N/E:A/AU:N/R:A/V:D/RE:M/U:Red

Что означают ключевые компоненты:

• AV:N, AC:L, PR:N, UI:N - сетевая атака, низкая сложность, без привилегий, без действий пользователя. Идеальный вектор для массовой эксплуатации.
• VC:L - низкий импакт на конфиденциальность уязвимой системы (самого файрвола). Именно этот компонент занижал оценку.
• SC:H, SI:H - высокий импакт на конфиденциальность и целостность последующих систем. Через VPN-туннель атакующий попадает во внутреннюю сеть - а это уже совершенно другой масштаб.

Предположительно, первоначальный CVSS-BT был ниже итогового 7.8, так как рассчитывался без подтверждения активной эксплуатации (E: не Active). Конкретное начальное значение не подтверждено официальным источником. Palo Alto Networks в FAQ объяснила так: "Общая severity привязана к Threat Score, который динамически корректируется на основе threat intelligence. Score растёт, когда публикуются PoC или наблюдаются активные атаки".

29 мая произошло сразу несколько вещей: опубликован PoC, подтверждена активная эксплуатация с 17 мая, CISA добавила CVE в KEV с дедлайном 1 июня - три дня на устранение для федеральных агентств. CVSS-BT достиг 7.8, E сменился на A (Active), U (Urgency) стал Red. В публичных рекомендациях прямо указывалось "treat this as a critical vulnerability""Рассматривайте это как критическую уязвимость" - формально high, фактически критика в каждом отчёте.

EPSS на момент написания - 0.8668, percentile 99.71%. CVE-2026-0257 имеет более высокую вероятность эксплуатации, чем 99.71% всех CVE в базе FIRST.org. CISA SSVC decision - Act (патчить немедленно), Technical Impact - total.

Хронология повышения критичности уязвимости:

Дата	Событие
13 мая 2026	Advisory опубликован, предположительно с более низким начальным CVSS-BT
17 мая 2026	Первая волна эксплуатации
21 мая 2026	Вторая волна эксплуатации, другой хостинг-провайдер
29 мая 2026	Публикация PoC, CISA KEV, CVSS-BT 7.8 (high)
1 июня 2026	Дедлайн CISA для федеральных агентств

Recon: fingerprinting уязвимых GlobalProtect-инстансов​

Требования к окружению:

• ОС: Kali Linux 2024.x или любая GNU/Linux-система с Python 3.9+
• Инструменты: openssl (1.1+), curl, nmap
• Сеть: HTTPS-доступ (443/tcp) к целевому GlobalProtect portal/gateway
• Лабораторная среда: EVE-NG с образом PAN-OS 10.2.8 для безопасного тестирования (RAM: 8 ГБ минимум для VM с PAN-OS, 16 ГБ рекомендуется)

Первый шаг - убедиться, что перед вами GlobalProtect, а не другой VPN. Обычно достаточно GET-запроса на корень HTTPS-сервиса: в ответе будут характерные заголовки и редирект на /global-protect/login.esp или /ssl-vpn/login.esp.

Проверить конфигурацию auth override cookies снаружи напрямую нельзя - это внутренняя настройка. Зато можно проверить сертификат: если один и тот же сертификат используется для HTTPS-сервиса и для auth override, это видно по серийному номеру в TLS-handshake.

openssl s_client -connect target.example.com:443 -showcerts \
  </dev/null 2>/dev/null | openssl x509 -noout -serial -subject

Серийный номер и subject сертификата - первый маркер. Если GlobalProtect использует дефолтный самоподписанный сертификат или сертификат с generic subject - вероятность совпадения с auth override cert выше.

Для автоматизации есть Nuclei-шаблон CVE-2026-0257.yaml (путь: javascript/cves/2026/CVE-2026-0257.yaml в репозитории projectdiscovery/nuclei-templates). Запуск: nuclei -t CVE-2026-0257.yaml -u https://target.example.com. Шаблон проверяет наличие уязвимой конфигурации через специфический запрос к endpoint'у аутентификации.

На GitHub есть публичный PoC-репозиторий (akashsingh0454/CVE-2026-0257-PoC(GitHub - akashsingh0454/CVE-2026-0257-PoC), 2 звезды, обновлён 3 июня 2026). Две звезды и отсутствие аудита - перед использованием код стоит вычитать руками.

Palo Alto GlobalProtect exploit: от публичного ключа до VPN-сессии​

Контекст применения: внешний пентест, GlobalProtect portal/gateway доступен из интернета, auth override включён, сертификат переиспользован.

Exploit chain CVE-2026-0257 состоит из четырёх шагов:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

По имеющимся наблюдениям, в реальных атаках cookie формировался с MAC-адресом aa:bb:cc:dd:ee:ff, hostname GP-CLIENT или DESKTOP-GP01 и endpoint_os_version Microsoft Windows 10 Pro 64-bit. Auth latency при cookie-аутентификации, по неподтверждённым данным, варьировалась в широком диапазоне в зависимости от конфигурации auth profile.

Характерный лог успешной эксплуатации:

GLOBALPROTECT,gateway-auth,login,Cookie,,admin,US,GP-CLIENT,
104.207.144[.]154,...,"Auth latency: <low_value>ms, profile: local_auth_profile",success

Ограничения в современных средах: по имеющимся данным, из 10 затронутых MDR-клиентов в 8 случаях cookie был принят, но полноценная VPN-сессия не установилась - файрвол аутентифицировал запрос, но не завершил tunnel negotiation. Полный VPN-туннель с IP-назначением зафиксирован в 2 из 10 случаев. Bypass аутентификации срабатывает чаще, чем полный exploit chain до внутренней сети. Это важно: 80% успешных auth bypass - тупик без туннеля. Но оставшиеся 20% - полноценный initial access.

Post-exploitation и место CVE-2026-0257 в kill chain​

Если VPN-туннель установлен (по имеющимся наблюдениям - 2 из 10 случаев) - атакующий находится во внутренней сети с правами того пользователя, чей username был подставлен в cookie. При использовании admin - это может означать доступ к management-сегменту.

Позиция в kill chain: initial access (T1190) через cookie forgery -> foothold через VPN-туннель (T1133, External Remote Services) -> lateral movement (T1550.004, Web Session Cookie).

По имеющимся данным, на момент публикации threat brief'а "no post-access behavior or lateral movement has been identified""Никаких поведенческих изменений или перемещений по инфрастурктуре не выявлено." - атакующие проводили массовое зондирование, но не углублялись. Аналогичная картина подтверждалась другими наблюдениями: "did not observe any indication of successful lateral movement from the devices""не было обнаружено никаких признаков успешного перемещения по инфраструктуре"ISPOILER].

В отдельных инцидентах после успешного auth bypass фиксировалась post-exploitation активность, включая получение конфигурации устройства и попытки lateral movement. Kill chain от auth bypass до компрометации внутренней сети технически реализуем, просто основная масса атакующих пока остаётся на стадии recon и access validation. Ждут своего часа - или продают доступ.

Для внутреннего пентеста после установки VPN-сессии стандартный следующий шаг - nmap -sn по назначенному VPN-пулу, enumeration AD через LDAP, SMB-share enumeration. Если VPN выдал IP в management VLAN - прямой путь к domain admin через стандартные AD-атаки (Kerberoasting, AS-REP Roasting, NTLM relay).

Detection: IoC и охота за следами обхода аутентификации GlobalProtect​

Для hunt'а по pre-PoC активности (до 29 мая 2026) ищите в GlobalProtect-логах подозрительные подключения. Ниже - примеры IoC-паттернов, требующие верификации в актуальном threat intelligence (источник не подтверждён независимо):

• 23.128.228[.]6
• 104.207.144[.]154
• 146.19.216[.]119, 146.19.216[.]120, 146.19.216[.]125
• 179.43.172[.]213
• 185.195.232[.]139
• 198.12.106[.]60
• 202.144.192[.]47

Подозрительные MAC-адреса и hostname'ы в логах gateway-connected событий (placeholder-значения, характерные для автоматизированных инструментов; в реальных атаках злоумышленник может рандомизировать MAC под правдоподобные OUI):

• MAC: aa:bb:cc:dd:ee:ff, 00:11:22:33:44:55
• Hostnames: WINDOWS-LAPTOP-001, DESKTOP-GP01, GP-CLIENT

Для post-PoC мониторинга - дополнительные маркеры, зашитые в публичный PoC:

• endpoint_os_version: Microsoft Windows 10 Pro 64-bit
• source_user_info.domain: пустое значение

На что смотреть в логах:

1. Cookie auth с admin-аккаунтом. Cookie-аутентификация для admin нетипична. Если в логе gateway-auth,login,Cookie,,admin - это красный флаг. Не оранжевый, не жёлтый - красный.
2. Auth latency аномалии. Forged cookies, предположительно, обрабатываются быстрее (по неподтверждённым наблюдениям), потому что не проходят полную цепочку аутентификации.
3. Подключения с hosting-провайдеров. Vultr, Dromatics Systems и подобные. Ваши сотрудники не ходят в VPN с Vultr. Если видите такое - проверяйте.
4. Одинаковый MAC-адрес. В обеих волнах эксплуатации, предположительно, фиксировался один и тот же placeholder MAC - может указывать на один инструмент или одного threat actor'а.

Для Cortex XDR / XSIAM - предположительно имеется покрытие через Behavioral Threat Protection [источник требует проверки]. Для PAN-OS Advanced URL Filtering - известные IP-адреса атакующих уже маркированы как malicious.

Palo Alto patch GlobalProtect: чеклист remediation​

1. Обновить PAN-OS до исправленной версии. Актуальный список фиксированных версий по веткам 10.2, 11.1, 11.2, 12.1 и Prisma Access - в официальном advisory на security.paloaltonetworks.com [конкретные hotfix-номера требуют проверки по vendor advisory].
2. Выделить отдельный сертификат для auth override cookies. Сгенерировать новый, не использовать его ни для HTTPS-сервиса, ни для других функций PAN-OS.
3. Если auth override не критичен - отключить. Снять флажки "Generate cookie for authentication override" и "Accept cookie for authentication override" в настройках портала и шлюза.
4. Включить HMAC-валидацию после обновления всех компонентов. Включить HMAC-валидацию auth override cookies согласно официальной документации (см. security advisory по CVE-2026-0257). Все порталы и шлюзы в среде должны быть обновлены до фиксированной версии перед включением HMAC - иначе несовместимость cookie между обновлёнными и необновлёнными компонентами.
5. Ограничить exposure GlobalProtect. Ограничить доступ к порталу/шлюзу доверенными IP-диапазонами через security policies, где это возможно.
6. Включить MFA для административных аккаунтов. Отключить или переименовать дефолтный аккаунт admin.
7. Провести hunt по логам. Проверить GlobalProtect-логи за период с 17 мая 2026 по IoC из раздела Detection. При обнаружении - запустить IR.
8. Учитывать phased upgrade. При поэтапном обновлении временно отключить HMAC на обновлённых устройствах согласно официальной документации. Включить обратно после обновления всех компонентов.

Формулу decay критичности этой CVE на бумаге понять несложно - CVSS-BT меняется при подтверждении эксплуатации. Но по-настоящему это ощущается, когда прогоняешь exploit chain самостоятельно и видишь, как cookie без HMAC проходит аутентификацию за доли секунды. Готовые стенды с VPN-инфраструктурой, где такие примитивы можно отработать безопасно, есть на HackerLab.pro (https://hackerlab.pro) - категории web и network покрывают именно эту механику на задачах разного уровня сложности.

Вся история с CVE-2026-0257 для меня - наглядный пример того, почему CVSS Base Score не должен быть единственным инструментом приоритизации. 16 дней организации могли недооценивать уязвимость из-за предположительно невысокого начального score, пока атакующие уже прощупывали периметры. Реальный risk rating определяется не абстрактным вектором, а ответом на два вопроса: можно ли это эксплуатировать удалённо и что за этим стоит. Для CVE-2026-0257 оба ответа были очевидны с первого дня - AV:N, PR:N, SC:H, SI:H. Файрвол на периметре с network-level bypass и high subsequent impact - это не medium ни при каких обстоятельствах.

CVSS v4.0 попытался решить проблему через Threat Score (компонент E), но это по определению запаздывающий индикатор - score растёт после того, как PoC опубликован и эксплуатация зафиксирована. Мне ближе подход CISA SSVC, где decision "Act" не зависит от наличия публичного PoC, а основан на Technical Impact + Automatable + Exploitation status.

Для edge-устройств - VPN-шлюзов, NGFW, SSL-порталов - я рекомендую вообще не ждать CVSS-BT escalation. Auth bypass на периметровом устройстве, PR:N, сетевой доступ - патчите в течение 48 часов, независимо от базового score. Время, потраченное на дебаты "medium или high", - это время, которое атакующий использует для установки VPN-сессии. На HackerLab лежит сценарий, где этот primitive нужно собрать в полную цепочку.