Un equipo de investigadores de ESET ha identificado once cargadores de arranque UEFI shim antiguos y olvidados, en versiones 0.9 e inferiores, que permiten eludir la protección UEFI Secure Boot en cualquier sistema basado en UEFI que confíe en el certificado de autoridad (CA) de terceros Microsoft Corporation UEFI CA 2011, independientemente del sistema operativo instalado. Estos shims, que datan de un periodo en el que las medidas de seguridad del ecosistema eran menos maduras, habían permanecido firmados y válidos, creando una puerta trasera silenciosa en la cadena de confianza del arranque seguro.
El hallazgo: once shims olvidados que comprometen el núcleo de la seguridad en el arranque
Los investigadores de ESET descubrieron que estos antiguos cargadores de arranque, al estar firmados con el certificado Microsoft Corporation UEFI CA 2011, pueden ser utilizados por un atacante para ejecutar código no verificado durante el inicio del sistema. Esto abre la puerta al despliegue de bootkits UEFI maliciosos como Bootkitty, HybridPetya o BlackLotus, incluso en equipos con UEFI Secure Boot activado. La vulnerabilidad no reside en un fallo de software complejo, sino en la propia persistencia de binarios antiguos y sin revocar en la base de datos de confianza.
El ataque no se limita a sistemas que tengan instalado el software o sistema operativo afectado. Un atacante puede llevar su propia copia de estos shims vulnerables a cualquier sistema UEFI que tenga inscrito el certificado CA de terceros de Microsoft, un escenario que abarca a la gran mayoría de los equipos modernos. Los investigadores reportaron sus hallazgos al CERT/CC en febrero de 2026, y como resultado, las aplicaciones UEFI vulnerables fueron revocadas en la actualización del Patch Tuesday del 9 de junio de 2026 de Microsoft.
Más allá del error: la superficie de ataque se extiende a cargadores secundarios
Aunque se asignaron dos identificadores CVE —CVE-2026-8863 y CVE-2026-10797— para cubrir los shims reportados, el verdadero riesgo va más allá de los fallos directos en estos antiguos binarios. Como señala el equipo de ESET, la superficie de ataque se amplía significativamente a través de los cargadores de arranque de segunda etapa en los que estos shims confían, principalmente GRUB 2. Al igual que los propios shims, estos cargadores secundarios pueden ser versiones obsoletas con vulnerabilidades conocidas, como las asociadas a BootHole. Los shims descubiertos provienen de diversas herramientas y paquetes de software, incluyendo software de diagnóstico para PC, distribuciones de Linux y otras utilidades basadas en UEFI.
La lista completa de productos de software que dependen de estos shims y sus versiones afectadas está disponible en la Nota de Vulnerabilidad del CERT/CC. En respuesta al informe de ESET, se revocaron los siguientes hashes Authenticode de los cargadores UEFI shim en la actualización de la base de datos dbx de Microsoft:
- AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
- 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
- EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
- FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
- A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
- 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
- 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
- 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
- 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
- 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
- 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629
¿Qué es un UEFI shim y por qué es crítico para Secure Boot?
Para comprender el impacto de estos shims vulnerables, es necesario entender cómo funciona UEFI Secure Boot y cómo estos pequeños cargadores de arranque extienden la cadena de confianza. Cuando el firmware UEFI carga una aplicación de arranque, como el gestor de arranque de Windows o un shim UEFI, verifica el binario contra dos bases de datos de Secure Boot: db (certificados y hashes permitidos) y dbx (certificados y hashes prohibidos). La imagen debe ser confiable para db y no estar listada en dbx. Para que esto funcione de fábrica, la mayoría de los OEM inscriben un conjunto de certificados UEFI de Microsoft, incluido el certificado para software de terceros, el Microsoft Corporation UEFI CA 2011.
El problema surge con el diseño de los shims. Las distribuciones de Linux, por ejemplo, necesitan una forma de arrancar de forma segura sin que cada versión de su gestor de arranque tenga que ser firmada directamente por Microsoft. La solución es un shim: un cargador de primera etapa mínimo y firmado por Microsoft que crea un ancla de confianza secundaria para el resto de la pila de arranque de la distribución, generalmente GRUB 2 y el kernel de Linux. Este ancla de confianza es un certificado de proveedor, gestionado por la distribución, que se incrusta en el binario del shim antes de ser firmado por Microsoft. De esta manera, una distribución puede actualizar su gestor de arranque y kernel con su propia clave, sin necesidad de recurrir a Microsoft en cada actualización. El problema es que este sistema de confianza delegada no es eterno y los shims antiguos, una vez firmados, mantienen su poder si no se revocan explícitamente.
La clave de la máquina (MOK) y el Secure Boot Advanced Targeting (SBAT)
Dos mecanismos son esenciales para entender la seguridad de los shims modernos y cómo los antiguos los eluden. El primero es la Machine Owner Key (MOK), que permite a los usuarios añadir sus propias claves externas a la cadena de confianza del shim. La MOK se almacena en variables de solo arranque, lo que requiere acceso físico para modificarlas. El segundo es el Secure Boot Advanced Targeting (SBAT), introducido a partir del shim versión 15.3. SBAT añade metadatos a cada componente UEFI (como shim o grub) con un número de generación que se incrementa con cada parche de seguridad. Una política en el propio sistema, gestionada por el shim, define el número de generación mínimo aceptable, permitiendo revocar versiones enteras de forma más eficiente que añadiendo hashes individuales a la base de datos dbx.
Los shims descubiertos por ESET, al ser anteriores a la implementación de SBAT y a las mejoras en el manejo de MOK, ignoran por completo estos mecanismos de seguridad modernos, dejando el sistema expuesto.
Cómo se elude Secure Boot con estos shims olvidados
La investigación de ESET detalla varios escenarios de ataque que demuestran la gravedad del problema. No se trata de vulnerabilidades de ejecución remota de código complejas, sino de fallos de diseño y de gestión del ciclo de vida del software.
Cargadores de segunda etapa vulnerables
Cada uno de los once shims reportados confía en un conjunto de binarios de segunda etapa (principalmente GRUB 2, MokManager y cargadores de respaldo). Las marcas de tiempo de compilación de estos binarios van desde 2013 hasta 2025, lo que indica que muchos son antiguos y contienen vulnerabilidades públicas conocidas. Un ejemplo claro es el shim de Oracle Linux, que confía en binarios firmados con un certificado de Oracle Corporation. Entre ellos se encuentra un binario de GRUB 2 de Oracle Linux 7.1 afectado por CVE-2015-5281. Esta vulnerabilidad permite a un atacante con acceso local eludir Secure Boot y ejecutar código no verificado a través de un módulo multiboot o multiboot2 manipulado. La explotación no requiere técnicas complejas como cadenas ROP; solo es necesario construir una imagen de kernel multiboot2 personalizada y copiarla junto con el shim y GRUB 2 vulnerables a la partición del sistema EFI. Un simple comando multiboot2 en GRUB 2 permite cargar y ejecutar el código malicioso.
La ausencia de funciones de seguridad modernas
El problema se agrava con la falta de características de seguridad que se introdujeron en versiones posteriores del shim. La característica de lista de denegación de MOK (MokListX) solo se empezó a aplicar a partir de la versión 0.9. Imaginemos una empresa que ha revocado un certificado de firma antiguo añadiéndolo a MokListX e inscribe uno nuevo. Un atacante podría reemplazar el shim actualizado de la víctima por un shim antiguo de la lista de ESET, como uno de la versión 0.8. Este shim antiguo sigue confiando en los certificados almacenados en MokList, pero ignora por completo MokListX, anulando la revocación y permitiendo cargar binarios vulnerables.
El mismo principio se aplica a SBAT. Cualquier shim anterior a la versión 15.3 desconoce por completo este mecanismo. No lee la política de revocación SbatLevel ni inspecciona la sección .sbat del cargador de segunda etapa. Un atacante puede emparejar un shim pre-15.3, como uno de Red Hat Enterprise Linux 7.2, con un binario de GRUB 2 que el shim sigue confiando pero que SBAT ya ha revocado. El shim, al no consultar SBAT, carga el binario vulnerable sin problemas.
Vulnerabilidades conocidas en los propios shims
Además de permitir la explotación de componentes secundarios, los propios shims antiguos contienen fallos de seguridad. ESET destaca un problema en shims de versión 0.9 e inferiores, ahora rastreado como CVE-2026-10797. La vulnerabilidad radica en una discrepancia en la validación de la longitud de la firma Authenticode. La función de comprobación de revocación y la de verificación de firma confiaban en diferentes valores para la longitud de la firma. Esto permite manipular la estructura WIN_CERTIFICATE del cargador de segunda etapa para que la función de revocación compare contra datos falsos, eludiendo la revocación basada en certificados en dbx y MokListX.
¿Resuelve el problema la expiración de los certificados UEFI de Microsoft?
Una pregunta lógica es si la expiración del certificado Microsoft Corporation UEFI CA 2011, ocurrida el 27 de junio de 2026, resuelve el problema. La respuesta es no. La fecha de expiración de un certificado no afecta al proceso de verificación de Secure Boot. Mientras el certificado permanezca en la base de datos db y no sea revocado en dbx, todos los cargadores de arranque firmados válidamente con él, aunque esté caducado, siguen siendo considerados confiables a menos que se revoquen explícitamente por su hash. Por esta razón, Microsoft continuó firmando nuevas presentaciones con el certificado antiguo hasta su fecha de expiración. La única solución efectiva es la revocación explícita, como la realizada en el Patch Tuesday de junio de 2026.
Protección y detección: cómo verificar si el sistema está parcheado
La principal medida de protección es asegurarse de que las últimas revocaciones UEFI de Microsoft estén instaladas. Los sistemas Windows deberían actualizarse automáticamente a través de Windows Update. Para verificarlo manualmente en un sistema Windows, se pueden ejecutar los siguientes comandos en PowerShell con permisos elevados, que comprueban si los hashes de los once shims vulnerables están presentes en la base de datos dbx:
$hashes="AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961",
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
$notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
"All hashes revoked in dbx!"
}Para sistemas Linux, las actualizaciones están disponibles a través del Linux Vendor Firmware Service, y el estado de la revocación se puede verificar con el script uefi-dbx-audit.
El problema de fondo: la visibilidad en la cadena de firma de shims
La revocación de estos once shims soluciona el problema inmediato, pero deja al descubierto una cuestión más profunda: la falta de visibilidad. El proceso de firma de shims se volvió mucho más transparente en 2017 con la introducción del repositorio shim-review, donde las presentaciones de los proveedores son examinadas antes de ser firmadas por Microsoft. Todos los shims aprobados desde entonces están documentados. Sin embargo, los anteriores a 2017 no lo están, y nadie puede decir con certeza cuántos de esos shims antiguos, aún confiables, permanecen activos. Lo que no se ha catalogado de forma completa y transparente no puede ser retirado de manera efectiva.
A pesar de esto, la tendencia es positiva. Cada divulgación como esta reduce el conjunto de shims olvidados. Con la mejora de la transparencia en la firma y mecanismos como SBAT, gestionar lo que debe ser revocado es ahora mucho más eficiente. El siguiente paso lógico es extender este nivel de transparencia a todo el ecosistema de firmas UEFI de terceros que no son shims, como aplicaciones de diagnóstico o utilidades de cifrado, que, como se ha demostrado repetidamente (CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250), también pueden servir como una fuente directa de elusión de UEFI Secure Boot. La seguridad del arranque, en última instancia, no depende solo de parches, sino de una gestión del ciclo de vida de confianza que sea tan rigurosa como el propio proceso de firma inicial.
