Once cargadores UEFI shim antiguos, pese a ir firmados por Microsoft, pueden permitir eludir UEFI Secure Boot en equipos que aún confían en Microsoft Corporation UEFI CA 2011. Microsoft ya ha distribuido revocaciones en DBX y la prioridad pasa por aplicarlas sin romper el arranque, actualizando antes los componentes a versiones modernas con SBAT.
El problema no está en un bug exótico del kernel ni en una cadena de exploits sofisticada, sino en algo más incómodo: binarios viejos que siguen siendo válidos por la firma que llevan. Un total de once UEFI shim antiguos, en versiones 0.9 o anteriores, pueden usarse para saltarse UEFI Secure Boot en sistemas cuyo firmware todavía confía en el certificado Microsoft Corporation UEFI CA 2011. El riesgo aparece cuando un atacante consigue colocar uno de esos shims vulnerables en la ruta de arranque y logra ejecutar código antes de que arranque el sistema operativo.
La técnica se parece a un BYOVD llevado a la fase pre OS: en vez de ‘traer tu propio driver vulnerable’, el atacante aporta un cargador vulnerable pero correctamente firmado. Eso cambia la lógica de defensa. No hace falta que el equipo tenga instalado el software original que incluyó ese shim, basta con que el firmware acepte la firma y el atacante pueda modificar el proceso de arranque, por ejemplo tocando el disco, una partición EFI o un medio de arranque.
El alcance es especialmente delicado porque el código se ejecuta antes del SO. Ahí resulta más fácil lograr persistencia, desplegar un bootkit UEFI o colar componentes maliciosos que acaben en el kernel. También se reduce la visibilidad: parte de la telemetría típica de un EDR empieza a funcionar cuando el sistema ya está en marcha, no cuando el firmware decide qué binario considera ‘de confianza’.
Las referencias públicas reparten el conjunto de shims entre varias entradas, con CVE-2026-8863 y CVE-2026-10797 cubriendo distintas porciones del problema. En la lista aparecen implementaciones asociadas a Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE, y también herramientas de terceros como baramundi Management Suite hasta 2024R1, WipeDrive 8.0.0 a 8.1.3, PC Doctor Service Center o Abitti 1.
La mitigación principal ya está encima de la mesa: revocar esos shims mediante actualizaciones de la lista DBX de Microsoft. Tras aplicar la revocación, el firmware deja de considerarlos válidos durante el arranque, aunque estén firmados. Esto también aclara una confusión habitual: la caducidad del certificado Microsoft UEFI CA 2011, fechada el 27 de junio de 2026, no invalida automáticamente los binarios firmados en el pasado. Mientras el certificado siga presente en la base DB y el hash no entre en DBX, el arranque puede aceptarlos.
Aquí viene la parte delicada para administradores: tocar DBX puede dejar equipos sin arrancar si conviven componentes antiguos. La receta prudente pasa por actualizar primero shim, GRUB y el resto de piezas de la cadena de arranque a versiones actuales con protecciones SBAT, y después desplegar las revocaciones. Conviene probar antes en un subconjunto representativo, verificar el estado final de DBX con utilidades como Check UEFISecureBootVariables en Windows o uefi dbx audit en Linux, e inventariar medios de rescate y USB de mantenimiento. Si esos soportes usan shims antiguos, pueden quedar inservibles justo cuando más falta hacen.
Más información
- The Hacker News – 11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot : https://thehackernews.com/2026/07/11-old-microsoft-signed-linux.html
- CERT Coordination Center – VU#616257: Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass : https://www.kb.cert.org/vuls/id/616257
- NIST NVD – CVE-2026-8863 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-8863
- Help Net Security – No one knows how many old shims can still bypass UEFI Secure Boot : https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/
Deja una respuesta