La vulnerabilidad crítica de desbordamiento de búfer CVE-2026-97631 en el controlador PXE de EDK II, el código abierto en el que se basa el firmware UEFI de la mayoría de las plataformas de servidor y cliente, permite a un atacante no autenticado ejecutar código arbitrario antes de la carga del sistema operativo y antes de la activación de Secure Boot. La vulnerabilidad afecta a sistemas que utilizan arranque de red PXE y está valorada en 9.5 puntos según CVSS v4 (Critical). El fallo se ha corregido en el código fuente de EDK II, pero ninguna versión estable lo incluye por ahora, por lo que se recomienda a los operadores de infraestructuras de servidor con arranque PXE desactivar el arranque por red hasta que se publiquen actualizaciones de firmware.
Detalles técnicos de la vulnerabilidad
La vulnerabilidad se clasifica como escritura fuera de los límites del búfer asignado (CWE-787, out-of-bounds write) en el componente NetworkPkg/UefiPxeBcDxe, el controlador PXE de EDK II. PXE (Preboot Execution Environment) es un mecanismo de arranque de máquinas por red, ampliamente utilizado en centros de datos para el despliegue y la recuperación de servidores.
Durante el arranque PXE, el controlador procesa mensajes ICMP de error entrantes, copiando su contenido a un área de memoria fija de 504 bytes. Las comprobaciones de límites en esta operación de copia están implementadas de forma incorrecta tanto para IPv4 como para IPv6. El envío de un paquete ICMP especialmente diseñado que exceda los 504 bytes provoca la sobrescritura de áreas de memoria adyacentes con datos controlados por el atacante.
La explotación no requiere contraseña ni acceso previo al sistema: basta con poder enviar un paquete de red a la dirección de la máquina en el momento del arranque PXE. Al mismo tiempo, según los datos del registro CVE, Red Hat y SUSE clasifican el vector de ataque como accesible desde un segmento de red adyacente y no desde Internet abierta.
El resultado garantizado de la explotación es el fallo de arranque (denial of service). La ejecución de código arbitrario es significativamente más compleja: requiere conocer la compilación concreta del firmware del sistema objetivo y crear un exploit adaptado a ella. Un exploit universal para un ataque masivo es poco probable precisamente por esta dependencia de la configuración.
Cabe destacar la discrepancia en las valoraciones de severidad entre distintas fuentes: TianoCore asigna 9.5 según CVSS v4, mientras que SUSE valora la vulnerabilidad en 8.8 según CVSS v3 (Important). No se trata de una contradicción: la diferencia se debe a las distintas versiones de la metodología CVSS; SUSE también muestra la puntuación CNA de 9.5 según CVSS v4.
Alcance de los sistemas afectados
El código vulnerable está presente en EDK II desde el commit de noviembre de 2010, es decir, existe desde hace unos 16 años. Se ven afectadas todas las versiones de EDK II hasta edk2-stable202608 (del 21 de agosto de 2026).
EDK II es una base de código de referencia que utilizan los mayores proveedores de firmware UEFI (AMI, Insyde, Phoenix), así como Microsoft en el proyecto Project Mu. Sin embargo, el uso generalizado de EDK II en el ecosistema no significa que todos los servidores sean vulnerables. La exposición práctica viene determinada por la intersección de tres condiciones:
- El controlador PXE de EDK II está presente en el firmware del sistema;
- el sistema realiza activamente el arranque por red en el momento del ataque;
- el atacante puede hacer llegar tráfico ICMP a la dirección de la máquina en ese momento.
Los ordenadores domésticos y de oficina que arrancan desde un disco local no se ven afectados. El principal grupo de riesgo lo constituyen los servidores y equipos de centros de datos que utilizan PXE para el despliegue.
Entre las distribuciones Linux: Red Hat indica que los paquetes edk2 en RHEL 8, 9 y 10 están afectados y aún sin corregir; Debian registra la vulnerabilidad en los paquetes de bookworm, trixie, forky y sid. Anteriormente ya escribimos sobre vulnerabilidades en el ecosistema de Red Hat, y este caso vuelve a subrayar el alcance de la dependencia de las distribuciones Linux corporativas de componentes comunes.
Según Ars Technica, Intel declaró que ninguno de sus productos comerciales que aún cuentan con soporte se ve afectado, aunque los fabricantes OEM pueden integrar el componente vulnerable por su cuenta. Arm comunicó que la vulnerabilidad no es aplicable a su cartera de productos. El estado de los productos de AMD, Phoenix Technologies, AMI, Microsoft y Amazon sigue siendo desconocido en el momento de la publicación.
Estado del parche e historial de divulgación
La corrección se incorporó a la rama principal de EDK II el 15 de octubre de 2026. El parche reescribe la operación de copia de modo que los paquetes que superen los 504 bytes se trunquen en lugar de escribirse más allá de los límites del búfer. Sin embargo, ninguna versión estable de EDK II incluye todavía este parche: la última versión, edk2-stable202608, está fechada el 21 de agosto, y en el aviso de seguridad de TianoCore la versión corregida sigue apareciendo como inexistente. Según Ars Technica, Microsoft Project Mu ya integró la corrección en sus ramas de publicación el 26 de octubre.
La vulnerabilidad fue descubierta por Alex Matrosov (Anthropic) y Dan Holmes-Mitra (Google). La divulgación coordinada estaba prevista para enero de 2027, pero el 28 de septiembre un pull request de un ingeniero de AMI describió públicamente la vulnerabilidad indicando el número CVE e incluía la corrección. Tras ello, TianoCore publicó el aviso de seguridad el 22 de octubre, varias semanas antes de la fecha prevista. La naturaleza pública del parche significa que atacantes cualificados pueden estudiarlo para crear exploits.
Por el momento no se han detectado indicios de explotación activa. La vulnerabilidad no se ha incluido en el catálogo CISA KEV.
Recomendaciones
La prioridad clave no es esperar actualizaciones de paquetes del sistema operativo, sino supervisar la publicación de actualizaciones de firmware por parte del fabricante del equipo, ya que es el proveedor de firmware quien debe lanzar una actualización de BIOS/UEFI basada en el código EDK II corregido. Hasta que aparezca dicha actualización:
- Desactive el arranque PXE en todos los sistemas en los que el arranque por red no sea necesario para los procesos de trabajo;
- Controle el tráfico de red en los segmentos donde se utiliza el arranque PXE, prestando atención a paquetes ICMP anómalos en el momento del arranque de los servidores;
- Póngase en contacto con el fabricante del equipo servidor o de la placa base para aclarar el estado de exposición y los plazos de publicación de la actualización de firmware;
- Limite el acceso de red a los segmentos con arranque PXE, minimizando la posibilidad de envío de tráfico arbitrario desde redes adyacentes.
Un punto práctico importante: a diferencia de vulnerabilidades de evasión de Secure Boot como BootHole y BlackLotus, CVE-2026-97631 se corrige mediante una actualización normal de código y no requiere la revocación de certificados o claves, lo que simplifica el proceso de aplicación de parches una vez que se publiquen las actualizaciones.
Las organizaciones que operan infraestructuras de servidor con arranque PXE deberían realizar ya un inventario de los sistemas con cargador de red activo, desactivar PXE allí donde no sea crítico y registrar una solicitud al proveedor de firmware: aún no existe una versión estable de EDK II con la corrección, y los plazos de su incorporación a productos concretos dependen de cada fabricante individualmente.
