📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artÃculo está justo aquà arriba.
📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artÃculo está justo aquà arriba.
Un pull request en GitHub acaba de arruinar meses de coordinación responsable entre Anthropic y Google. Publicaron un parche antes de la fecha acordada, la ventana de disclosure se cayó a pedazos, y detrás del error de agenda aparece algo más incómodo: una vulnerabilidad con severidad 9.5 sobre 10 que lleva 16 años dormida en el firmware de prácticamente todos los servidores del planeta. El CVE es CVE-2026-97631 y si administras cualquier cosa con UEFI, esto te toca aunque no lo sepas.
Qué es exactamente el bug
El fallo vive en EDK II, el código base open source de TianoCore que AMI, Insyde, Phoenix y casi todos los fabricantes usan para construir su UEFI. Incluso Project Mu, el fork «endurecido» de Microsoft, arrastraba el componente vulnerable. Dicho de otro modo: no es un bug de un proveedor puntual, es un bug del substrato común de la industria. El foro UEFI describe EDK II como la implementación de referencia de sus especificaciones.
La técnica es un buffer overflow en el driver PXE de la pila de red de EDK II. Durante un arranque por red, el driver copia mensajes de error ICMP en un campo fijo de 504 bytes sin validar el largo del mensaje. Alguien con acceso a tu red local manda un ICMP más grande en el momento justo y escribe bytes controlados fuera del campo. El código termina corriendo en ring 0, antes del sistema operativo, antes de Secure Boot, antes de que el TPM cargue. La cadena de confianza completa se construye después del punto donde el atacante ya está dentro.
Por qué la posición del exploit importa más que el exploit
HD Moore, el creador de Metasploit, lo resumió mejor que nadie: un atacante con acceso breve a la red puede usar ese instante del boot para llegar a componentes sensibles como el TPM y romper el cifrado de disco. El payload final no deja persistencia, pero en ese punto del arranque el atacante puede instalar módulos que sà corren en cada inicio. Es exactamente la zona que buscaban LogoFail, PixieFail, PKFail, BootHole y BlackLotus en años anteriores. Esta familia de bugs no es una mala racha, es un patrón de diseño con grietas.
La ironÃa extra: después de PixieFail la comunidad montó proyectos de fuzzing sobre EDK II justamente para cazar estos fallos antes que nadie. Un overflow de 16 años pasó entre las redes de todos esos fuzzers. El fuzzing no es una póliza, es una esperanza.
Mi lectura desde la administración de infraestructura
Si tu servidor es una máquina fÃsica propia, la respuesta es la de siempre: revisa si tu fabricante ya liberó firmware parcheado y aplica la actualización capsule en el próximo reinicio. Se hace sin downtime extra, solo se demora el reboot.
Pero si administras VPS, como yo, la respuesta honesta es más frustrante: probablemente no puedes hacer nada todavÃa. El firmware lo pone el proveedor, tú ni siquiera sabes qué build de UEFI corre detrás de tu máquina virtual. Mi flota lleva dÃas con esta duda encima y la única acción disponible es pedir soporte y esperar. La ventaja parcial: el exploit exige acceso a la red local durante la ventana de boot PXE, y un server detrás de un front-end que absorbe el ICMP está bastante más protegido que un equipo expuesto. El vector realista son insiders, operadores de ransomware que ya entraron a la red, o un robo fÃsico del equipo.
Lo que sà me incomoda de verdad es el proceso: un solo pull request publicado antes de tiempo quemó el timeline de disclosure completo, a seis dÃas de otro desorden similar con parches crÃticos de PHP. AMI publicó el fix en un PR el mes pasado y el advisory público apareció recién esta semana. Con el código del parche disponible, escribir el exploit es cuestión de tiempo, mientras el parcheo real de millones de equipos tardará meses. Moore lo llama un bug «forever»: va a seguir vivo en hardware fuera de soporte por años. Guarda este CVE en tu lista de las que nunca se cierran del todo.
VÃa: Code-execution flaw in UEFI firmware affects most servers on planet Earth, Ars Technica.
Fuente de inspiración: Code-execution flaw in UEFI firmware affects most servers on planet Earth
