Un bug de 16 años en el corazón del firmware UEFI de servidores de todo el mundo ha sido descubierto y clasificado con la máxima severidad: 9,5 de 10. La falla, identificada como CVE-2026-97631, reside en el controlador PXE Base Code (NetworkPkg/UefiPxeBcDxe) de TianoCore EDK II — la referencia open-source que alimenta prácticamente todo el firmware UEFI de servidores fabricado por AMI, Insyde, Phoenix y otros grandes proveedores.
Lo que hace esta falla particularmente peligrosa es dónde se ejecuta. La explotación ocurre durante el PXE boot — el proceso de inicialización por red —, antes de que el sistema operativo cargue y antes de que mecanismos como Secure Boot o measured boot hayan verificado cualquier componente. El código malicioso corre en ring 0, el nivel más privilegiado de la CPU, con acceso directo al TPM y a todos los componentes sensibles del sistema.
La mecánica de la vulnerabilidad es elegante en su simplicidad. Durante el PXE boot, el controlador mantiene un puerto de recepción abierto para mensajes de error ICMP. El código copia cada mensaje recibido a un campo fijo de 504 bytes (Mode.IcmpError) sin validación de tamaño. Un atacante autenticado en la misma red puede enviar mensajes ICMP con más de 504 bytes, corrompiendo la memoria DXE-phase y ejecutando código arbitrario. No necesita credenciales, no necesita interacción del usuario — basta alcanzar la máquina por la red durante la ventana de arranque.
El descubrimiento fue acreditado a Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google. El parche fue fusionado al EDK II master el 15 de octubre de 2026 (PR #13302), pero la etiqueta estable más reciente, edk2-stable202608 de 21 de agosto, aún no incluye la corrección. El advisory del TianoCore lista el estado como "Not patched currently".
El impacto es amplio pero no universal. La mayoría de los servidores modernos usan EDK II con PXE network boot para aprovisionamiento de data centers. Sin embargo, las máquinas que arrancan exclusivamente desde disco local — como la mayoría de los portátiles personales y escritorios — no se ven afectadas. Esta distinción importa: los data centers que dependen del arranque por red para aprovisionamiento, mantenimiento o redimensionar infraestructura están en la línea de fuego.
La ausencia de persistence en los payloads finales es a la vez un alivio y una fuente de preocupación. El exploit corre una única vez y muere — pero esta puerta inicial abre la puerta para instalar bootkits persistentes que sobreviven a reinstalaciones del sistema operativo. El firmware UEFI vive en el chip físico de la placa madre, inalcanzable por herramientas de software convencionales. Una vez comprometido, el firmware puede reinyectar cualquier malware en el próximo arranque, independientemente de los cambios en el disco.
La mitigación inmediata es simple pero impactante: desactivar PXE/network boot donde no sea esencial. Para administradores que dependen de esta funcionalidad para aprovisionamiento, la espera por parches de firmware de los proveedores es el único camino. Debian ya rastreó el CVE en su security tracker, pero esto es clasificación, no corrección.
La pregunta que queda es si la arquitectura del EDK II — 16 años sin revisión de seguridad formal — refleja un problema sistémico del ecosistema de firmware. Con la computación migrando a edge, IoT y sistemas embebidos que corren UEFI, esta es la misma arquitectura que protege los data centers mientras también los expone. El próximo vulnerability de pre-boot probablemente no va a esperar 16 años para aparecer.
Fuentes: pwn.watch, GitHub Advisory — TianoCore EDK II, Debian Security Tracker
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
