Palo Alto PAN-OS Уязвимость Нулевого Дня CVE-2026-0300: Атаки Государственных Хакеров

Каждый, кого будили в 3 часа ночи из-за самопроизвольной перезагрузки периметрового файрвола, понимает, о чём пойдёт речь. CVE-2026-0300 — это уязвимость удалённого выполнения кода без аутентификации с оценкой CVSS 9.3 в PAN-OS Captive Portal, предоставляющая атакующему права root, и патча для неё не существует. Собственное подразделение Palo Alto — Unit 42 — сообщает, что группировки, поддерживаемые государством, тихо эксплуатируют её с 9 апреля.

Цифры

Начнём с оценки. CVSS 9.3 — это тот показатель, который, по моему опыту в реальных инцидентах, мгновенно вытесняет все остальные задачи из очереди. Как сообщает The Register, уязвимость находится в User-ID Authentication Portal — это ошибка повреждения памяти, которая предоставляет атакующим root-доступ без какой-либо аутентификации. Под угрозой находятся как физические устройства серии PA, так и виртуальные файрволы серии VM. Второй момент особенно важен: многие компании с облачной инфраструктурой ошибочно полагают, что их VM-Series за балансировщиком нагрузки чем-то защищённее железного устройства в стойке. Это не так.

Хронология событий должна насторожить всех руководителей платформ. Первые неудачные попытки эксплуатации — 9 апреля. Успешное RCE на целевом файрволе — примерно через неделю, около 16 апреля. Очистка журналов и отчётов об ошибках — немедленно. Разведка в Active Directory — вскоре после. Принудительное переключение на резервный файрвол через наводнение трафиком аутентификации — 29 апреля. Компрометация резервного устройства и установка дополнительных инструментов удалённого доступа — в тот же период. Публичное раскрытие информации — 7 мая. Добавление в каталог KEV CISA — уже выполнено.

Это примерно четыре недели неприписанного root-доступа к интернет-ориентированной инфраструктуре безопасности — и всё это время у защитников даже не было CVE для поиска. Для команд, эксплуатирующих PAN-OS перед платёжными системами, букмекерскими конторами или торговыми площадками, четыре недели — это не окно. Это эпоха. Она охватывает полное закрытие месяца, два цикла расчёта зарплат и как минимум один запуск продукта. Кластер отслеживается как CL-STA-1132 и описывается как «предположительно спонсируемый государством» — на языке вендоров это означает «мы достаточно уверены, чтобы говорить вслух, но недостаточно, чтобы называть страну».

Технический признак: шеллкод, внедрённый в рабочий процесс nginx на устройстве. Кампанию атрибутирует Unit 42. CISA её кодифицировала. Единственная рекомендация Palo Alto по снижению риска — ограничить доступ к User-ID Authentication Portal до доверенных сетей или полностью отключить его. Патча на момент публикации не существует.

Что действительно нового

Если честно — немногое, и в этом весь смысл. На протяжении последних двух лет файрволы Palo Alto регулярно становятся мишенями атакующих: множество кампаний с использованием уязвимостей нулевого дня поражало интернет-ориентированные устройства PAN-OS до появления патчей. Атакующие уже связывали уязвимости в предыдущих версиях PAN-OS для глубокого проникновения в сети. Так что заголовок «периметровое устройство взломано» — не новость. Новым является оперативная зрелость CL-STA-1132.

Посмотрите на хореографию. Неудачные попытки 9 апреля говорят о том, что атакующие оттачивали свой эксплойт на живых целях, а не в лаборатории. Неделю спустя они получили RCE и немедленно уничтожили журналы и отчёты об ошибках. Это означает, что криминалистический сценарий был готов ещё до того, как был отправлен первый пакет. Затем они начали разведку в Active Directory — стандартный манёвр, — но делали это, продолжая стирать следы с файрвола. Параллельные операции, а не последовательные.

Манёвр 29 апреля — это то, что я бы выделил для любого CTO, который до сих пор думает: «У нас есть HA — мы в безопасности». Атакующие намеренно создали наводнение трафика аутентификации, чтобы вызвать переключение на резервный файрвол, после чего скомпрометировали и его, установив дополнительные инструменты удалённого доступа. Это не оппортунизм. Это оператор, понимающий семантику PAN-OS HA, знающий, что резервное устройство зачастую хуже мониторится, и решивший, что избыточность — это функция для него, а не для вас.

Моё мнение: действительно новый сигнал здесь состоит в том, что высокодоступные пары периметровых устройств теперь представляют собой единый домен отказа с точки зрения атакующего. Если ваш план реагирования на инциденты предполагает, что резервный файрвол — это чистая точка восстановления в ходе активного вторжения, это предположение устарело. Оба узла находятся в зоне риска, и опытный противник может переключить вас на тот, который он хочет скомпрометировать следующим.

Что уже учтено командами безопасности

Для всех, кто эксплуатирует PAN-OS, появление очередного неаутентифицированного RCE в функции портала — это, к сожалению, уже ожидаемое явление. Команды, с которыми я работал у операторов iGaming на Мальте и в финтех-компаниях, работающих с реальными деньгами, последние 18 месяцев отрабатывают мышечную память применительно к экстренным мерам по PAN-OS. Схема реагирования: заблокировать плоскость управления, ограничить портал, проверить исходящие соединения с самого файрвола, искать аномалии nginx. Ничего принципиально нового.

Что не должно быть учтено, но, вероятно, уже стало таковым — это отсутствие патча в день публичного раскрытия. Добавление в KEV CISA без исправления от вендора ставит CISO в неудобное положение. У федеральных ведомств есть обязательные сроки для устранения записей KEV, но единственная доступная сейчас мера — отключить функцию в производственной среде. Это реальные операционные издержки. Если через captive portal аутентифицируются подрядчики, пользователи гостевого Wi-Fi или BYOD-устройства, «полностью отключить его» означает шквал обращений в службу поддержки с понедельника.

Меня удивила деталь о разведке в AD. Если сопоставить действия атакующих с MITRE ATT&CK, получаем: Initial Access через Exploit Public-Facing Application, Defense Evasion через Indicator Removal и Discovery против Active Directory — и всё это с плацдарма на самом файрволе. Большинство SOC настраивают обнаружение аномалий AD с предположением, что источник — это конечная точка или сервер. Они не ищут LDAP-запросы, исходящие с периметрового устройства. Именно эта слепая зона делает компрометацию файрволов столь ценной для государственных группировок.

Альтернативная точка зрения

Консенсусная реакция будет такой: «PAN-OS сломан — нужно всё снести и заменить». Я считаю это ошибочным, дорогостоящим и не решающим саму проблему. За последние два года каждый крупный вендор файрволов выпускал уязвимости с неаутентифицированным RCE в функциях управления или смежных с аутентификацией. Смена логотипа вендора даёт вам другой поток CVE, но не другую модель угроз.

Неудобная истина: настоящий провал здесь — не качество кода Palo Alto, а устоявшаяся в отрасли привычка выставлять насыщенные порталы аутентификации на интернет-ориентированных устройствах безопасности. Captive-порталы, страницы входа SSL VPN, интерфейсы управления, которые «должны» быть закрыты, но никогда до конца не закрываются. Каждый из них — это парсер, написанный на C-подобном коде, находящийся на незащищённой стороне сети и обрабатывающий ненадёжный ввод. Поверхность атаки — это архитектура, а не вендор.

Если вы хотите одобрить миграцию с PAN-OS в этом квартале, сначала задайте более сложный вопрос: почему вообще какой-либо портал аутентификации доступен из публичного интернета? Identity-aware прокси в стиле Cloudflare, ZTNA-шлюзы и сегментированные плоскости администрирования существуют именно для того, чтобы создать слой между открытым интернетом и этими уязвимыми парсерами. Это и есть структурное решение.

Ключевые выводы

• Принимайте меры сегодня, не ждите патча: ограничьте User-ID Authentication Portal до доверенных сетей или отключите его. CVE-2026-0300 активно эксплуатируется и включена в каталог CISA KEV.
• Оба узла HA являются скомпрометированной территорией: CL-STA-1132 принудительно вызвала переключение через наводнение трафика аутентификации и скомпрометировала резервный файрвол тоже. При реагировании на инциденты рассматривайте пару HA как единую границу доверия.
• Ищите рабочий процесс nginx: задокументированный TTP — внедрение шеллкода в nginx на устройстве. Если у вас есть телеметрия с плоскости файрвола, ищите аномальные дочерние процессы, исходящие соединения и отсутствующие отчёты об ошибках.
• Отслеживайте AD-запросы с позиций сети файрвола: атакующие зондировали Active Directory после получения плацдарма. Настройте обнаружение так, чтобы трафик LDAP и Kerberos с периметровых устройств не получал автоматического пропуска.
• В день раскрытия уязвимости предполагайте четыре недели присутствия атакующих: первые попытки эксплуатации начались 9 апреля. Если ваше устройство PAN-OS доступно из интернета, область IR охватывает период «с начала апреля», а не «с 7 мая».