- CVE-2026-97631 es un desbordamiento de búfer en el controlador PXE de EDK II, con gravedad 9,5 y ejecución potencial antes del sistema operativo.
- El riesgo se limita a equipos que arrancan por red PXE con firmware vulnerable; los que inician desde disco local no usan ese camino.
- El parche está en la rama principal de EDK II, pero todavía debe llegar a versiones estables, distribuidores y fabricantes de equipos.
- Medidas recomendadas: desactivar PXE si no se usa, segmentar la red de arranque, consultar al proveedor e inventariar versiones de firmware.
La seguridad del firmware vuelve a ponerse en el punto de mira por CVE-2026-97631, una vulnerabilidad catalogada con 9,5 sobre 10 en EDK II, la base de código abierto sobre la que se construyen numerosas implementaciones de UEFI. El fallo se localiza en el arranque por red PXE y permite que un atacante con acceso a la red adecuada pueda interferir en una fase previa a la carga del sistema operativo, cuando todavía no actúan defensas habituales como Secure Boot o el arranque medido.
Aunque el titular pueda sonar a amenaza global, la exposición real depende de varios factores: que el equipo arranque por PXE, que su firmware incluya el controlador afectado y que el atacante pueda enviar tráfico ICMP durante esa ventana de arranque. Las máquinas que solo inician desde disco local no recorren ese camino, y hasta la fecha no consta explotación activa ni inclusión en el catálogo de vulnerabilidades explotadas de CISA.
Qué es el fallo y cómo se activa
El problema se encuentra en el controlador PXE-Base Code, identificado como NetworkPkg/UefiPxeBcDxe, encargado de gestionar el arranque desde la red. Mientras el equipo permanece en ese proceso, el controlador mantiene abierta la recepción de mensajes de error ICMP; al recibir uno, copia su contenido en un campo fijo de 504 bytes llamado Mode.IcmpError. Los manejadores de IPv4 e IPv6 no validan correctamente el tamaño, de modo que un mensaje sobredimensionado puede escribir datos más allá del espacio reservado, avanzar el puntero de destino con la longitud acumulada y corromper memoria del firmware.
La consecuencia más directa es una denegación de servicio: el arranque se cuelga y el equipo no termina de iniciar. El escenario más delicado aparece cuando el atacante conoce la versión exacta del firmware, algo que puede permitirle preparar un paquete para ejecutar código en el entorno UEFI con privilegios de anillo 0, antes de que el sistema operativo o sus controles de integridad entren en juego. Esa ejecución no persiste por sí sola, pero puede servir para instalar otro componente que sí sobreviva a reinicios posteriores.
El historial del proyecto sitúa el origen del fallo en un cambio de noviembre de 2010, por lo que la vulnerabilidad ha permanecido unos 16 años en el código y ha superado distintas revisiones de EDK II. El aviso también señala que el arranque por red PXE viene activado por defecto en la build estándar de EDK II, una circunstancia que amplía la superficie potencial si no se revisa la configuración. No obstante, que la función esté habilitada no equivale a que todos los equipos sean atacables: hace falta que se use durante el arranque y que el firmware concreto incluya el controlador vulnerable.
Alcance real y condiciones de exposición
El requisito de red reduce bastante el universo de equipos expuestos. El ataque no se plantea como una entrada universal desde internet abierto, sino desde una posición de red adyacente o con cierto punto de apoyo interno, según las clasificaciones de distribuidores como Red Hat y SUSE. Además, el equipo debe estar arrancando por PXE en el momento del envío del mensaje ICMP, algo que no ocurre en servidores configurados para iniciar siempre desde su disco local.
La frase de que la mayoría de los servidores del planeta estaría en riesgo describe, mucho, el alcance potencial del código compartido, no un recuento confirmado de máquinas vulnerables. Intel y Arm indicaron que sus productos comerciales bajo soporte no se ven directamente afectados, aunque un fabricante podría integrar la funcionalidad vulnerable en sus diseños. En las primeras coberturas, AMD, Phoenix Technologies, AMI, Microsoft y Amazon no habían aclarado su situación, y AMI tampoco recogía el caso en su página de avisos, por lo que la identificación del firmware instalado y la consulta al proveedor siguen siendo pasos necesarios.
En España y Europa, el riesgo se concentra en organizaciones que gestionan servidores propios, hosting dedicado o flotas de máquinas virtuales con firmware basado en EDK II. Desactivar PXE donde no sea imprescindible, separar la VLAN de arranque y revisar el inventario de versiones de BIOS o UEFI son medidas útiles mientras se confirma el estado de cada fabricante. También conviene preguntar a los proveedores cloud o de hosting por su calendario de actualización, porque el parche existe en el código fuente pero su llegada al equipo final depende de una cadena con varios intermediarios.
Parche, divulgación y cadena de actualización
La corrección reescribe la copia defectuosa para truncar el mensaje a 504 bytes en lugar de desbordar el campo y llegó a la rama principal de EDK II el 15 de octubre. Sin embargo, ninguna versión estable de EDK II la incluía en el momento del aviso, según el propio proyecto, y Microsoft llevó el arreglo a su variante Project Mu en builds posteriores. Red Hat marcaba su paquete edk2 en RHEL 8, 9 y 10 como afectado y sin corregir; SUSE y Debian también etiquetaban sus paquetes equivalentes como pendientes, con versiones vulnerables en varias ramas de Debian.
El caso muestra el problema estructural del firmware: el arreglo viaja del proyecto de código abierto al fabricante del firmware, de ahí al fabricante del servidor y, finalmente, al administrador que aplica la actualización. Ese recorrido puede tardar meses y explica por qué no basta con que el parche sea público. Jesse Michael, investigador de Eclypsium, señaló que este fallo se resuelve con un cambio de código y una actualización de BIOS o UEFI, sin necesidad de revocar certificados ni claves, a diferencia de BootHole o BlackLotus.
La divulgación se adelantó a lo previsto. Los investigadores Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, habían coordinado la publicación para enero de 2027, pero 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 en septiembre. TianoCore publicó su aviso en octubre y, con el parche ya visible, cualquier atacante avanzado puede estudiar cómo se dispara el error. Matrosov advirtió además que la investigación asistida por inteligencia artificial está acortando los embargos, porque cada vez más equipos usan herramientas parecidas para buscar vulnerabilidades. Hasta finales de octubre no constaba explotación activa ni entrada en el catálogo de CISA.
Este episodio se suma a otros avisos sobre UEFI, como PixieFail en 2024, y recuerda que los fallos en la fase previa al sistema operativo son atractivos porque quedan por debajo de muchas herramientas de defensa. No es necesario revocar certificados ni cambiar el gestor de arranque, pero sí revisar la configuración de red y las versiones de firmware. La combinación de código compartido, actualizaciones lentas y despliegues masivos hace que un fallo grave en EDK II pueda seguir presente en equipos mucho después de que haya dejado de ocupar titulares.
Medidas prácticas para entornos españoles y europeos
Para una organización española o europea, el primer paso es comprobar si sus servidores arrancan por PXE y si ese uso responde a una necesidad real. Si no hace falta, conviene desactivarlo, incluida la revisión de máquinas virtuales con firmware EDK II. Después toca abrir un ticket al fabricante o proveedor de hosting para pedir el cronograma de BIOS o UEFI corregido; si no hay respuesta, esa falta de información también debe tratarse como un indicador de exposición.
La segmentación de la red de gestión y de la VLAN de arranque limita quién puede enviar tráfico a un equipo que está iniciando. Mantener TPM y Secure Boot activos sigue siendo recomendable, aunque no detiene este ataque por sí solo, porque el código se ejecuta antes de que esas protecciones puedan verificar nada. También resulta útil incluir el firmware en la política de actualizaciones, con un inventario de modelo, fabricante y versión de BIOS, y vigilar registros o comportamientos anómalos en la fase de arranque.
La vulnerabilidad CVE-2026-97631 es un fallo serio en un punto especialmente sensible del arranque, pero su impacto práctico está condicionado por el uso de PXE, la configuración del firmware y la posición del atacante en la red. La corrección existe en el código fuente, aunque todavía debe llegar a versiones estables, distribuidores y equipos finales. Quien administra infraestructura necesita saber dos cosas concretas: si sus máquinas arrancan por red y cuándo publicará su fabricante una actualización de BIOS o UEFI; mientras tanto, reducir la superficie expuesta es la medida más sensata.
