Ошибка UEFI, живущая в коде EDK II с 2010 года, получила критическую оценку 9,5 из 10: во время PXE-загрузки она позволяет отправить серверу сетевой пакет и потенциально выполнить код ещё до проверки Secure Boot. Для инфраструктурных команд это не повод панически обновлять ноутбуки сотрудников, а повод срочно инвентаризировать серверы, стойки и лабораторное оборудование, которое стартует из сети.
Проблема зарегистрирована как CVE-2026-97631 и затрагивает EDK II — открытый базовый код для UEFI, на котором строят прошивки многие производители. О ней сообщает The Hacker News. Уязвимость находится в реализации PXE, то есть механизма, при котором машина получает загрузочный образ по сети, а не с локального диска. Самая неприятная часть истории — момент исполнения: успешная атака происходит до загрузки операционной системы и до того, как Secure Boot успевает проверить цепочку запуска.
Технически это переполнение буфера в обработчике ICMP-сообщений об ошибках. Драйвер PXE для IPv4 и IPv6 копирует полученные данные в область памяти размером 504 байта, но неверно проверяет длину сообщения. Пакет большего размера выходит за границы буфера и перезаписывает соседнюю память данными атакующего. Достаточно отправить специально подготовленное ICMP-сообщение в короткое окно, пока целевая машина загружается по сети.
Самый простой и реалистичный результат — отказ в обслуживании: сервер зависает на старте и не поднимается. Выполнение произвольного кода существенно сложнее. По данным консультативного сообщения TianoCore, для этого атакующему нужно знать точную сборку прошивки и подготовить эксплуатацию под неё — в частности, сформировать поддельное событие, которое передаст управление его коду. Но именно этот сценарий делает ошибку UEFI критичной: код получает контроль на уровне firmware, где до средств защиты ОС ещё очень далеко.
Ни пароль, ни учётная запись на сервере для атаки не нужны. Однако речь не идёт о компрометации любого компьютера из интернета: злоумышленник должен находиться в доступном сегменте сети и поймать машину в момент PXE-загрузки. Red Hat и SUSE классифицируют вектор как adjacent network — атаку из соседней сети, а не удалённую атаку через публичный интернет. Практический профиль угрозы здесь довольно приземлённый: инсайдер, скомпрометированное устройство в серверном VLAN или атакующий, уже закрепившийся в локальной инфраструктуре.
Патч есть в исходниках, обновления прошивок — не везде
Ошибка присутствует в EDK II вплоть до edk2-stable202608, выпущенной 21 августа 2026 года. Уязвимый фрагмент появился в проекте в ноябре 2010-го. Исправление уже попало в основную ветку разработки EDK II 15 октября: теперь слишком длинное сообщение должно обрезаться до безопасных 504 байт. Но на момент публикации ни один стабильный релиз EDK II этот патч не включал, а в консультативном сообщении TianoCore статус исправленной версии оставался «Not patched currently».
Для операторов это типичная, хотя и неприятная особенность прошивочной безопасности. Наличие патча в открытом проекте не означает, что его можно немедленно поставить на парк серверов. Производителю платы или системы необходимо собрать новую UEFI-прошивку, протестировать её и выпустить обновление BIOS/UEFI. Microsoft уже перенесла исправление в ветки Project Mu и выпустила помеченные сборки 26 октября. При этом статус продуктов AMD, AMI, Phoenix Technologies и Amazon на момент публикации оставался неясным.
Red Hat считает уязвимыми пакеты edk2 в RHEL 8, 9 и 10; аналогичный статус у пакетов SUSE и Debian. Это не означает, что обновление пользовательского пакета в Linux само по себе исправит прошивку каждого сервера: важно разделять EDK II как компонент дистрибутива и EDK II, уже скомпилированный в UEFI конкретного оборудования. Intel заявила, что среди её коммерческих продуктов на поддержке известных затронутых систем нет и что уязвимая функциональность не входит в её референсный код. Arm сообщила, что проблема не применима напрямую к её продуктовому портфелю. Оба заявления не исключают риск в прошивках OEM-производителей.
Код, выполненный через эту ошибку UEFI, сам по себе не переживает перезагрузку. Это ограничение снижает ценность одноразовой атаки, но не обнуляет её: получив контроль до ОС, атакующий теоретически может установить механизм постоянного запуска или добраться до чувствительных компонентов процесса старта. Исследователь Dragos Х. Д. Мур отдельно указал на риск для машин с TPM и дисковым шифрованием: краткого доступа к локальной сети может хватить, чтобы атаковать систему в особенно уязвимый момент.
Организациям, использующим PXE для развёртывания, bare-metal-кластеров, CI-стендов или восстановления серверов, стоит уже сейчас сопоставить инвентаризацию железа с политиками сетевой загрузки. Если PXE не нужен на конкретной машине, его отключение сокращает поверхность атаки до выхода прошивки. Там, где сетевая загрузка обязательна, полезно изолировать provisioning-сегмент, ограничить доступ к нему и отслеживать аномальные сообщения во время запуска. Универсального обходного пути разработчики EDK II пока не предложили.
История особенно неудобна для отрасли потому, что в январе 2024 года в том же PXE-коде EDK II уже раскрыли набор из девяти уязвимостей PixieFail. После него код активно проверяли фаззингом, но нынешняя ошибка осталась незамеченной. Пока нет признаков эксплуатации CVE-2026-97631 в реальных атаках, однако публичный патч заметно упрощает анализ уязвимого места. Главный вопрос теперь не в наличии исправления, а в скорости, с которой оно доберётся от исходного кода до прошивок в дата-центрах.
