Introducción
Acaba de revelarse una vulnerabilidad crítica con puntuación 9,5 sobre 10 en el CVSS v4 en EDK II, la base de código de referencia sobre la que prácticamente todos los fabricantes de servidores construyen su firmware UEFI. La particularidad de CVE-2026-97631: la explotación se produce antes de que el sistema operativo comience a cargar, dejando inoperativas las protecciones habituales como Secure Boot y TPM.
Un desbordamiento de búfer en el controlador PXE
El arranque por red (PXE) es una funcionalidad central en las grandes infraestructuras de TI: permite aprovisionar servidores en masa desde un servidor central, sin intervención física en cada máquina. Es precisamente en este flujo donde reside la vulnerabilidad.
El controlador afectado —UefiPxeBcDxe en el paquete NetworkPkg de EDK II— copia los mensajes de error ICMP recibidos durante el arranque de red en un búfer de tamaño fijo de 504 bytes. El problema: los gestores IPv4 e IPv6 calculan incorrectamente el límite de copia. Un mensaje ICMP sobredimensionado sobrescribe datos adyacentes en memoria. Un atacante posicionado en la red local puede enviar una trama especialmente diseñada para desencadenar uno de dos escenarios: un bloqueo inmediato que interrumpe el arranque o —más grave— la ejecución de código arbitrario al nivel de privilegio más alto del sistema, antes de que se cargue cualquier componente de software. La explotación no requiere autenticación ni interacción del usuario.
Antes de Secure Boot, antes del TPM
Este detalle lo cambia todo. Tecnologías como Secure Boot o la medición de integridad mediante TPM actúan después del firmware: no pueden hacer nada contra una amenaza que se instala en la propia secuencia de arranque. Un atacante que explote CVE-2026-97631 puede teóricamente implantar código persistente que las capas de software superiores nunca detectarán. La ventana de exposición abarca la totalidad de la duración del arranque PXE —lo que, en un centro de datos que aprovisiona máquinas de forma continua, representa una superficie de ataque permanente.
El verdadero problema: el retraso entre el parche y el firmware
El código fuente de EDK II fue corregido el 15 de octubre de 2026 mediante la pull request #13302 en el repositorio TianoCore, con verificaciones de límites reforzadas y una corrección de la aritmética de punteros en ambos gestores. Sin embargo, este parche en el código de referencia no se traduce automáticamente en protección para las organizaciones.
Cada fabricante —Dell, HP, Lenovo, Supermicro, y los proveedores de capas de firmware como AMI, Insyde o Phoenix— debe integrar el parche en su propia cadena de compilación de firmware, validarlo sobre sus plataformas de hardware y distribuirlo a través de sus canales de actualización de BIOS. Dell ya ha publicado un aviso de seguridad específico e iniciado actualizaciones para varias gamas. Otros fabricantes seguirán. Pero entre el momento en que la corrección existe en el código de referencia y aquel en que está disponible en el firmware de un servidor en producción, los plazos se miden en semanas, a veces en meses según los modelos y generaciones de hardware.
Lo que los equipos de TI deben hacer ahora
Mientras esperan el firmware corregido de su fabricante, las organizaciones pueden reducir su exposición desde hoy mismo:
- Deshabilitar el arranque PXE en el BIOS/UEFI de todos los servidores que no lo requieran operativamente.
- Aislar el tráfico de arranque por red en una VLAN dedicada, inaccesible desde el resto de la red corporativa.
- Monitorizar los avisos de los fabricantes e implementar un seguimiento activo de CVE de firmware —habitualmente ausente en las políticas de gestión de parches tradicionales, que se detienen en el nivel del sistema operativo.
- Priorizar las actualizaciones de BIOS en cuanto estén disponibles para los modelos afectados, con el mismo nivel de urgencia que un parche crítico de sistema operativo.
CVE-2026-97631 ilustra una brecha estructural en la gestión del riesgo de TI: el firmware se trata con demasiada frecuencia como un componente estable, excluido del perímetro de gestión de parches. Sin embargo, sigue siendo software —y como todo software, puede albergar vulnerabilidades críticas. La seguridad de un servidor comienza antes que su sistema operativo.