Una máquina virtual alquilada puede leer la memoria de la máquina física que la aloja, tumbar la máquina entera y, en el laboratorio del investigador que encontró el fallo, ejecutar código como root fuera de su jaula. El fallo se llama PwnEscape, está registrado como CVE-2026-99999 y el equipo de CVE del kernel de Linux lo puntúa 9,3 sobre 10, mientras Red Hat lo califica de Important con 8,8.
El camino hasta la ficha fue corto y poco habitual. Paulos Yibelo, de PWNAI Research, lo encontró en agosto durante el desafío de un millón de dólares que Vercel abrió sobre sus sandboxes, y lo reportó en privado a los responsables de seguridad del kernel el 4 de septiembre. El parche aceptado, firmado por Michael S. Tsirkin, de Red Hat, entró en la rama principal el 14 de octubre y un día después salieron siete kernels estables. El detalle incómodo es la edad del código: nace en 2008, en Linux 2.6.27, así que casi cualquier anfitrión Linux construido desde entonces nació vulnerable.
Por eso el dato urgente no es la nota, sino quién ha parcheado. Red Hat, AlmaLinux y Debian publicaron kernels corregidos entre el 19 y el 27 de octubre, y Ubuntu, con todas sus versiones soportadas afectadas, seguía sin kernel arreglado el 3 de noviembre. Hay una trampa de concepto que explica la mitad del riesgo: el invitado es el sistema que corre dentro de la máquina virtual, y el anfitrión es el kernel real que ejecuta el hipervisor y al que ese invitado solo debería pedir recursos, nunca leerle la memoria. Actualizar el invitado deja el agujero del anfitrión donde estaba.
El checksum que reescribe una cabecera ya validada
El fallo no está en el hipervisor, sino en cómo el kernel del anfitrión procesa los paquetes IPv4 que llegan desde una máquina virtual. No es un error de KVM: vive en la pila de red del anfitrión.
Linux permite que un paquete viaje con el checksum sin calcular, una optimización llamada descarga de checksum. El paquete lleva dos pistas, dónde empieza el cálculo y dónde debe escribirse el resultado, y una tarjeta virtio permite al invitado pasarlas al anfitrión. El kernel aceptaba la posición sin comprobar que quedara después de la cabecera IPv4, así que el cálculo diferido escribía encima de una cabecera que ya había leído y dado por buena.
Con metadatos mal puestos, el campo de longitud pasaba de 5 a 15 en el ejemplo del investigador, así que el código de fragmentación trataba una cabecera de 20 bytes como si midiera 60 y leía los 40 siguientes como si fueran opciones de IP. De esa confusión salieron tres resultados, descritos paso a paso por el investigador y recogidos en el desafío de un millón de dólares:
- Fuga de memoria del anfitrión, 32 bytes por caso y repetible mientras el invitado siguiera enviando paquetes. Vercel afirma que se demostró contra sus sandboxes de producción.
- Caída del anfitrión con dos paquetes, que se lleva por delante todas las máquinas virtuales de esa máquina.
- Escrituras de 64 bytes en memoria del kernel encadenadas hasta ejecutar un programa como root en el anfitrión, probadas solo en equipos del propio investigador.
El código de explotación no es público y los detalles de esa cadena quedan para una segunda entrega, así que el listón práctico sigue siendo alto. Lo que ya es público es la fuga de memoria y la caída, y ninguna de las dos necesita un exploit elegante.
Qué separa al invitado del anfitrión y por qué el parche del invitado no sirve
Un proveedor que actualiza la imagen de sus máquinas virtuales cree haber cerrado el problema y no ha tocado la puerta que importa. El código vulnerable se ejecuta en el kernel del anfitrión al procesar los paquetes que salen del invitado, así que la corrección tiene que aterrizar ahí y necesita un reinicio de la máquina física. Parchear el invitado protege a ese invitado de los demás, nunca al anfitrión que los sostiene.
Red Hat añade un matiz que amplía el alcance. Un atacante local también puede disparar el fallo, sin máquina virtual de por medio, y el código vulnerable está en todos los kernels de Red Hat, corran o no máquinas virtuales. Cualquier servidor afectado entra en la lista, aunque el riesgo serio se concentra en quien aloja código de terceros.
Para quien vende máquinas virtuales, esa frontera separa un cliente enfadado de una fuga que afecta a todos a la vez. Un invitado comprometido en un anfitrión sin parche puede leer memoria del anfitrión y, a través de ella, la de los demás invitados de esa máquina. El sistema en riesgo es, al final, el que ejecuta máquinas virtuales de gente en la que no confías.
El kernel recibe más CVE de los que puede arreglar
Quién tiene el kernel corregido y quién sigue esperando
La foto por distribución es la parte más útil y la que decide si un anfitrión está expuesto esta semana. La tabla recoge lo que cada proyecto ha publicado y deja fuera los productos que siguen en investigación, como los equipos de gestión de NetApp.
| Distribución |
Estado el 3 de noviembre |
Detalle |
| Red Hat |
Corregido |
RHEL 10 y 9 el 19 y 20 de octubre, RHEL 8 el 24, RHEL 7 y 6 ELS el 22 y el 27; OpenShift 4.12 a 4.22 incluido |
| AlmaLinux 8, 9 y 10 |
Corregido |
Backport propio en los repositorios de producción desde el 23 de octubre |
| Debian 12 y 13 |
Corregido |
Paquetes 6.1.190-1 y 6.12.113-1 |
| Ubuntu 22.04, 24.04, 26.04 y 26.10 |
Sin parche |
Kernels en preparación; 20.04 y anteriores siguen vulnerables sin fecha |
En la mayoría de las distribuciones el trabajo ya está hecho y lo que falta es que el anfitrión reinicie con el kernel nuevo. En Ubuntu no, y ahí se abre una ventana que ya va por su tercera semana. Canonical marca el fallo con prioridad Medium y asigna número a cada kernel previsto, del 5.15.0-203.213 al 7.3.0-10.10, señal de trabajo en curso sin fecha pública.
Los proveedores que alquilan capacidad no están en la misma casilla. Akamai dice que ya parcheó sus hipervisores, pero sus nodos sobre Ubuntu seguían esperando a Canonical el 29 de octubre. El mes tampoco acompaña. CVE-2026-98432, el fallo de TCP que Ubuntu y RHEL arrastraban sin parche a finales de octubre, es otro agujero distinto y el segundo no tapa al primero.
El error más común es confundir el paquete instalado con el kernel que corre. `uname -r` contesta a la segunda pregunta y es la única que cuenta: un anfitrión que actualizó sin reiniciar sigue expuesto, y en un hipervisor ese reinicio obliga a migrar antes las máquinas virtuales que aloja.
MPTCP abre el CVE-2026-98432 y Linux sigue sin parche en RHEL
El reloj que corre desde el 15 de octubre
La ventana no es cómoda. Yibelo escribe que espera exploits para configuraciones débiles en semanas y exploits que funcionen con la configuración por defecto del hipervisor en menos de un mes. Hoy no hay exploit público, la evaluación de explotación de CISA en la ficha es «none» y el fallo no aparece en el catálogo de vulnerabilidades explotadas de la agencia.
El riesgo se concentra donde alguien ejecuta código ajeno sobre el mismo kernel. Los proveedores de cloud y VPS, los runners de integración continua y las plataformas que ejecutan agentes sobre KVM o Firecracker son el grupo que más tiene que perder, porque un solo inquilino malicioso alcanza a los demás. Vercel contó con AWS y otros socios para coordinar la corrección, y casi todos los grandes proveedores aíslan cargas en esa capa del kernel.
La parte que no se puede improvisar es el inventario. Saber qué anfitriones corren qué kernel, cuáles han reiniciado y cuáles comparten máquina con código no verificado es lo que separa una semana de trabajo de un incidente con nombre propio.
La pregunta que conviene hacerle al proveedor
Quien alquila máquinas virtuales no necesita un comunicado, necesita una fecha. La pregunta útil es si el kernel del anfitrión que sostiene tu servicio está parcheado, en qué día se reinició esa máquina y si eso ocurrió antes del 15 de octubre. Un proveedor que responde con la del invitado no ha entendido la pregunta, o prefiere no contestarla.
Del otro lado, quien vende capacidad tiene un problema de inventario antes que de tecnología. La ventana que describe el investigador se mide en semanas, y en ese plazo no cabe una auditoría nueva; solo cabe tener el trabajo hecho. Un fallo nacido en 2008 que se arregla con una comprobación en seis archivos deja la sensación de que el problema real no era el checksum, sino cuántos anfitriones llevaban dieciocho años sin que nadie mirara dentro.
