Уязвимость прошивки UEFI CVE-2026-97631: патч опубликовали досрочно

Безопасность

Уязвимость прошивки UEFI CVE-2026-97631: патч опубликовали досрочно

Эксплойт в ICMP-компоненте прошивки TianoCore EDK II запускает код на сервере раньше Secure Boot и операционной системы

В TianoCore EDK II нашли уязвимость прошивки UEFI CVE-2026-97631 с оценкой 9,5 из 10. Через неё злоумышленник выполняет код ещё до загрузки ОС, а на коде EDK II собирают прошивки почти все производители серверного железа. Раскрытие планировали на январь, но, по данным Ars Technica, AMI около месяца назад выложила исправление в публичном pull request. Обновление ОС от этой дыры не спасает.

Коротко

  • CVE-2026-97631 в ICMP-компоненте TianoCore EDK II даёт злоумышленнику выполнить код до загрузки ОС и до Secure Boot, оценка 9,5 из 10.
  • Уязвимый код есть у AMI, Insyde, Phoenix и в Microsoft Project Mu; по данным Ars Technica, исправление около месяца назад появилось в публичном PR от AMI.
  • Обновление ОС не спасает: нужен бюллетень производителя платформы и перепрошивка UEFI, а до него стоит отключить лишнюю сетевую загрузку.

Почему обновление ОС не закрывает уязвимость прошивки UEFI

Уязвимость находится в прошивке платформы, а не в Windows, Linux или гипервизоре. CVE-2026-97631 относится к классу «повреждение памяти» и сидит в ICMP-компоненте TianoCore EDK II. Уязвимую функцию и точку вызова в публикациях не раскрывают.

EDK II это открытая эталонная реализация UEFI, в прошлом году представитель UEFI Forum назвал её главной. На этом коде строят прошивки почти все независимые разработчики BIOS (IBV), включая AMI, Insyde и Phoenix. Уязвимый компонент был даже в Project Mu, hardened-форке EDK II от Microsoft.

От себя добавим: сетевой стек UEFI нужен для PXE- и HTTP-загрузки, поэтому сборка на EDK II ещё не значит, что уязвимый ICMP-код в конкретной прошивке включён и доступен по сети.

Закрывает ли Secure Boot CVE-2026-97631?

Нет. Код злоумышленника стартует раньше, чем Secure Boot выстраивает цепочку доверия для загрузочного кода, включая TPM. А ошибку памяти внутри уже доверенной прошивки проверка подписей и не видит.

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

По нашему опыту, TPM и Measured Boot эксплуатацию не блокируют, а только записывают измерения в PCR для аттестации. EDR внутри ОС происходящее в UEFI тоже не видит.

Как сорвалось эмбарго и почему публичный патч опасен

Уязвимость нашли Алекс Матросов (Alex Matrosov) из Anthropic и Дэн Холмс-Митра (Dan Holmes-Mitra) из Google, пишет Ars Technica. Раскрытие назначили на январь, но примерно за месяц до публикации Ars Technica AMI выложила pull request с описанием ошибки и исправлением. Когда исследователи его заметили, участники TianoCore выпустили публичный бюллетень, за неделю до статьи.

Патч показывает, какой именно код поменялся. По оценке Ars Technica, квалифицированным злоумышленникам будет несложно вычислить по нему условие срабатывания и собрать рабочий эксплойт. Пока это прогноз: об атаках и пострадавших не сообщалось.

За шесть дней до этой истории так же досрочно раскрыли критическую уязвимость выполнения кода в PHP, похожий сюжет мы разбирали в материале PHP2Shell в реальных атаках. Только у прошивки путь от upstream до сервера в стойке намного длиннее.

Как узнать, касается ли CVE-2026-97631 ваших серверов?

Только через производителя платформы: пакетный менеджер, обновление гипервизора или CMS прошивку не трогают. Исправление из EDK II переносят к себе IBV, затем OEM, ODM и облачные провайдеры, и каждый тестирует образ под свои модели.

  • Составьте список: производитель и модель платы, IBV (AMI, Insyde, Phoenix или собственный форк), версия и дата UEFI.
  • Запросите у OEM бюллетень именно по CVE-2026-97631 с матрицей моделей и версий: номер коммита TianoCore о вашей прошивке ничего не скажет.
  • Для облака и bare metal спросите провайдера, закрыты ли хосты. Если стек опирается на Microsoft, уточните статус Project Mu.
  • Пока патча нет, отключите неиспользуемую PXE- и HTTP-загрузку по IPv4 и IPv6 и изолируйте boot-сеть от пользовательских VLAN. Это сужает поверхность атаки, но не заменяет патч.
  • Прошивайте в окно обслуживания с доступом к BMC и после перезагрузки проверьте, что версия сменилась.

Не проверяйте прод самодельными ICMP-пакетами: сбой памяти до загрузки ОС может повесить сервер так, что удалённая перезагрузка не поможет.

Версии UEFI стоит включить в регулярный аудит уязвимостей, а изоляцию boot-сетей проверить на внутреннем пентесте сети.

Частые вопросы

Что такое уязвимость CVE-2026-97631 в UEFI?

Это уязвимость класса «повреждение памяти» в ICMP-компоненте TianoCore EDK II. Через неё злоумышленник выполняет код до загрузки ОС и раньше, чем Secure Boot выстроит цепочку доверия.

Касается ли CVE-2026-97631 AMI, Insyde и Phoenix?

Эти IBV строят прошивки на коде EDK II, уязвимый компонент был и в Microsoft Project Mu. Закрыта ли конкретная модель, скажет только бюллетень её производителя.

Есть ли эксплуатация CVE-2026-97631 в реальных атаках?

На момент публикации об атаках не сообщалось. Но патч публичный, и, по оценке Ars Technica, квалифицированным злоумышленникам будет несложно собрать по нему эксплойт.

Помогает ли обновление ОС при уязвимости прошивки UEFI?

Нет. Нужно перепрошить UEFI по бюллетеню производителя платформы или облачного провайдера и после перезагрузки проверить версию.

Если серверы в парке стоят на разных платформах и непонятно, где какая прошивка, команда HirexTech поможет провести инвентаризацию и вести учёт версий прошивок. Подробнее о наших работах по информационной безопасности.

Прокрутить вверх