Qué es CVE-2026-97631 y qué tan grave es en realidad
CVE-2026-97631 es un desbordamiento de búfer en el controlador de arranque por red PXE de EDK II, la base de código abierto sobre la que casi todos los fabricantes construyen su firmware UEFI. TianoCore, el proyecto que la mantiene, publicó su aviso el 22 de octubre y le asignó 9,5 puntos sobre 10 de gravedad, según The Hacker News.
La mecánica se entiende rápido: el driver escucha los mensajes de error ICMP que devuelve la red durante un arranque PXE y copia cada uno en un espacio fijo de 504 bytes sin verificar antes el tamaño. Un mensaje más largo se derrama sobre la memoria contigua y la sobrescribe con datos elegidos por el atacante. El error está tanto en la versión IPv4 como en la IPv6 del código.
El primer nivel del impacto es una denegación de servicio: el arranque se cuelga y el servidor no levanta. El segundo es el que justifica la nota 9,5. Un atacante que conozca la build exacta de firmware puede colar instrucciones que la máquina ejecuta antes de que exista cualquier control del sistema operativo, antes de Secure Boot y antes del arranque medido, según el aviso de TianoCore. Ese código corre una sola vez y no persiste por sí mismo, pero alcanza para instalar algo que sí arranque en cada reinicio, según Ars Technica.
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →Un error de 16 años en el corazón del arranque por red
The Hacker News rastreó el historial del proyecto y encontró que el bucle defectuoso entró al código en un commit de noviembre de 2010. Es decir, la vulnerabilidad tiene alrededor de 16 años y sobrevivió a varias revisiones de EDK II.
El fallo está presente hasta edk2-stable202608, la versión estable más reciente, fechada el 21 de agosto. Y hay un agravante de configuración que pocos equipos revisan: el arranque por red PXE viene activado por defecto en la build estándar de EDK II, de acuerdo con The Hacker News.
Eso no significa que todos los servidores del mundo estén en riesgo. Significa que la función vulnerable está encendida a menos que alguien la apague.
¿Cuántos servidores están realmente expuestos?
Ars Technica tituló la historia como una amenaza para "la mayoría de los servidores del planeta". La propia cobertura matiza bastante esa frase.
El fallo solo es alcanzable durante la ventana en que la máquina arranca por red. Un servidor que arranca desde su disco local nunca toca ese camino. Y Red Hat y SUSE, que distribuyen el código afectado, clasificaron el fallo como explotable desde una posición de red adyacente, no desde internet abierto, según The Hacker News.
Los propios fabricantes reducen el universo. Intel declaró a Ars Technica que ninguno de sus productos comerciales bajo soporte de seguridad se conoce afectado y que no incluye la funcionalidad EDK2 afectada en su código de referencia, aunque un ensamblador podría agregarla. Arm dijo que el fallo no aplica directamente a su portafolio. AMD, Phoenix Technologies, AMI, Microsoft y Amazon no respondieron a las consultas antes de la publicación, así que el estado de sus productos sigue sin aclararse.
Traducción práctica: el titular describe, como mucho, el alcance potencial del código. El número real de máquinas atacables depende de cuántas arrancan por red y de qué firmware cargan.
El parche existe, pero tu servidor todavía no lo tiene
La corrección reescribe la copia defectuosa para truncar el mensaje a 504 bytes en lugar de desbordarlo, y llegó a la rama principal de EDK II el 15 de octubre. El problema es lo que vino después: ninguna versión estable de EDK II la incluye todavía, y el aviso de TianoCore seguía listando el estado como sin parchear, según The Hacker News. Microsoft llevó la corrección a su variante de firmware, Project Mu, y esa rama ya cortó builds etiquetados el 26 de octubre.
El desglose por distribuidor tampoco ayuda. Red Hat marca su paquete edk2 en RHEL 8, 9 y 10 como afectado y sin corregir. SUSE y Debian etiquetan sus paquetes equivalentes igual. BankInfoSecurity reporta que Debian identificó versiones vulnerables en sus ramas Bookworm, Trixie, Forky y Sid. AMI no recoge el caso en su página de avisos de seguridad.
Es el problema estructural del firmware: el arreglo tiene que recorrer una cadena que va del proyecto de código abierto al fabricante del firmware, de ahí al fabricante del servidor y, al final, al administrador que aplica la actualización de BIOS. Jesse Michael, investigador de la firma de seguridad de firmware Eclypsium, señaló a Ars Technica que este caso se resuelve con un parche de código básico y no exige revocar certificados ni claves, a diferencia de fallos como BootHole o BlackLotus.
Tampoco es la primera vez que esta parte del código falla. En enero de 2024 se divulgaron PixieFail, nueve fallos en el mismo bloque de EDK II, también alcanzables durante un arranque PXE, según The Hacker News.
El embargo roto y el hallazgo duplicado
La historia de la divulgación es casi tan interesante como el fallo. Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, encontraron la vulnerabilidad y habían coordinado la publicación para enero de 2027. El plan se rompió el 28 de septiembre, cuando un pull request firmado por un ingeniero de AMI describió el fallo por su número de CVE e incluyó la corrección en público. Al verlo, TianoCore publicó su aviso el 22 de octubre, semanas antes de lo previsto.
Matrosov lo resumió en X, según BankInfoSecurity: la investigación asistida por IA está acabando con los embargos, porque cuando todos usan las mismas herramientas y la misma inteligencia para buscar vulnerabilidades, nadie es el único que encuentra el bug. También advirtió que los equipos de seguridad de producto necesitan repensar sus procesos, con menos control de acceso y más despliegue continuo de parches.
Con el parche ya público, cualquier atacante avanzado puede estudiar cómo se dispara el fallo y construir exploits funcionales. Hasta el 27 de octubre, la vulnerabilidad no aparecía en el catálogo de vulnerabilidades explotadas de CISA, y ningún investigador reportó haberla visto en uso, según The Hacker News.
Qué significa esto para tu startup
No necesitas ser un banco para que esto te toque. Si tu producto corre en servidores propios o en hosting dedicado, o si tienes una flota de máquinas virtuales con firmware EDK II, estás en el mapa. Y si dependes de un proveedor cloud o de un hosting, la pregunta correcta ya no es si existe el parche, sino cuándo lo va a publicar tu fabricante.
Acciones concretas que puedes ejecutar esta semana:
- Audita si tus servidores arrancan por PXE. Si no lo necesitas, desactívalo. Es la única mitigación documentada mientras no haya actualización, y aplica igual a máquinas virtuales con firmware EDK II. Menos superficie expuesta, menos riesgo.
- Pregunta a tu proveedor por una fecha. Manda un ticket a tu hosting o al fabricante pidiendo el cronograma del BIOS o UEFI corregido. Si no hay respuesta, eso también es información: es tu nivel real de exposición.
- Segmenta la red de gestión. El ataque requiere estar en la red adyacente o tener ya un punto de apoyo interno. Si la VLAN de arranque está separada del resto y con acceso restringido, el escenario se vuelve mucho más difícil.
- Incluye el firmware en tu política de actualizaciones. Este caso vuelve a mostrar que el firmware es el eslabón que nadie revisa. Un inventario con modelo, fabricante y versión de BIOS te ahorra semanas cuando llegue el próximo aviso.
El aprendizaje de fondo es incómodo: el código que corre antes del sistema operativo es casi invisible para las defensas habituales, y su ciclo de actualización se mide en meses, no en horas. Quien administra infraestructura necesita saber dos cosas concretas: si sus máquinas arrancan por red y cuándo publicará su fabricante la BIOS corregida. Lo segundo, a día de hoy, sigue sin respuesta.
Fuentes
- Fallo UEFI EDK2 PXE CVE-2026-97631 en servidores (fuente original)
- Code-execution flaw in UEFI firmware affects most servers on planet Earth
- Critical 16-Year-Old UEFI Flaw Can Run Code Before Secure Boot on Network-Booting Servers
- Critical UEFI Flaw Exposes Systems to Pre-Boot Attacks
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →
