Критична вразливість переповнення буфера CVE-2026-97631 у PXE-драйвері EDK II — відкритого коду, на якому побудована прошивка UEFI більшості серверних і клієнтських платформ — дає змогу неавтентифікованому зловмиснику виконати довільний код до завантаження операційної системи і до спрацювання Secure Boot. Вразливість зачіпає системи, що використовують мережеве завантаження PXE, і оцінена в 9.5 бала за CVSS v4 (Critical). Виправлення внесено до початкового коду EDK II, однак жоден стабільний реліз його поки не містить, і операторам серверної інфраструктури з PXE-завантаженням рекомендується вимкнути мережеве завантаження до виходу оновлень прошивки.
Технічні деталі вразливості
Вразливість класифікована як запис за межами виділеного буфера (CWE-787, out-of-bounds write) у компоненті NetworkPkg/UefiPxeBcDxe — PXE-драйвері EDK II. PXE (Preboot Execution Environment) — механізм завантаження машини по мережі, який широко застосовується в дата-центрах для розгортання та відновлення серверів.
Під час PXE-завантаження драйвер обробляє вхідні ICMP-повідомлення про помилки, копіюючи їхній вміст у фіксовану ділянку пам’яті розміром 504 байти. Перевірки меж під час цієї операції копіювання реалізовані некоректно як для IPv4, так і для IPv6. Надсилання спеціально сформованого ICMP-пакета, що перевищує 504 байти, призводить до перезапису суміжних ділянок пам’яті даними, які контролює зловмисник.
Для експлуатації не потрібні ні пароль, ні попередній доступ до системи — достатньо можливості надіслати мережевий пакет на адресу машини в момент PXE-завантаження. При цьому, згідно з даними CVE-запису, Red Hat і SUSE класифікують вектор атаки як доступний із суміжного мережевого сегмента, а не з відкритого інтернету.
Гарантований результат експлуатації — відмова завантаження (denial of service). Виконання довільного коду значно складніше: воно вимагає знання конкретної збірки прошивки цільової системи та створення експлойта, адаптованого під неї. Універсальний експлойт для масової атаки малоймовірний саме через цю залежність від конфігурації.
Варто відзначити розбіжність в оцінках серйозності у різних джерел: TianoCore присвоює 9.5 за CVSS v4, тоді як SUSE оцінює вразливість у 8.8 за CVSS v3 (Important). Це не суперечність — відмінність зумовлена різними версіями методології CVSS; SUSE також відображає оцінку CNA 9.5 за CVSS v4.
Масштаб уражених систем
Уразливий код присутній в EDK II починаючи з коміту листопада 2010 року — тобто існує близько 16 років. Уражені всі версії EDK II аж до edk2-stable202608 (від 21 серпня 2026 року).
EDK II — референсна кодова база, яку використовують найбільші постачальники UEFI-прошивок (AMI, Insyde, Phoenix), а також Microsoft у проєкті Project Mu. Однак широке використання EDK II в екосистемі не означає, що всі сервери уразливі. Практична вразливість визначається перетином трьох умов:
- PXE-драйвер EDK II присутній у прошивці системи;
- система активно виконує завантаження по мережі в момент атаки;
- зловмисник може доставити ICMP-трафік на адресу машини в цей момент.
Домашні та офісні комп’ютери, що завантажуються з локального диска, не зачеплені. Основна група ризику — сервери та обладнання дата-центрів, які використовують PXE для розгортання.
Серед дистрибутивів Linux: Red Hat відзначає пакети edk2 в RHEL 8, 9 і 10 як уражені та не виправлені; Debian фіксує вразливість у пакетах bookworm, trixie, forky та sid. Раніше ми вже писали про вразливості в екосистемі Red Hat, і цей випадок знову підкреслює масштаб залежності корпоративних Linux-дистрибутивів від спільних компонентів.
За даними Ars Technica, Intel заявила, що жоден із її комерційних продуктів, які перебувають на підтримці, не зачеплений, хоча OEM‑виробники можуть інтегрувати уразливий компонент самостійно. Arm повідомила, що вразливість не застосовна до її продуктового портфеля. Статус продуктів AMD, Phoenix Technologies, AMI, Microsoft і Amazon на момент публікації залишається невідомим.
Статус виправлення та історія розкриття
Виправлення було внесено до основної гілки EDK II 15 жовтня 2026 року. Патч переписує операцію копіювання так, щоб пакети, що перевищують 504 байти, усікалися, а не записувалися за межі буфера. Однак жоден стабільний реліз EDK II цей патч поки не включає — останній випуск edk2-stable202608 датований 21 серпня, а в бюлетені TianoCore версія з виправленням досі вказана як відсутня. За даними Ars Technica, Microsoft Project Mu вже інтегрував виправлення у свої релізні гілки 26 жовтня.
Вразливість виявлена Алексом Матросовим (Anthropic) і Деном Холмсом-Мітрою (Google). Скоординоване розкриття планувалося на січень 2027 року, але 28 вересня pull request від інженера AMI публічно описав вразливість із зазначенням CVE-номера та містив виправлення. Після цього TianoCore опублікував бюлетень 22 жовтня — на кілька тижнів раніше від запланованого терміну. Публічність патча означає, що кваліфіковані зловмисники можуть вивчити його для створення експлойтів.
Свідчень активної експлуатації на цей момент не виявлено. Вразливість не внесена до каталогу CISA KEV.
Рекомендації
Ключовий пріоритет — не очікування оновлення пакетів ОС, а відстеження виходу оновлень прошивки від виробника обладнання, оскільки саме вендор прошивки має випустити BIOS/UEFI-оновлення на основі виправленого коду EDK II. До появи такого оновлення:
- Вимкніть PXE-завантаження на всіх системах, де мережеве завантаження не є необхідним для робочих процесів;
- Контролюйте мережевий трафік у сегментах, де PXE-завантаження використовується, звертаючи увагу на аномальні ICMP-пакети в момент завантаження серверів;
- Зв’яжіться з виробником серверного обладнання або материнської плати для уточнення статусу вразливості та строків випуску оновлення прошивки;
- Обмежте мережевий доступ до сегментів із PXE-завантаженням, мінімізуючи можливість надсилання довільного трафіку із суміжних мереж.
Важливий практичний момент: на відміну від вразливостей обходу Secure Boot на кшталт BootHole та BlackLotus, CVE-2026-97631 усувається звичайним оновленням коду і не потребує відкликання сертифікатів або ключів, що спрощує процес патчингу після виходу оновлень.
Організаціям, які експлуатують серверну інфраструктуру з PXE-завантаженням, варто вже зараз провести інвентаризацію систем з активним мережевим завантажувачем, вимкнути PXE там, де він не критичний, і зафіксувати запит до вендора прошивки — стабільного релізу EDK II з виправленням поки немає, і строки його появи в конкретних продуктах залежать від кожного виробника окремо.
