JC Rueda
Ciberseguridad · Aviso

TianoCore EDK II (firmware UEFI, controlador PXE) · Ejecución de código previa al arranque por arranque en red

Un desbordamiento de búfer en el controlador de arranque por red de EDK II, el código de referencia con el que se fabrica buena parte del firmware UEFI del mundo, permite ejecutar código antes del sistema operativo y de Secure Boot. El fallo se hizo público antes de tiempo por un error en la divulgación coordinada.

Publicado Lectura 10 min Ref. CVE-2026-97631 CVSS 9.5 (CNA (TianoCore, aviso GHSA-99cj-7hg9-mp4m), CVSS v4.0. Red Hat asigna una puntuación preliminar CVSS v3.1 de 8,8 (AV:A, red adyacente). NVD no ha hecho su propio análisis (estado «Deferred»).)

Resumen

TianoCore publicó el 22 de octubre de 2026 el aviso GHSA-99cj-7hg9-mp4m (CVE-2026-97631, CVSS v4.0 9,5 según la CNA). Describe un desbordamiento de búfer en el controlador PXE de EDK II: mientras un equipo arranca por red, un mensaje ICMP de error manipulado puede bloquear el arranque o, si el atacante conoce la versión exacta del firmware, ejecutar código con el máximo privilegio antes de que se cargue el sistema operativo. La corrección se incorporó al repositorio el 15 de octubre, pero todavía no hay versión estable de EDK II que la incluya ni consta ningún firmware corregido de los grandes fabricantes. Solo están expuestos los equipos que arrancan por red, y no hay constancia de explotación activa.

Materias: Vulnerabilidades, Firmware y UEFI, Seguridad de servidores y centros de datos, Divulgación coordinada, Gestión de parches

Antes de que arranque Windows o Linux, todo ordenador ejecuta un pequeño programa grabado en la placa base: el firmware UEFI. Una parte muy grande del firmware UEFI del mundo se construye a partir de un mismo proyecto de código abierto, EDK II (TianoCore). En ese código se ha encontrado un fallo que permite a un atacante con acceso a la red tomar el control de un servidor mientras arranca por red, antes de que se active ninguna defensa. Es grave, pero tiene límites: solo afecta al arranque por red y no consta que se esté explotando. Además, la noticia ha salido a la luz antes de lo previsto.

Descripción

Qué es

El fallo es CVE-2026-97631 (aviso GHSA-99cj-7hg9-mp4m, titulado «Pre-boot RCE in EDK II PXE driver»). Es una corrupción de memoria en el controlador PXE Base Code de EDK II (NetworkPkg/UefiPxeBcDxe).

Algunos términos:

  • UEFI: estándar del firmware que inicializa el hardware y carga el sistema operativo. Ha sustituido a la antigua BIOS.
  • EDK II: implementación de referencia, de código abierto, de la especificación UEFI. Los fabricantes de firmware (los llamados IBV, como AMI, Insyde o Phoenix), los fabricantes de servidores y los proveedores cloud la usan como base. También es la base de OVMF, el firmware de muchas máquinas virtuales en KVM/QEMU.
  • PXE (Preboot eXecution Environment): mecanismo para que un equipo arranque descargando su sistema por la red local en lugar de leerlo del disco. Es habitual en centros de datos y en despliegues masivos de equipos.
  • ICMP: protocolo de mensajes de control y error de las redes IP. Es el de «ping» y el de los avisos del tipo «destino inalcanzable».

Clasificación

  • CVSS v4.0: 9,5 (crítica), asignada por la CNA (TianoCore). Vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. En palabras: ataque por red, sin autenticación ni intervención del usuario, con impacto alto, pero con «requisitos de ataque presentes» (AT:P), es decir, solo funciona en determinadas condiciones.
  • Red Hat da una puntuación preliminar distinta: CVSS v3.1 8,8, con vector de «red adyacente» (AV:A). Considera, por tanto, que el atacante tiene que estar en la misma red local.
  • Debilidades (CWE): CWE-120 (copia a un búfer sin comprobar el tamaño), CWE-131 (cálculo incorrecto del tamaño del búfer) y CWE-787 (escritura fuera de límites).
  • NVD no ha hecho su propia evaluación (estado «Deferred»). El fallo no figura en el catálogo CISA KEV.

A quién y a qué versiones afecta

  • EDK II: según el registro del CVE, todas las versiones hasta edk2-stable202608 incluida. El aviso indica como afectada la rama principal (master) a fecha de 14 de septiembre de 2026. Ars Technica dice que el código vulnerable tiene unos 16 años. No hemos podido comprobar ese dato con fuentes primarias.
  • Firmware de terceros basado en EDK II que incluya y tenga activado el arranque PXE. Que un firmware concreto esté afectado depende de cada fabricante, y la mayoría no se ha pronunciado todavía.
  • Red Hat marca como afectado su paquete edk2 en Red Hat Enterprise Linux 8, 9 y 10 y en OpenShift Container Platform 4. Esto apunta a máquinas virtuales con firmware OVMF que arranquen por red.

No afecta a los equipos que arrancan solo desde disco, que es el caso de casi todos los ordenadores domésticos y de pequeña oficina. Tampoco a los firmwares que no usen el controlador PXE de EDK II. El titular de que afecta a «la mayoría de servidores del planeta» se refiere a lo extendido que está el código, no a que todos esos servidores sean atacables en la práctica.

Mecánica

El fallo

Durante el arranque por red, el controlador PXE deja abierta una «escucha» para recibir mensajes ICMP de error y copia cada uno en un campo de memoria de tamaño fijo: 504 bytes (Mode.IcmpError). Según el aviso oficial, el control de límites de esa copia está mal hecho en los dos manejadores, el de IPv4 (PxeBcIcmpErrorDpcHandle) y el de IPv6 (PxeBcIcmp6ErrorDpcHandle):

  • si el mensaje mide más de 504 bytes, la copia continúa igualmente;
  • el puntero de destino avanza según la longitud acumulada y no según la de cada fragmento, así que los datos acaban escritos más allá del campo;
  • ningún paso anterior de la recepción limita el tamaño del mensaje.

El resultado es un desbordamiento de búfer: el atacante puede sobrescribir con datos propios la memoria contigua del controlador.

Qué puede conseguir el atacante

  1. Denegación de servicio (impedir que el equipo funcione): según el aviso, la corrupción es determinista y en el siguiente mensaje ICMP de error provoca una excepción de la CPU que cuelga el arranque.
  2. Ejecución de código: si el atacante conoce la compilación exacta del firmware de la víctima, puede colocar en el mismo paquete un «evento falsificado». El núcleo DXE (la fase del firmware que carga los controladores) lo ejecuta mediante CoreSignalEvent(). El código del atacante corre entonces en ring 0, el nivel de privilegio más alto de la CPU, antes de que actúen Secure Boot (la verificación de firmas del arranque) o el arranque medido con TPM.

Requisitos y límites

  • El equipo tiene que estar arrancando por PXE. La exposición dura solo mientras dura ese arranque, normalmente unos segundos.
  • El atacante tiene que hacer llegar un mensaje ICMP de error a la IP del equipo. El aviso dice que basta un paquete unicast «desde cualquier distancia de red». En la práctica, cortafuegos, balanceadores y la segmentación de red lo dificultan mucho. Por eso Red Hat lo califica como ataque de red adyacente, y los expertos consultados por Ars Technica (HD Moore, de Dragos) hablan de un atacante interno o que ya ha entrado en la red local.
  • Para ejecutar código hay que adaptar el exploit a cada modelo, versión y configuración, porque las direcciones de memoria cambian. Así lo explica Jesse Michael, de Eclypsium, a Ars Technica: no sirve un único exploit para todos los equipos.
  • Según Ars Technica, el código inyectado no persiste por sí solo tras reiniciar, aunque podría usarse para instalar otros componentes maliciosos que sí persistan. HD Moore apunta que, en ese momento del arranque, el atacante podría acceder al TPM y comprometer el cifrado de disco. No consta que nada de esto se haya visto en ataques reales.

El fallo recuerda a PixieFail (2024), un conjunto de vulnerabilidades en la misma pila de red de EDK II (NetworkPkg).

Respuesta del creador

Una divulgación que se adelantó

El aviso atribuye el descubrimiento a Alex Matrosov (Anthropic) y Dan Holmes-Mitra (Google). Según Ars Technica, la publicación coordinada estaba prevista para enero de 2027. Sin embargo, el repositorio público muestra esta secuencia:

  • 28 de septiembre de 2026: un desarrollador vinculado a AMI abre en GitHub, en público, el pull request (propuesta de cambio de código) #13200, con la corrección y el número de CVE en el título.
  • 14 de octubre: Michael D. Kinney, mantenedor de EDK II, lo sustituye por el #13302, que añade las mejoras pedidas en la revisión y pruebas unitarias.
  • 15 de octubre: se integra el #13302 en la rama principal (commit fa789071ff0b29f1e568bfe153ef7f3d76bd60e4).
  • 22 de octubre: TianoCore publica el aviso GHSA-99cj-7hg9-mp4m y el CVE.

En ese mismo pull request, un colaborador del proyecto reconoce que el embargo (el periodo de confidencialidad pactado) se rompió «por error» y que eso «debería evitarse». Insiste en que los avisos privados de GitHub siguen siendo el canal correcto para notificar fallos, aunque admite que hay retraso en su tramitación. Por su parte, otro participante se había quejado de que sus notificaciones privadas llevaban meses sin respuesta, mientras que las correcciones públicas avanzaban más rápido.

Fabricantes

  • Intel (a Ars Technica): ninguno de sus productos comerciales con soporte de seguridad está afectado, según lo que sabe. Su código de referencia no incluye la función vulnerable, pero un fabricante de placas o de sistemas podría haberla integrado. Recomienda consultar al fabricante del equipo.
  • Arm (a Ars Technica): el CVE «no es directamente aplicable» a su catálogo de productos.
  • Red Hat marca como afectados sus paquetes edk2 (RHEL 8, 9 y 10, y OpenShift 4) y sigue el caso en su Bugzilla. No hemos encontrado ningún paquete corregido publicado.
  • AMI, AMD, Phoenix, Microsoft (Project Mu) y Amazon no respondieron a Ars Technica. No hemos encontrado avisos propios de AMI, Insyde ni Phoenix en el momento de redactar esta nota.

Autoridades

El fallo no está en el catálogo de vulnerabilidades explotadas de CISA (KEV). No hemos encontrado aviso específico de INCIBE-CERT ni de CERT/CC sobre este CVE. No hay constancia pública de explotación activa. El EPSS (estimación estadística de la probabilidad de explotación) está por debajo del 1 %.

Parches y mitigaciones

Estado de los parches

  • Código fuente (EDK II): corregido en la rama principal desde el 15 de octubre de 2026 (PR #13302). La corrección limita la copia al tamaño del campo, corrige el cálculo de los desplazamientos, recorta los mensajes demasiado grandes y pone a cero el búfer antes de copiar. Viene con pruebas unitarias.
  • Versión estable: la última publicada, edk2-stable202608 (agosto de 2026), sigue siendo vulnerable. El aviso no da ninguna versión estable corregida. Lo previsible es que la próxima versión estable incluya la corrección, pero no consta fecha.
  • Firmware de los equipos: es lo que de verdad importa al usuario, y por ahora no consta ninguna actualización de BIOS/UEFI publicada por los fabricantes de servidores ni por los IBV para este CVE. Cada fabricante tiene que incorporar el cambio a su firmware y distribuirlo.
  • Virtualización: hay que estar atentos a las actualizaciones de los paquetes edk2/ovmf de cada distribución (Red Hat lo tiene en seguimiento).

Una buena noticia, según Eclypsium: a diferencia de BootHole o BlackLotus, este fallo se arregla con una actualización normal de firmware. No obliga a revocar certificados de Secure Boot ni a actualizar listas de claves (db/dbx).

Qué hacer ya

  1. Inventario: identificar qué servidores, equipos y máquinas virtuales arrancan por red (PXE) y qué firmware llevan.
  2. Desactivar el arranque PXE en la configuración del firmware o del hipervisor allí donde no sea imprescindible, o quitarlo del orden de arranque. El aviso no propone ninguna mitigación oficial, pero sin arranque PXE el código vulnerable no se ejecuta.
  3. Segmentar la red de aprovisionamiento PXE: una red dedicada y aislada, con filtrado de ICMP entrante hacia los equipos mientras arrancan.
  4. Preguntar al fabricante del servidor o del firmware (Dell, HPE, Lenovo, Supermicro, AMI, Insyde, Phoenix, el proveedor cloud…) si su firmware está afectado y cuándo saldrá la actualización. Aplicarla cuando esté disponible.
  5. Vigilar los registros por si aparecen cuelgues de arranque PXE inexplicables o tráfico ICMP anómalo durante el aprovisionamiento.
  6. Mantener activados Secure Boot y el TPM como buena práctica general, sabiendo que no protegen contra este fallo concreto.

Perspectiva jurídica

Para las entidades sujetas al RGPD (art. 32, seguridad del tratamiento), a la Directiva NIS2 o al Esquema Nacional de Seguridad, este caso pone a prueba la gestión de vulnerabilidades en un nivel que a menudo se descuida: el firmware. Conviene dejar constancia documental del inventario, de las mitigaciones aplicadas (por ejemplo, desactivar PXE) y de las consultas a los fabricantes. Si más adelante se produce un incidente, esa trazabilidad será la prueba de la diligencia debida.

Fuentes