Критическая уязвимость переполнения буфера 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 с исправлением пока нет, и сроки его появления в конкретных продуктах зависят от каждого производителя индивидуально.
