Nube e infraestructura

PwnEscape: Una vulnerabilidad crítica en el kernel de Linux permite a las máquinas virtuales leer la memoria del host

Una vulnerabilidad crítica en el código de red del kernel de Linux, denominada PwnEscape, permite que las máquinas virtuales invitadas lean la memoria del host. El fallo afecta a la infraestructura en la nube y requiere un parche inmediato en el kernel del hos

Ilustración de un rack de servidores con grietas estructurales
Ilustración generada para este artículo

Traducido automáticamente del original en inglés.

Una vulnerabilidad de seguridad crítica en el kernel de Linux, registrada como CVE-2026-99999 y apodada PwnEscape, permite que el código que se ejecuta dentro de una máquina virtual lea la memoria del sistema anfitrión (host). Descubierta por el investigador Paulos Yibelo de pwn.ai durante un desafío de seguridad de Vercel en agosto de 2026, el fallo fue confirmado por Vercel tras ser demostrado contra sus sandboxes en la nube en producción. El problema reside en la capa de red compartida del kernel de Linux, lo que supone un riesgo para los proveedores de nube que dependen de esta infraestructura para el aislamiento de cargas de trabajo.

Qué ocurrió

Paulos Yibelo demostró que paquetes de red especialmente diseñados, enviados desde dentro de una máquina virtual invitada, podían provocar tres resultados distintos: lectura de la memoria del host, caída del host y ejecución de código en el host. En pruebas realizadas contra los sandboxes de producción de Vercel, cada paquete filtraba aproximadamente 32 bytes de memoria del host, un proceso que podía repetirse indefinidamente enviando más paquetes. Aunque la fuga de memoria se verificó en producción, las capacidades de caída del sistema y ejecución de código solo se observaron en entornos de laboratorio configurados para imitar la configuración de Vercel. Dos paquetes específicos fueron suficientes para colgar un host e interrumpir todos los sandboxes que se ejecutaban en él, y una explotación posterior permitió al investigador obtener control de administrador en estas pruebas controladas.

La vulnerabilidad fue identificada utilizando Omega-Pwn, una herramienta interna de investigación que combinaba herramientas de seguridad con elementos de la arquitectura OmegaClaw de SingularityNET. GPT-5.6 Sol actuó como motor principal de razonamiento, analizando el código fuente y trazando hipótesis bajo dirección humana. Yibelo enfatizó que, aunque se logró el control de administrador en el laboratorio, esto no constituye una afirmación de ejecución de comandos root en ningún entorno de producción de un proveedor. Vercel informó que ningún participante del desafío accedió a archivos de clientes, secretos o datos de aplicaciones, y no hay evidencia de explotación en el mundo real.

Cómo funciona

El fallo existe en el código de red del kernel de Linux, específicamente en cómo maneja las sumas de verificación (checksums) de los paquetes. No es una mala configuración en la instalación de un único proveedor de nube, sino un defecto en la capa de kernel compartida utilizada por la mayoría de las grandes nubes para aislar las cargas de trabajo de los clientes. La explotación implica enviar paquetes de red donde los datos de la suma de verificación apuntan al encabezado IPv4 antes de que el kernel los procese. Esto permite que la VM invitada evite los límites de aislamiento y acceda a la memoria del host.

La corrección, implementada en el commit 6785011f8b16 por Michael S. Tsirkin de Red Hat, añade una comprobación en cinco lugares del código de red para garantizar que los datos de la suma de verificación no puedan apuntar al encabezado IPv4. El autor describe esto como una "medida de defensa en profundidad", señalando que aún está pendiente una comprobación más exhaustiva a la entrada de los paquetes. Este parche ha sido portado hacia atrás (backported) a múltiples ramas estables del kernel, abordando el riesgo inmediato mientras se desarrollan mejoras a largo plazo.

Detalles clave

  • ID de la vulnerabilidad: CVE-2026-99999, apodada PwnEscape.
  • Severidad: Calificada como 9.3 sobre 10 (Crítica) por los mantenedores del kernel.
  • Vector de ataque: Local; requiere ejecución de código dentro de una VM invitada.
  • Impacto: Fuga de memoria (32 bytes por paquete), caída del host y potencial ejecución de código.
  • Descubrimiento: Encontrada por pwn.ai en tres días utilizando investigación asistida por IA durante un desafío de bug bounty de Vercel.
  • Estado: No se reporta explotación activa; la corrección se ha fusionado en los kernels mainline y estables.

Por qué importa

Para ingenieros de software y líderes técnicos, esta vulnerabilidad destaca la fragilidad del aislamiento en entornos de nube multiinquilino. Dado que el fallo radica en el propio kernel de Linux, afecta a cualquier servicio que utilice microVMs Firecracker o tecnologías de virtualización similares en hosts bare-metal. Incluso si el código de su aplicación es seguro, la infraestructura subyacente puede ser vulnerable. Esto refuerza la necesidad de estrategias de defensa en profundidad, ya que confiar únicamente en los límites de virtualización es insuficiente cuando el kernel del host está comprometido.

El método de descubrimiento también señala un cambio en la investigación de seguridad. El uso de modelos de lenguaje grandes como GPT-5.6 Sol para analizar el código del kernel y encadenar vulnerabilidades redujo el costo de encontrar este fallo crítico a menos de $700 en tokens de API. Esto sugiere que el fuzzing y el análisis asistidos por IA se convertirán en herramientas estándar tanto para atacantes como para defensores, acelerando el ritmo al que se descubren vulnerabilidades profundas del sistema. Los equipos deben considerar ahora el modelado de amenazas impulsado por IA como parte de su postura de seguridad.

Qué puedes hacer

  • Actualice inmediatamente el kernel de su host a una versión corregida; actualizar solo los kernels de las invitadas no resuelve el problema.
  • Verifique el aviso de su distribución para asegurarse de que la corrección (commit 6785011f8b16) esté incluida, ya que los números de versión pueden variar.
  • Reinicie los sistemas después de aplicar la actualización del kernel para asegurar que el nuevo kernel esté activo.
  • Si no es posible parchear inmediatamente, limite el impacto deshabilitando la virtualización anidada y restringiendo los permisos para los procesos de microVM.
  • Monitoree las actualizaciones de su proveedor de nube respecto a parches del kernel del host y ventanas de mantenimiento.
  • Revise sus propias tuberías de pruebas de seguridad para incorporar herramientas de análisis asistidas por IA para una inspección de código más profunda.

Herramientas de la Tienda de Bytechap

Seguir leyendo

Todos los artículos