В TianoCore EDK II (EDK2) обнаружили критическую уязвимость CVE-2026-97631 (9,5 балла по шкале CVSS), которая позволяет выполнить код на этапе загрузки системы, еще до запуска ОС и защитных механизмов вроде Secure Boot. Так как EDK2 лежит в основе UEFI-прошивок огромного количества серверов, потенциальный масштаб проблемы велик. При этом информацию об уязвимости раскрыли на несколько месяцев раньше запланированного срока из-за случайной публикации патча.

Уязвимость представляет собой переполнение буфера в сетевом стеке EDK2. Этот опенсорсный проект широко используют производители оборудования, облачные провайдеры и поставщики UEFI, включая AMI, Insyde и Phoenix. Кроме того, уязвимый компонент также применялся в Project Mu — усиленном форке EDK2, созданном специалистами Microsoft.

Проблему обнаружили Алекс Матросов (Alex Matrosov) из компании Anthropic и Дэн Холмс (Dan Holmes) из компании Google, и изначально раскрытие информации о баге было запланировано на январь 2027 года. Однако в сентябре 2026 года специалисты AMI случайно опубликовали пул-реквест с патчем и описанием самой уязвимости. После этого сохранить проблему в секрете уже не представлялось возможным, и на прошлой неделе разработчики TianoCore выпустили официальный бюллетень безопасности.

В TianoCore сообщили, что CVE-2026-97631 присутствует в коде EDK2 около 16 лет и затрагивает драйвер PXE Base Code (NetworkPkg/UefiPxeBcDxe), который отвечает за загрузку серверов, систем хранения и других устройств по сети.

Во время PXE-загрузки драйвер ожидает ICMP-сообщения об ошибках и копирует полученные данные в фиксированное поле Mode.IcmpError размером 504 байта. Однако обработчики IPv4 и IPv6 некорректно проверяют границы буфера: если сообщение оказывается длиннее 504 байт, копирование все равно продолжается. Кроме того, при поэтапном копировании код неправильно рассчитывает смещение внутри буфера, из-за чего данные записываются все дальше за его пределы.

В итоге специально сформированное ICMP-сообщение позволяет записывать данные за пределы буфера и повреждать соседние области памяти UEFI. Причем такое сообщение можно отправить обычным unicast-пакетом на IP-адрес цели, и основная задача атакующего — попасть в окно PXE-загрузки.

Результатом эксплуатации уязвимости может стать «зависание» процесса загрузки и отказ в обслуживании (DoS). Однако если атакующему известен конкретный билд прошивки и расположение нужных объектов в памяти, он сможет добиться выполнения собственного кода в UEFI-среде. В этом случае код выполняется в ring 0 — на самом высоком уровне привилегий процессора.

Подчеркивается, что в этом случае код запускается на этапе, когда процесс загрузки еще имеет доступ к чувствительным компонентам вроде TPM, а Secure Boot и другие механизмы защиты еще не сформировали полноценную цепочку доверия. Фактически атака позволяет обойти механизмы аттестации, которые должны криптографически подтверждать удаленным системам, что устройство находится в доверенном состоянии.

Хотя сам пейлоад для CVE-2026-97631 не переживает перезагрузку устройства, он может использоваться для установки других компонентов, которые уже будут запускаться при каждом старте системы.

К счастью, эксплуатацию этой уязвимости вряд ли можно назвать простой и универсальной. Так, атакующему потребуется заранее получить доступ к локальной сети жертвы или найти другую возможность для отправки трафика цели во время PXE-загрузки. Кроме того, эксплоит придется адаптировать под конкретную модель устройства, версию прошивки и конфигурацию, поскольку адреса в памяти будут отличаться.

Проблема CVE-2026-97631 практически не затронет обычных пользователей, которые загружают свои системы только с локальных накопителей. В зоне риска прежде всего находятся серверы, системы хранения данных и другая инфраструктура, где используется PXE, причем функция сетевой загрузки нередко включена по умолчанию.

Представители Intel сообщили изданию Ars Technica, что, по имеющимся данным, коммерческие продукты компании, которые сейчас получают обновления безопасности, не затронуты CVE-2026-97631. Они подчеркивают, что уязвимая функциональность EDK2 не входит в референсный код Intel, но ее могут добавлять OEM-производители материнских плат или готовых систем. Поэтому в компании советуют уточнять статус конкретных платформ у их производителей.

Журналисты отмечают, что при этом публичный референсный код Intel содержит отсылки к EDK2. Кроме того, разработчики TianoCore писали, что каждый набор средств разработки UEFI, поставляемый Intel, представляет собой полностью проверенную имплементацию определенной ревизии кода EDK II.

В свою очередь представители Arm заявили изданию, что CVE-2026-97631 «напрямую не применима» к продуктам компании. В то же время опубликованные Arm прошивки во многом используют код EDK2, и это подтверждается документацией TianoCore.

Исправление проблемы CVE-2026-97631 потребует обновления BIOS/UEFI. До появления патча для конкретной системы специалисты советуют по возможности отключить функцию сетевой загрузки и следить за логами на предмет попыток эксплуатации. TPM и Secure Boot также рекомендуется держать включенными, хотя непосредственно от CVE-2026-97631 они не защищают.

Отметим, что CVE-2026-97631 пополнила длинный список проблем, связанных с UEFI. Ранее исследователи обнаруживали уязвимости LogoFail, позволявшие атаковать цепочку загрузки через обработчики изображений; похожие на CVE-2026-97631 PXE-баги под названием PixieFail, затрагивавшие EDK2; проблему PKFail, связанную с тестовыми ключами Secure Boot; а также BootHole и буткит BlackLotus.

По мнению создателя Metasploit и специалист компании Dragos Эйч Ди Мура (HD Moore), новая уязвимость тоже рискует превратиться в «вечный» баг, который годами будет присутствовать в устаревших системах, уже не получающих поддержки.