Kernel de Linux permite lectura de memoria del host desde una VM; parche CVE-2026-99999.

La comunidad de seguridad ha confirmado una vulnerabilidad crítica en el código de red del kernel de Linux que permite a código que ya se ejecuta dentro de una máquina virtual (VM) leer memoria del equipo físico que la hospeda y, en laboratorio, avanzar hasta provocar fallos y ejecutar código en ese host. El fallo fue descubierto por investigadores de pwn.ai durante un reto de seguridad organizado por Vercel, se reportó en privado a los responsables y ha recibido la referencia CVE-2026-99999 y la calificación 9.3 (Crítica) en el registro público.

Qué pasó (hechos confirmados): Paulos Yibelo, investigador de pwn.ai, demostró que paquetes de red especialmente construidos enviados desde el interior de una microVM podían filtrar bytes de la memoria del host; cada paquete podía devolver unos 32 bytes y el proceso podía repetirse. Vercel confirmó la demostración contra sus sandboxes en producción y dijo que no hay indicios de que nadie haya leído datos de clientes en el programa de recompensas. Los mantenedores del kernel aplicaron un parche (commit 6785011f8b16) que añade comprobaciones para que los datos de checksum de un paquete no apunten dentro del encabezado IPv4; ese cambio se ha integrado en la rama principal y se ha retroportado a ramas estables. El registro público del fallo lo clasifica como de vectores “locales”: el atacante necesita poder ejecutar código dentro de la VM afectada; no es un vector de explotación remota simplemente enviando paquetes desde Internet.

Cómo funciona técnicamente (explicado con cautela): el problema reside en la validación insuficiente de ciertas estructuras usadas por la pila de red del kernel al procesar checksums y referencias dentro de paquetes IPv4. Si el kernel sigue referencias dentro del propio paquete sin comprobar que no señalan regiones indebidas del encabezado, un paquete malformado puede inducir lecturas fuera de los límites previstos. Esas lecturas pueden exfiltrar fragmentos de memoria del espacio del kernel del host hacia la VM, y en condiciones controladas el mismo fallo puede provocar corrupción de memoria que derive en caídas del host o en posibilidad de control de ejecución. El parche introduce una comprobación adicional en cinco puntos del código de red para bloquear referencias de checksum que apunten dentro del encabezado IPv4; la solución es calificada por su autor como una medida de “defensa en profundidad” y requiere trabajo adicional para una verificación más temprana en la entrada de paquetes.

A quién afecta y por qué importa: el riesgo principal recae sobre entornos de nube y cualquier infraestructura en la que múltiples inquilinos compartan el mismo kernel de Linux en el host (es decir, la capa que ejecuta y gestiona VMs o microVMs). Vercel usa microVMs Firecracker sobre hosts bare-metal en Amazon EC2; el fallo no está en Firecracker sino en el kernel que corre en el host, por lo que cualquier proveedor que use una pila similar podría verse afectado hasta que el parche esté aplicado en sus kernels de host. Por otro lado, el vector requiere que el atacante ya ejecute código dentro de una VM; no es una vulnerabilidad explotable simplemente desde fuera por un atacante que envíe paquetes desde Internet.

Qué demostraron en laboratorio y qué queda incierto: en laboratorio pwn.ai mostró lectura continua de memoria (~32 bytes por paquete), dos paquetes bastaron para hacer caer un host y, con configuraciones replicadas, consiguieron control administrativo del host. Vercel confirma la fuga de memoria en su producción pero aclara que no hay evidencia de que datos de clientes fueran leídos en sus informes al reto. Esos avances hacia “ejecución de código en el host” y “control administrativo” fueron reproducidos por el investigador en máquinas configuradas para imitar la plataforma de Vercel; ambos puntos son reclamaciones del equipo investigador y, tal y como ellos mismos subrayan, corresponden a resultados de laboratorio más que a explotaciones observadas fuera del entorno controlado. No hay, hasta ahora, informes públicos verificados de explotación en el mundo real.

Parche y estado de despliegue: el cambio principal está disponible en la rama principal del kernel y se ha retroportado a ramas estables; su autor fue Michael S. Tsirkin (Red Hat). Administradores de sistemas y proveedores deben aplicar la actualización del kernel en los hosts físicos o los builds del proveedor que incluyan el parche y reiniciar los hosts para que la corrección entre en vigor. Es importante comprobar los avisos de la propia distribución o del proveedor de la imagen, porque algunas distribuciones introducen correcciones sin cambiar el número de versión declarado por uname; por tanto, confirme que el parche concreto está presente en el binario que corre el host y no basarse únicamente en la versión numérica. Para referencia técnica del parche consulte el repositorio del kernel: commit 6785011f8b16, y para el contexto de microVM usado por Vercel vea Firecracker: https://github.com/firecracker-microvm/firecracker. También consulte la entrada pública del CVE en la base de datos nacional: https://nvd.nist.gov/vuln/detail/CVE-2026-99999.

Recomendaciones concretas para administradores y responsables de nube: actualice cuanto antes los kernels de host a los builds que incluyan el parche y reprograme/reinicie hosts para arrancar con la versión corregida; verifique con su proveedor que los hosts públicos han recibido la corrección. No basta con actualizar kernels de invitados: el fallo está en el kernel del host. Si no puede parchear inmediatamente, reduzca el riesgo de escalada: limite la capacidad de inquilinos no verificados para ejecutar código arbitrario en VMs, deshabilite características innecesarias como virtualización anidada, aplique controles de red estrictos a VMs que ejecuten código no confiable, y use mecanismos de aislamiento adicionales (jailers, políticas de permisos mínimos). Audite logs y patrones de tráfico de las VMs para detectar ráfagas inusuales de paquetes pequeños originados en invitados (indicadores coherentes con la técnica de exfiltración por paquetes repetidos).

Recomendaciones para desarrolladores y usuarios de servicios en la nube: si usa plataformas gestionadas, consulte sus avisos y confirme que el proveedor ha aplicado la corrección a los hosts que alojan sus cargas. Para operaciones críticas que requieran confidencialidad máxima, considere solicitar alojamiento en hosts dedicados o en instancias físicas aisladas hasta que la mayoría de proveedores tengan desplegado el parche. Mantenga secretos y claves rotadas periódicamente como práctica de mitigación ante posibles fugas no detectadas.

El descubrimiento es también un recordatorio de que la dimensión “compartida” del kernel en entornos multiinquilino es una superficie de riesgo y que el mantenimiento y despliegue rápido de correcciones en la capa de host son esenciales. El caso ilustra además cómo herramientas avanzadas, incluyendo modelos de lenguaje en el proceso de investigación, están acelerando la identificación de vulnerabilidades: pwn.ai afirma haber usado su plataforma asistida por IA para encontrar y encadenar el fallo en días y con coste reducido, una nota relevante para organizaciones que defienden infraestructuras comunes.