Cuando encendemos un ordenador, lo primero que se ejecuta no es Windows ni Linux. Antes actúa el firmware, un pequeño programa grabado en la placa base que despierta el hardware, revisa que todo esté en orden y busca desde dónde cargar el sistema. Hoy ese programa casi siempre sigue el estándar UEFI. Y si alguien consigue manipularlo, consigue el puesto de vigilancia más privilegiado de la máquina.

Eso es justo lo que permite una vulnerabilidad publicada en octubre de 2026 con el identificador CVE-2026-97631. Está en EDK II (también llamado EDK2), el proyecto de código abierto de TianoCore que sirve de referencia para buena parte del firmware UEFI del mercado. Según el aviso del proyecto, publicado el 22 de octubre, el fallo tiene una gravedad de 9,5 sobre 10 en la escala CVSS v4.

Qué falla exactamente

El problema está en el controlador de arranque por red, conocido como PXE, que forma parte del paquete NetworkPkg de EDK II. PXE permite que un equipo arranque descargando su sistema desde un servidor de la red local en lugar de leerlo de su propio disco. Es algo muy habitual en centros de datos, donde se instalan y reinstalan cientos de máquinas a la vez sin tocar ninguna a mano.

Según las descripciones publicadas, el fallo está en cómo ese controlador procesa los mensajes ICMP, el tipo de paquete que usan las redes para avisar de errores o comprobar si un equipo responde. Un mensaje más grande de lo previsto puede desbordar un búfer y corromper la memoria. El rastreador de seguridad de Debian lo clasifica como una escritura fuera de límites por un cálculo incorrecto del tamaño del búfer, explotable a distancia, que puede acabar en la ejecución de código arbitrario. The Hacker News añade que el error llevaba unos 16 años en el código.

Lo delicado es cuándo ocurre todo esto: durante el arranque, antes de que se cargue el sistema operativo y antes de que Secure Boot haga sus comprobaciones. Un código que se ejecuta en ese momento puede quedar fuera del alcance de antivirus y otras defensas que funcionan dentro del sistema.

A quién afecta y a quién no

El titular original de Ars Technica habla de «la mayoría de los servidores del planeta», y conviene leer esa frase con calma. Es cierto que EDK II es la base sobre la que trabajan los grandes fabricantes de firmware y que también lo usa Project Mu, la variante reforzada de Microsoft. Pero que un fabricante parta de EDK II no significa que su producto final lleve el código vulnerable, ni que el arranque por red esté activado. Algunos análisis recuerdan que nadie ha medido qué porcentaje real de servidores está expuesto.

Para que el ataque funcione se necesitan varias condiciones a la vez:

• Un firmware que incluya la versión afectada del controlador PXE. El registro del CVE señala NetworkPkg hasta la versión edk2-stable202608.
• Que el equipo arranque por red. Una máquina que arranca desde su propio disco no queda expuesta por esta vía.
• Que el atacante pueda enviar paquetes a la red donde ocurre ese arranque, normalmente una red interna.

Además, hay análisis que apuntan a que, para lograr una ejecución de código fiable, el atacante necesitaría conocer la versión concreta del firmware de su objetivo. Por su parte, Intel dijo a Ars Technica que no le consta que esté afectado ninguno de sus productos comerciales que siguen recibiendo actualizaciones de seguridad.

El fallo también llega a las distribuciones Linux que empaquetan EDK II, por ejemplo para arrancar máquinas virtuales con UEFI. Debian marca como vulnerables varias de sus versiones, entre ellas bookworm y trixie, y Red Hat incluye su paquete edk2 de RHEL 8, 9 y 10 entre los afectados.

Parches y letra pequeña

La corrección ya está integrada en el código de EDK II. El problema es el camino que tiene que recorrer después: cada fabricante de firmware la incorpora a su versión, cada fabricante de placas o servidores la empaqueta para sus modelos, y cada administrador la instala. Las actualizaciones de firmware se aplican con mucha menos frecuencia que las del sistema operativo, así que es probable que muchos equipos tarden meses en recibirla, y algunos no la recibirán nunca.

Mientras tanto, la recomendación habitual en los fallos de PXE de EDK II es sencilla: desactivar el arranque por red en los equipos que no lo necesiten, aislar la red donde arrancan los que sí lo usan y aplicar la actualización de firmware en cuanto el fabricante la publique. Para el usuario doméstico, el riesgo práctico es bajo: un portátil o un PC de casa casi nunca arranca por PXE.

Por qué importa

El firmware es el cimiento de cualquier ordenador. Cuando falla, lo que se construye encima pierde parte de su protección. Este caso recuerda que una sola pieza de código abierto, reutilizada por toda la industria, puede repartir el mismo error por miles de productos distintos, y que arreglarlo en el origen es solo el primer paso. Para empresas y centros de datos, la lección es revisar qué servicios del arranque tienen activados, desactivar los que no usan y tratar las actualizaciones de firmware con la misma seriedad que las del sistema.