Una vulnerabilidad crítica pone en riesgo a millones de servidores: el fallo llevaba 16 años oculto y nadie se había dado cuenta
Elígenos como tu fuente preferida en Google.
Este fallo de seguridad permitía a los atacantes ejecutar código malicioso en algunos servidores. La vulnerabilidad tiene una gravedad de 9,5 sobre 10.
Aunque lo normal es que, si existe cualquier brecha de seguridad, se encuentre más o menos rápido, hay algunos fallos que permanecen ocultos durante años sin que nadie se dé cuenta. Eso es precisamente lo que ha ocurrido con una vulnerabilidad que llevaba 16 años en un componente utilizado por fabricantes de servidores y otros equipos.
Tal y como se ha podido saber, el fallo está en EDK II, un proyecto de código abierto que sirve como base para desarrollar el firmware UEFI de muchos dispositivos, es decir, el software que se pone en marcha cuando enciendes un ordenador.
La vulnerabilidad ya está registrada con el nombre CVE-2026-97631 y tiene una puntuación de gravedad de 9,5 sobre 10. Que sea tan alarmante se debe a que un atacante podría ejecutar código malicioso antes de que incluso se carguen las barreras de seguridad del dispositivo una vez se enciende.
Por supuesto, esto no significa que todos los servidores estén en contra de las cuerdas ni que este problema ahora vaya a dar pie a un ciberataque masivo. Es muy peligroso, eso es cierto, pero no compromete todos los dispositivos.
Un error que llevaba 16 años sin que nadie lo viera
Contextualizando, EDK II es un proyecto de código abierto que utilizan muchos fabricantes para crear el firmware UEFI de sus equipos. Aunque no todos lo usan de la misma forma, lo cierto es que su código sigue estando en cierta parte.
Uno de los componentes de este software permite encender un servidor utilizando una red, sin necesidad de arrancarlo directamente desde su disco duro o SSD. Esto es algo que usan las empresas, porque permite arrancar muchos equipos sin tener que ir uno por uno.
El problema es que ese componente tiene un error a la hora de recibir ciertos mensajes a través de la red. En lugar de comprobar correctamente el tamaño de esos mensajes, puede aceptar más información de la que debería.
Si un atacante consigue aprovechar el error en un servidor, podría meter código malicioso y ejecutarlo antes de que se pongan en marcha las protecciones del equipo.
Por qué es tan peligroso que el ataque ocurra antes de arrancar Windows o Linux
Que todo esto sea tan peligroso se debe precisamente al momento en el que sucede el ataque. De forma simple, cuando enciendes un ordenador, el sistema operativo no se carga al momento. Antes de comenzar a funcionar, entra en acción el firmware UEFI, que prepara el hardware y se encarga de iniciar el proceso de arranque.
El problema es que, durante esa fase, Windows Defender, por ejemplo, todavía no está funcionando. Si un atacante consigue ejecutar código malicioso en ese momento, puede hacer realmente lo que quiera.
Según los investigadores, todo esto podía ejecutarse con los máximos privilegios del procesador dentro del entorno UEFI.
Esta grave vulnerabilidad se ha hecho pública antes de lo previsto
La vulnerabilidad ha sido descubierta por Alex Matrosov, de Anthropic, y Dan Holmes, de Google. Ambos habían acordado mantenerla en secreto hasta enero, con el objetivo de dar tiempo a los fabricantes para tener listas las correcciones.
Sin embargo, AMI, un fabricante de firmware y otros componentes de hardware, ha publicado una solicitud de cambios en el repositorio de EDK II en la que habla del fallo e incluye una solución.
Con esto, puede parecer que es más positivo, ya que este problema se corta de raíz; sin embargo, no todo es tan perfecto como parece.
La mejor opción es que los fabricantes tengan tiempo para preparar las actualizaciones y que los administradores puedan instalarlas antes de que todo se haga público y aquellos hackers que lo desconocían, no se aprovechen. Ahora todos saben que existe un problema grave, pero todavía no tienen una solución.
Y actualizar el firmware no es tan fácil. Cada fabricante tiene que comprobar qué productos están afectados, adaptar la corrección y lanzarla para todos sus equipos. Ahora toca trabajar contrarreloj.
