Vulnerabilidad crítica en EDK II permite ejecución de código antes de que cargue el sistema operativo
Se ha descubierto una vulnerabilidad de gravedad crítica en EDK II (EFI Development Kit 2), el entorno de desarrollo de firmware más utilizado en el mundo para plataformas UEFI. Rastreada como CVE-2026-97631 y clasificada con 9,5 de 10 en la escala CVSS 4.0 — casi la puntuación máxima posible —, la falla reside en el controlador PXE Base Code (NetworkPkg/UefiPxeBcDxe) y puede permitir que un atacante no autenticado ejecute código arbitrario durante la fase previa al arranque, antes de que Secure Boot o measured boot hayan verificado cualquier componente del sistema operativo.
Cómo funciona la vulnerabilidad
El problema está en los manejadores de error ICMP (Internet Control Message Protocol) tanto del controlador IPv4 como del IPv6 del controlador de arranque de red. Durante el arranque de red, el controlador mantiene una solicitud de recepción abierta para mensajes de error ICMP y copia cada mensaje recibido en un campo fijo de 504 bytes llamado `Mode.IcmpError` en su estructura de contexto privada.
El bucle de cópia tiene un defecto de manejo de límites tanto en los controladores IPv4 como IPv6: para mensajes con más de 504 bytes, el código sigue copiando bytes más allá del campo, avanzando el puntero de destino por la longitud acumulativa en lugar de la longitud por fragmento. Nada en el camino de recepción anterior restringe el tamaño del mensaje. Esto configura un desbordamiento de búfer clásico (CWE-120) combinado con cálculo incorrecto del tamaño del búfer (CWE-131) y escritura fuera de los límites (CWE-787).
El resultado es doble: una corrupción determinística de los datos privados del controlador, causando una excepción de CPU dentro del core DXE en el próximo error ICMP (bloqueo del arranque, denegación de servicio), y la posibilidad, para un atacante que conoce la configuración de firmware del objetivo, de inyectar un evento falso en el mismo paquete y hacer que `CoreSignalEvent()` despache bytes controlados por el atacante en la fase DXE — anillo 0, antes de que exista cualquier control de seguridad del sistema operativo.
Quiénes están afectados
EDK II es mantenido por la fundación TianoCore y es la implementación de referencia de facto para la especificación UEFI. Los fabricantes incluyen American Megatrends (AMI), Intel, Insyde Software, Phoenix Technologies y Microsoft. Las máquinas que usan EDK II y arrancan de red vía PXE — y, crucialmente, están configuradas para usar IPv6 — son todas vulnerables a la explotación.
Intel le dijo a Ars Technica que no conoce productos comerciales actualmente bajo soporte de seguridad que se vean afectados, pero señaló que los OEM o los fabricantes de sistemas podrían integrar la funcionalidad vulnerable.
El alcance exacto de los productos afectados permanece incierto, y varias empresas contactadas por Ars Technica no respondieron en la publicación. Los sistemas que arrancan exclusivamente desde disco no se ven afectados — la exposición requiere acceso a la red relevante durante la secuencia de arranque PXE.
Descubrimiento y parche
La vulnerabilidad fue descubierta por Alex Matrosov de Anthropic y Dan Holmes-Mitra de Google, quienes también proporcionaron la corrección recomendada. La revelación llegó antes de lo previsto después de que el fabricante de placa base AMI publicara un pull request con los detalles de la corrección — lo cual, irónicamente, facilita el trabajo de atacantes avanzados que deseen aprender cómo se activa la vulnerabilidad.
El pull request (#13302) añade lógica de validación de tamaño antes de la cópia e incluye pruebas unitarias para las condiciones que la corrección resuelve. La versión afectada de EDK II es la master a partir de 2026-09-14. La versión estable más recente, `edk2-stable202608` (21 de agosto de 2026), también fue listada como afectada.
Qué observar
Con el código de parche disponible públicamente, será trivial para hackers avanzados aprender cómo se activa la vulnerabilidad y construir exploits funcionales. La ventana de exposición es la duración del arranque PXE — lo que significa que el riesgo se concentra en momentos específicos, pero la superficie de ataque es amplia en entornos de datacenter donde el arranque de red es parte del flujo normal de aprovisionamiento.
Lo que hace esta vulnerabilidad particularmente peligrosa es que opera a un nivel por debajo de cualquier protección del sistema operativo. Un exploit exitoso comprometería toda la plataforma, incluyendo la capacidad de modificar o implantar malware que sobreviva reinstalaciones del sistema operativo. La analogía con el caso BlackLotus — el primer bootkit UEFI públicamente documentado que derrotó a Secure Boot en una máquina Windows 11 de fábrica — ilustra el tipo de escenario que los administradores de infraestructura desean evitar.
La pregunta es si la comunidad de firmware de código abierto, que ha trabajado diligentemente con el proceso de divulgación coordinada, podrá producir parches para distribución OEM a tiempo, o si cientos de miles de servidores permanecerán en riesgo hasta que las actualizaciones de firmware lleguen a los datacenters.
Fuentes: TianoCore EDK II Security Advisory, Linxi News, CVE Record
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
