Palo Alto PAN-OS Zero-Day CVE-2026-0300 Атакований Державними Хакерами

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

Цифри

Почнемо з оцінки. CVSS 9.3 — це той тип числа, який, за моїм досвідом у виробничих інцидентах, миттєво відсуває на другий план усі інші заявки. Як The Register повідомляв, вразливість знаходиться в User-ID Authentication Portal — помилка пошкодження пам'яті, яка надає зловмисникам права root без будь-якого входу в систему. У зоні ризику знаходяться як фізичні апарати PA-Series, так і віртуальні фаєрволи VM-Series. Другий момент є важливим, оскільки багато хмарних компаній вважають, що їхній VM-Series за балансувальником навантаження якимось чином захищений краще, ніж фізичний пристрій у стійці. Це не так.

Хронологія — це та частина, яка має змусити керівників платформ відчути дискомфорт. Перші невдалі спроби експлуатації: 9 квітня. Успішне RCE на цільовому фаєрволі: приблизно тиждень потому, тобто близько 16 квітня. Очищення журналів та звітів про збої: негайно. Зондування Active Directory: невдовзі після цього. Примусовий перехід на резервний фаєрвол через флуд автентифікаційного трафіку: 29 квітня. Компрометація цього резервного пристрою та встановлення додаткових засобів віддаленого доступу: той самий часовий проміжок. Публічне розкриття: 7 травня. Внесення до каталогу KEV від CISA: вже зроблено.

Це приблизно чотири тижні непоміченого root-доступу до інтернет-орієнтованої інфраструктури безпеки, перш ніж у захисників взагалі з'явився CVE для пошуку. Для команд, які використовують PAN-OS перед платіжними системами, букмекерами або торговими майданчиками, чотири тижні — це не вікно. Це ціла епоха. Вона охоплює повне місячне закриття, два цикли нарахування зарплати та щонайменше один запуск продукту. Угруповання відстежується як CL-STA-1132 та описується як «імовірно держспонсороване» — це мова вендора на позначення «ми достатньо впевнені, щоб сказати це вголос, але недостатньо, щоб назвати країну».

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

Що насправді нового

Чесно кажучи, небагато — і в цьому і полягає суть. Фаєрволи Palo Alto протягом останніх двох років є постійною ціллю для зловмисників: кілька zero-day кампаній вражали інтернет-орієнтовані пристрої 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 — це спосіб автентифікації підрядників, гостьового WiFi або 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 portals, посадкові сторінки SSL VPN, інтерфейси управління, які «мали б» бути заблоковані, але ніколи повністю не закриті. Кожен із них — це парсер, написаний C-подібним кодом, що знаходиться на брудній стороні мережі й обробляє недовірені дані. Поверхня атаки — це архітектура, а не вендор.

Якщо ви спокушаєтесь схвалити міграцію з PAN-OS у цьому кварталі, спочатку поставте собі більш складне питання: чому взагалі будь-який портал автентифікації доступний з публічного інтернету? Проксі-сервери з урахуванням ідентифікації на кшталт Cloudflare, шлюзи ZTNA та сегментовані адміністративні площини існують саме для того, щоб розмістити шар між відкритим інтернетом і цими ненадійними парсерами. Це і є структурне виправлення.

Ключові висновки

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