11 старых Microsoft-signed shim-загрузчиков для Linux оказались достаточными, чтобы устроить обход Secure Boot на большинстве UEFI-систем, где по-прежнему доверяют сертификату Microsoft Corporation UEFI CA 2011. Для ИБ-команд и инфраструктурных администраторов это неприятная новость: даже патченая машина может получить буткит еще до старта ОС, если в цепочке загрузки остался старый, но не отозванный бинарник.
Об этом сообщает The Hacker News со ссылкой на исследование ESET. Речь идет не о свежем zero-day в привычном смысле, а о куда более раздражающем классе проблем: старые компоненты давно уязвимы, исправления для upstream-проекта уже были, но часть вендорских shim продолжала оставаться подписанной и доверенной. В результате злоумышленнику не нужно ломать Secure Boot в лоб. Достаточно подложить один из 11 старых UEFI-загрузчиков, подписанных Microsoft, и использовать доверие прошивки к легитимной подписи.
Механика атаки упирается в то, как устроен shim. Этот небольшой открытый загрузчик нужен Linux-дистрибутивам для запуска при включенном Secure Boot: сначала UEFI проверяет подпись самого shim по сертификату Microsoft, затем shim проверяет второй этап загрузки, обычно GRUB 2, а уже тот проверяет ядро. Если в этой цепочке появляется старый, уязвимый, но все еще доверенный shim, он позволяет выполнить неподписанный или вредоносный код на ранней стадии загрузки. А это уже территория UEFI-bootkit: уровень, где обычные средства защиты еще не проснулись и журналы EDR пока молчат.
Список затронутых загрузчиков выглядит как привет из музея корпоративной инфраструктуры, но именно такие экспонаты часто лежат на сервисных флешках, в образах аварийного восстановления и в старых пайплайнах развертывания. Среди 11 затронутых вариантов исследователи перечисляют shim из Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R9 и R10, OpenSUSE, а также загрузчики из Blancco WipeDrive версий 8.0.0-8.1.3, baramundi Management Suite до 2024R1, PC-Doctor Service Center 15 и 16, Abitti 1.0 и Spyrus WTGCreator. Набор показательный: проблема касается не только дистрибутивов, но и сервисных, диагностических и wipe-решений, которые нередко живут в инфраструктуре дольше, чем кто-либо готов признать на аудите.
Отдельный нюанс, из-за которого история выглядит особенно едко: сертификат Microsoft Corporation UEFI CA 2011 формально истек 27 июня 2026 года, но сам по себе факт истечения не мешает Secure Boot доверять уже подписанным бинарникам. Пока конкретный загрузчик не отозван через DBX-список, он остается рабочим ключом к ранней стадии загрузки. Microsoft уже отозвала загрузчики shim 0.9 и старше в июньский Patch Tuesday 2026 года, после того как ответственное раскрытие проблемы произошло в феврале. Но классический разрыв между «исправлено upstream» и «вычищено из реальной инфраструктуры» никуда не делся. Именно в этом окне и живет риск.
Исследователи ESET связывают проблему с двумя идентификаторами: CVE-2026-8863 и CVE-2026-10797. Второй относится к давно исправленной ошибке в shim, позволявшей обойти сертификатную схему отзыва через модификацию заголовка подписи у загрузчика второго этапа. Дополнительно ломается логика MOK denylist и механизм SBAT, который как раз придумывали затем, чтобы не поддерживать бесконечный черный список хэшей для каждого отдельного файла. На бумаге SBAT должен отсекать старые поколения компонентов цепочки загрузки. На практике старый, но все еще доверенный shim превращает эту защиту в рекомендацию, а не в барьер.
Для бизнеса и корпоративного ИТ это важнее, чем может показаться по слову Linux в заголовке. Уязвимость затрагивает любую UEFI-машину, которая доверяет старому сертификату Microsoft, независимо от установленной ОС. Это значит, что риск уходит за пределы Linux-парка как такового и упирается в контроль загрузочной среды. Если у атакующего уже есть права администратора или возможность изменить процесс загрузки, он может закрепиться ниже уровня операционной системы и пережить перезагрузки, а в некоторых сценариях и переустановку ОС. Для SOC это плохой расклад: вредоносный код стартует до инициализации встроенных механизмов защиты и EDR, а значит, сигналов меньше, расследование дороже, а восстановление часто требует не «переустановить систему», а пересобрать доверенную цепочку загрузки и носители.
Практический вывод довольно приземленный. Недостаточно просто поставить июньские обновления Microsoft и считать тему закрытой. Нужна инвентаризация старых recovery-образов, инженерных флешек, OEM-утилит, средств диагностики и wipe-инструментов, которые могут принести в среду старый shim. Нужна проверка DBX-обновлений на реальных машинах, а не в отчетах. Нужен пересмотр процедур, где загрузка с внешних носителей считается штатной операцией. И да, если где-то в шкафу лежит «проверенная сервисная флешка» пятилетней выдержки, она теперь больше похожа не на страховку, а на обход Secure Boot в красивом пластиковом корпусе.
История с этими 11 shim хорошо показывает, где у Secure Boot слабое место: не в криптографии как таковой, а в длине хвоста унаследованного доверия. Пока экосистема продолжает подписывать, хранить и не отзывать старые загрузочные компоненты, атаки на pre-boot-цепочку будут оставаться слишком дешевыми для своего эффекта. Подробности со списком затронутых загрузчиков и CVE приводит .