CVE-2026-8863 rompe Secure Boot
¿Sabías que tu equipo puede estar protegido y ser vulnerable al mismo tiempo?
Once viejos shims olvidados rompían Secure Boot en cualquier máquina UEFI.
ESET descubrió que estos bootloaders, firmados por Microsoft hace años, nunca fueron revocados. Cualquier atacante podía traer su propia copia y usarla sin necesitar acceso especial al sistema.
No hacía falta explotar ningún fallo nuevo ni tener el software afectado instalado. Bastaba con copiar el shim vulnerable a la partición EFI y reiniciar.
El arma perfecta no necesita vulnerabilidades nuevas ni exploits complejos.
ESET identificó 11 shims UEFI firmados por Microsoft en versiones 0.9 e inferiores que nunca fueron revocados. Estos bootloaders actúan como puerta de entrada al arranque: si Microsoft los firmó una vez, el firmware los sigue considerando de confianza. Un atacante solo necesitaba copiar uno a la partición EFI y reiniciar. Secure Boot no lo detendría, porque el binario llevaba la firma correcta.
Sin CVE nuevo, sin exploit sofisticado, sin barreras.
Desde esos shims antiguos se podía desplegar bootkits como Bootkitty, HybridPetya o BlackLotus incluso en sistemas completamente parcheados. Los shims anteriores a la versión 15.3 ignoran SBAT, el mecanismo de revocación por versiones, y cargan GRUB 2 sin verificar si ha sido revocado. Los GRUB 2 confiados por esos shims acumulaban vulnerabilidades desde 2013, incluyendo CVE-2015-5281.
Cada shim olvidado era una llave maestra sin fecha de caducidad.
Microsoft revocó los 11 shims en el Patch Tuesday del 9 de junio de 2026, tras la divulgación coordinada que ESET reportó a CERT/CC en febrero. Pero la pregunta que queda en el aire es cuántos shims firmados antes de 2017 siguen ahí sin que nadie los haya catalogado ni retirado.
Lo que no se cataloga no se revoca.
El proceso de firma se volvió más transparente en 2017 con el repositorio shim-review, donde los fabricantes envían sus binarios antes de que Microsoft los firme. Todo lo anterior es territorio desconocido: nadie puede decir cuántos shims viejos siguen siendo de confianza para el firmware.
El problema supera estos once casos.
Los shims provienen de herramientas de diagnóstico, distribuciones Linux y utilidades UEFI de todo tipo. Uno pertenecía al software Abitti de Finlandia; otro venía de Oracle Linux 7.1. Eran piezas legítimas que simplemente nunca fueron retiradas. El incidente BootHole en 2020 ya demostró que la revocación por hash tiene un límite físico que complica retirar binarios a gran escala.
Los shims anteriores a 0.9 ignoran la lista negra MOK.
Un administrador que revocó un certificado comprometido añadiéndolo a MokListX creía estar protegido. Pero si un atacante sustituía el shim actualizado por uno antiguo de versión 0.8, ese shim ignoraba la lista negra por completo y cargaba los binarios vulnerables sin restricción. La revocación quedaba anulada sin que nadie lo notara.
CVE-2026-10797 estuvo casi una década sin identificador CVE oficial.
El fallo fue corregido en un commit del repositorio upstream hace años, pero nunca recibió un CVE. Permite manipular la estructura WIN_CERTIFICATE de un bootloader para que el shim compare la revocación contra datos falsos, ignorando si el certificado real está bloqueado.
La firma expiraba, pero el riesgo no.
El certificado Microsoft Corporation UEFI CA 2011 expiró en junio de 2026, pero eso no cambia nada en Secure Boot. Si el certificado sigue en db y no está en dbx, todos los binarios que firmó siguen siendo de confianza. Microsoft continuó firmando nuevas solicitudes con ese certificado hasta el último día antes de su expiración.
La caducidad no es protección real.
Aplicar las últimas actualizaciones de revocación dbx de Microsoft es el paso inmediato. En Windows se instalan automáticamente; en Linux, a través del Linux Vendor Firmware Service.
Qué puedes hacer
- ✓Instala las últimas actualizaciones de revocación dbx de Microsoft.
- ✓En Linux, verifica el estado con el script uefi-dbx-audit.
- ✓Comprueba con PowerShell elevado las revocaciones aplicadas en Windows.
¿Cuántos shims olvidados siguen firmados y activos en mi equipo ahora mismo?
La seguridad no se improvisa, se audita. En Nacata Security detectamos vulnerabilidades y protegemos tu empresa, porque un solo fallo puede costarte todo lo que has construido.
Artículos relacionados
BitLocker toma empresas como rehenes
MessiahGPT forja malware sin límites
Impresoras repartieron notas de rescate
Talos abre sus archivos secretos
PHP cierra tres brechas críticas
Nacata Security, contáctanos cuando quieras
Somos Nacata Security, conócenos
web: nacata.io
email: info@nacata.io
Teléfono: 919930793
LinkedIn: Nacata Security
El ecosistema de los actores maliciosos y la inteligencia que se genera sobre ellos: grupos APT y su atribución, bandas de ransomware, operaciones policiales y detenciones, mercados de la dark web, informes de threat intelligence y el trasfondo geopolítico del cibercrimen.
RATING
7.3
¿Quiénes somos?
En Nacata Security somos una empresa de ciberseguridad ofensiva especializada en auditorías y test de intrusión.
Detectamos, evaluamos y ayudamos a mitigar las vulnerabilidades de tus sistemas, redes y aplicaciones antes de que un atacante real las explote, ofreciendo una defensa 360º adaptada a cada cliente.
Estamos encantados de contactar contigo para lo que quieras.