Un único mensaje ICMP de error de más de 504 bytes basta para escribir fuera de un búfer del firmware UEFI de un servidor que arranca por red. El fallo, CVE-2026-97631, está en TianoCore EDK II, el código abierto de firmware UEFI que mantiene TianoCore y del que parten derivados como el de Microsoft o el de XCP-ng, y su aviso oficial lo puntúa con un 9,5 sobre 10 en CVSS v4. El arreglo es público desde el 14 de octubre de 2026, pero ninguna versión estable de EDK II lo incluye todavía.
Qué falla exactamente
El driver PXE de EDK II (NetworkPkg/UefiPxeBcDxe) deja abierta una recepción para los mensajes ICMP de error mientras la máquina arranca por red, y copia cada uno en un campo fijo de 504 bytes, Mode.IcmpError. Según el aviso de seguridad publicado el 22 de octubre, las funciones que lo hacen para IPv4 (PxeBcIcmpErrorDpcHandle) y para IPv6 (PxeBcIcmp6ErrorDpcHandle) calculan mal los límites: con un mensaje más largo siguen copiando y, además, avanzan el puntero de destino por la longitud acumulada en vez de por la de cada fragmento. Nada antes en la ruta de recepción limita el tamaño del mensaje.
El aviso describe dos consecuencias:
- Denegación de servicio determinista: los datos privados del driver quedan corrompidos y el siguiente error ICMP provoca una excepción en el núcleo DXE que cuelga el arranque.
- Ejecución de código: si el atacante conoce la build concreta del firmware, puede colar en el mismo paquete un evento falso para que
CoreSignalEvent()ejecute sus bytes en la fase DXE. Es decir, antes de que cargue el sistema operativo y, por tanto, fuera del alcance de cualquier agente de seguridad instalado en él.
Quién está expuesto
Las condiciones son concretas: la máquina tiene que estar arrancando por PXE, sobre IPv4 o IPv6, y el atacante tiene que hacerle llegar un ICMP de error unicast dirigido a su IP. El aviso subraya que puede hacerlo "desde cualquier distancia de red", no solo desde el mismo segmento. La ventana dura lo que dura el arranque PXE, así que el riesgo se concentra en flotas bare metal que se aprovisionan o reinstalan por red y en hipervisores que dan firmware UEFI con arranque de red a sus VMs. Un servidor que arranca de disco no abre esa ventana.
La versión afectada que cita el aviso es "EDK II master a 14 de septiembre de 2026" y en el apartado de versiones corregidas pone "Not patched currently". Lo que no dice el aviso es qué fabricantes de servidores llevan este código en su firmware; eso depende de cada uno.
Un parche público antes que el aviso
La cronología es lo que hace urgente este CVE. El arreglo, el PR #13302, se abrió en abierto el 14 de octubre y se integró en master el 15 de octubre (commit fa78907). En el propio hilo, un responsable del proyecto reconoce que el embargo "se rompió por un error" y que por eso el PR se creó en público. El aviso oficial llegó una semana después, el 22 de octubre, con crédito para Alex Matrosov (Anthropic) y Dan Holmes-Mitra (Google).
Desde entonces cualquiera puede leer el diff para entender cómo se dispara el fallo, mientras la última versión estable, edk2-stable202608, es del 21 de agosto y no lo lleva. Los derivados ya se están moviendo: Microsoft integró el backport en su rama release/202511 de mu_basecore el 23 de octubre, y XCP-ng lo integró en la rama 8.3 de su paquete edk2 el 28 de octubre, de momento solo compilado y sin pasar su batería de pruebas.
Qué haría yo esta semana
- Inventariar qué arranca por red: servidores que se aprovisionan o reinstalan por PXE y VMs UEFI con arranque de red. Eso es la superficie real, no "todos los servidores".
- Quitar el arranque de red donde no haga falta: si la máquina ya está instalada y arranca de disco, sacar PXE del orden de arranque cierra la ventana sin esperar a nadie.
- Filtrar los ICMP de error que entran en la red de aprovisionamiento desde fuera de ella. Como el ataque puede llegar desde cualquier distancia, el borde de ese segmento es el sitio natural. En IPv6, cuidado con no romper el descubrimiento de MTU del resto de tráfico.
- Pedir el firmware al fabricante citando CVE-2026-97631, y si compilas tu propio firmware desde EDK II, aplicar el commit
fa78907en vez de esperar a la próxima versión estable.
La cautela que importa: el 9,5 del aviso asume un atacante que puede alcanzar la máquina mientras arranca por red y, para ejecutar código, que conoce su build de firmware. No es un gusano de Internet, pero con el parche publicado desde el 14 de octubre, construir el exploit es cuestión de leer el diff.
Fuentes
- Pre-boot RCE in EDK II PXE driver (CVE-2026-97631), TianoCore EDK II
- NetworkPkg/UefiPxeBcDxe: Fix ICMP buffer overflow in IPv4/IPv6 handle (CVE-2026-97631), TianoCore EDK II
- EDK II releases (edk2-stable202608), TianoCore EDK II
- Backport CVE-2026-97631 from edk2, Microsoft mu_basecore
- Add fixes for CVE-2024-38797 and CVE-2026-97631, XCP-ng