PwnEscape: la falla KVM que filtro memoria en Vercel
En pocas palabras: El stack de red del host forma parte del límite de aislamiento porque procesa metadata de checksum enviada por el guest después de validar el paquete IPv4. En PwnEscape (CVE-2026-99999), eso permitió filtrar memoria del host contra sandboxes de Vercel, aunque la falla está en el kernel Linux, no en KVM.
El 15 de octubre de 2026, investigadores de pwn.ai publicaron CVE-2026-99999, bautizada PwnEscape, una falla en el procesamiento de checksums IPv4 del kernel Linux. El bug permitió filtrar memoria del host contra sandboxes de producción de Vercel y, en laboratorio propio del investigador, ejecutar código como root en la máquina anfitriona.
PwnEscape es una vulnerabilidad crítica en el stack de red del host que atiende máquinas virtuales KVM conectadas por virtio-net. La encontró Paulos Yibelo, de pwn.ai, durante el desafío de seguridad “1 Million Dollar Vercel Sandbox Challenge”. El guest envía metadata de checksum que el host procesa después de haber validado el paquete, y esa metadata tardía puede reescribir un header IPv4 que el kernel ya dio por bueno.
En este artículo:
- En 30 segundos
- ¿Qué es CVE-2026-99999 (PwnEscape) y qué demostró pwn.ai contra Vercel?
- ¿Cómo funciona el ataque: qué es la “deferred-metadata trust inversion”?
- ¿Qué confirmó Vercel y qué todavía no está probado?
- ¿Qué dice el parche del kernel y qué distribuciones ya lo tienen?
- ¿Qué deben revisar los administradores de hosts KVM con virtio-net?
- ¿Qué está confirmado y qué queda pendiente?
- Errores comunes al evaluar esta vulnerabilidad
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- CVE-2026-99999 (PwnEscape), publicada el 15 de octubre de 2026, vive en el stack IPv4 del host, no en el hipervisor KVM.
- Vercel confirmó la fuga de memoria del host contra sus propios sandboxes de producción, pero dijo que no hay reportes de acceso a datos de clientes.
- El CNA del kernel calificó el bug 9.3 crítico sin privilegios requeridos; Red Hat lo calificó 8.8; Ubuntu lo lista como Medium.
- El fix llegó en el commit 6785011f8b16, integrado a mainline el 14 de octubre de 2026, con validación agregada en cinco rutas de checksum.
- AlmaLinux publicó kernels parcheados en su repositorio de testing el 16 de octubre, antes que apareciera un advisory formal para RHEL.
¿Qué es CVE-2026-99999 (PwnEscape) y qué demostró pwn.ai contra Vercel?
CVE-2026-99999 es un escape de máquina virtual que explota cómo Linux delega el cálculo de checksums de red al host. pwn.ai demostró tres resultados con niveles de evidencia distintos: filtración de memoria confirmada en producción de Vercel, caídas del host y ejecución de código como root solo reproducidas en máquinas propias del investigador, corriendo KVM y Firecracker.
El reporte técnico distingue algo clave: la fuga de memoria la validó Vercel contra infraestructura real. Los crashes y la ejecución de comandos quedaron confinados a laboratorios del propio investigador, según el write-up técnico publicado en dev.to. Esa diferencia importa porque mezclar ambos niveles de evidencia exagera el alcance real del incidente.
¿Por qué el nombre “escape”? Porque la ejecución de código cruza el límite entre guest y host. Pero el bug en sí mismo no está en el hipervisor.
Está en el código de red que cualquier VM con virtio-net puede alcanzar sin privilegios especiales. Vercel usa microVMs Firecracker basadas en KVM para su plataforma de sandboxes, y fue justo ese desafío público de seguridad el que destapó el problema.
¿Cómo funciona el ataque: qué es la “deferred-metadata trust inversion”?
La “inversión de confianza por metadata diferida” describe un orden de operaciones roto: el host valida el paquete temprano, pero ejecuta una escritura de checksum más tarde que modifica justo los bytes que ya había validado. pwn.ai le puso ese nombre descriptivo, no es un término establecido en la industria, pero sirve para entender la secuencia completa. Esto se conecta con lo que analizamos en cómo desplegar una app React con Vite.
En el ejemplo del investigador, el campo IHL del header IPv4 cambió de 20 a 60 bytes después de que el host ya había parseado un header de 20. La fragmentación de salida, que corre después, confió en el valor nuevo y copió bytes que no correspondían al dato lógico del paquete. El resultado: 32 bytes de memoria del host filtrados por caso, según la configuración de prueba que describe pwn.ai en su reporte.
Hay tres transiciones de confianza en juego. Primero, confianza de origen: un guest menos confiable le describe al host una operación que este va a ejecutar igual. Segundo, confianza de interpretación: el paquete cambia de representación mientras se procesan los headers, así que un valor chequeado contra una vista termina usándose contra otra distinta. Tercero, confianza temporal: una operación diferida altera un estado que otro código ya había parseado y dado por confiable.
Subís el paquete, el host lo valida, lo normaliza, lo fragmenta, y en algún punto de ese recorrido la metadata que viajó con el paquete reescribe exactamente lo que ya se había chequeado, sin que nadie vuelva a mirar esos bytes antes de usarlos.
¿Y esto solo pasa con checksums IPv4? No necesariamente. Los propios investigadores advierten que patrones similares podrían existir en otras partes del stack de red donde metadata controlada por el guest modifica campos del paquete después de la validación.
¿Qué confirmó Vercel y qué todavía no está probado?
Vercel confirmó la fuga de memoria del host contra sus sandboxes de producción, pero no confirmó ejecución de código ni acceso a datos de clientes en ese mismo entorno. La compañía dijo que no hay reportes de que alguien haya accedido a archivos, secretos o datos de aplicaciones de clientes en Vercel Sandbox.
Los crashes del host y la cadena de ejecución de código con privilegios root quedaron demostrados en máquinas propias de pwn.ai, con KVM y Firecracker, no en la infraestructura de Vercel. La cadena completa de escritura (los pasos exactos que llevan de la fuga de 32 bytes a correr un binario como root) no está publicada todavía. Los investigadores la reservaron para una “Parte 2” que, hasta el 22/10/2026, sigue sin aparecer. En desplegar tu sitio gratis en Vercel profundizamos sobre esto.
Eso deja una brecha real entre lo demostrado y lo reportado. ¿Alguien verificó de forma independiente la ejecución de código en producción? Todavía no. Lo que existe es el reporte del investigador y la confirmación parcial de Vercel sobre la fuga de memoria, nada más.
Alex Zenla, CTO de la firma de seguridad en contenedores Edera, lo resumió así para CSO Online: “cuando un guest escapa, no está escapando a una capa de hipervisor cuidadosamente contenida; puede caer en las capas más bajas del sistema operativo que controla los procesos, drivers y el stack de red del host”.
¿Qué dice el parche del kernel y qué distribuciones ya lo tienen?
El parche, commit 6785011f8b16 de Michael S. Tsirkin (Red Hat), agrega una validación simple antes de completar cualquier checksum: verifica que el punto de inicio del checksum esté más allá del header IPv4. La corrección toca cinco consumidores: fragmentación de salida, conntrack de bridge, NFQUEUE, el target CHECKSUM y la salida xfrm, con un helper compartido en el código de header IPv4.
El mensaje del propio commit la describe como “defense in depth” y aclara que “una validación más completa en la entrada está pendiente, pero necesita más trabajo”. Eso significa que el parche cierra esta instancia puntual del bug, no la clase completa de problema.
Mainline incorporó el fix el 14 de octubre de 2026. Las ramas estables lo llevan en 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 y 7.2.11. Acá va el estado por distribución, verificado al 21 de octubre de 2026: Sobre eso hablamos en comparamos Vercel contra AWS Amplify.
| Distribución | Estado | Referencia |
|---|---|---|
| Debian 12 (bookworm) | Parcheado en 6.1.190-1 | DLA-4841-1 |
| Debian 13 (trixie) | Parcheado en 6.12.113-1 | DSA-6568-1 |
| RHEL 9 | Parcheado, RHSA-2026:86033 | Red Hat CVE page |
| AlmaLinux 9 | Parcheado, ALSA-2026:86033 | AlmaLinux errata |
| RHEL 10 y RHEL 8 | Afectados, sin erratum listado | Red Hat CVE page |
| Ubuntu 22.04, 24.04, 26.04 | Vulnerable | Ubuntu tracker |
| Rocky Linux 9 | Sin advisory publicado | Rocky errata search |
| Amazon Linux 2 y 2023 | Builds parcheados listados | AWS bulletin 2026-137-AWS |
Ojo con algo puntual: los vendors backportean sin seguir el número de versión de upstream. Amazon Linux 2023 trae su fix en kernel-6.1.188-233.385.amzn2023, un número que a simple vista queda por debajo del 6.1.190 de upstream. Comparar números a ciegas te puede hacer pensar que un host sigue vulnerable cuando ya está parchado, o al revés.
¿Qué deben revisar los administradores de hosts KVM con virtio-net?
Lo primero: inventariar qué hosts corren guests que no administrás vos, conectados por virtio-net vía TAP o vhost-net. AWS nombra específicamente KVM autogestionado con virtio-net, Firecracker incluido, corriendo sobre kernels sin parchar.
Una lista práctica para empezar:
- Exposición de guests: identificá qué hosts corren VMs de terceros o workloads que no controlás directamente.
- Procedencia del kernel: confirmá si cada host corre un kernel upstream o un build de vendor, y qué dice el advisory exacto para esa build, incluyendo si hay un reboot pendiente.
- Rutas de datos activas: revisá cuáles de las rutas parcheadas existen en tu host (forwarding con fragmentación, conntrack de bridge, NFQUEUE, target CHECKSUM, IPsec).
- Dueño de la verificación: definí quién es responsable de probar el límite de aislamiento por el canal que el guest sí puede usar, y cuándo se probó la última vez.
La severidad tampoco es uniforme entre quienes la evaluaron. El CNA del kernel la puntuó 9.3 crítico sin privilegios requeridos. Red Hat la bajó a 8.8, con privilegios bajos requeridos. Ubuntu la clasificó como prioridad Media. AWS describe al atacante como alguien con acceso privilegiado dentro de un guest. Cada escala parte de un supuesto distinto sobre la posición del atacante, así que la exposición real de tu host depende de quién puede mandarle paquetes y bajo qué configuración.
Si administrás tu propia infraestructura KVM para hosting o sandboxes, ya sea on-premise o con un proveedor de infraestructura como donweb.com, la pregunta de fondo no es si parcheaste, es si alguien probó el límite de aislamiento por el canal que el guest tiene disponible. Un virtio-net device es exactamente ese canal.
¿Qué está confirmado y qué queda pendiente?
- Confirmado: fuga de memoria del host en sandboxes de producción de Vercel, según el propio comunicado de la empresa.
- Confirmado: parche upstream mergeado el 14 de octubre de 2026, con backports activos en múltiples distros al 21 de octubre.
- Confirmado: crashes de host y ejecución de código root, pero solo en máquinas propias del investigador, no en producción de Vercel.
- No confirmado: acceso a datos de clientes en Vercel Sandbox; la empresa dice que no hay reportes de eso.
- No confirmado: la cadena completa de escritura que lleva de la fuga de memoria a la ejecución de código, reservada para una Parte 2 que hasta el 22/10/2026 sigue sin publicarse.
- No confirmado: que la clase completa de vulnerabilidad esté cerrada; el propio commit dice que falta validación más completa en la entrada.
Errores comunes al evaluar esta vulnerabilidad
Pensar que PwnEscape solo afecta a hosts que corren VMs es el primer error. Red Hat aclara que un atacante local también puede disparar la falla, y el código vulnerable está en cualquier kernel Linux de los últimos 18 años, corra o no máquinas virtuales.
Actualizar solo el kernel del guest y asumir que el problema se resolvió es otro error típico. El bug vive en el host, no en el guest. Parchar la VM invitada no hace nada si el hipervisor sigue corriendo el kernel vulnerable. Para más detalles técnicos, mirá configurar el pooler de Supabase en Vercel.
Dar por cerrada toda la clase de vulnerabilidad apenas ves el CVE parcheado también es un error. El mensaje del commit lo dice explícito: es defensa en profundidad, y la validación completa de entrada todavía está en desarrollo. Cinco rutas quedaron cubiertas, pero la metadata que llega a esas rutas sigue siendo controlada por el guest.
Comparar el número de versión de tu kernel vendor contra la lista de versiones upstream sin leer el advisory específico puede llevarte a conclusiones equivocadas, como vimos con el caso de Amazon Linux 2023.
Preguntas Frecuentes
¿Qué es CVE-2026-99999 (PwnEscape)?
CVE-2026-99999, nombrada PwnEscape, es una vulnerabilidad crítica en el procesamiento de checksums IPv4 del kernel Linux que permite a un guest conectado por virtio-net corromper un header IPv4 ya validado en el host. El CNA del kernel la calificó 9.3 crítico y Red Hat 8.8, según sus propias escalas de evaluación.
¿Vercel confirmó una fuga de memoria en sus sandboxes de producción?
Sí, Vercel confirmó que la fuga de memoria del host fue demostrada contra sus sandboxes de producción. La empresa aclaró que no hay reportes de que esa fuga haya permitido acceder a archivos, secretos o datos de aplicaciones de clientes.
¿Ya existe parche para la vulnerabilidad de checksum en KVM?
Sí, el parche llegó en el commit 6785011f8b16, mergeado a mainline el 14 de octubre de 2026. Las ramas estables ya lo incluyen desde 5.10.272 en adelante, y distros como Debian, RHEL 9 y AlmaLinux 9 ya publicaron sus builds parcheadas.
¿Qué distribuciones Linux están afectadas por el escape de VM en virtio-net?
Todas las distribuciones que corren código del kernel Linux heredado desde 2008 están afectadas, incluyendo RHEL, Debian, Ubuntu, AlmaLinux, Rocky y Amazon Linux. El estado de parche varía: algunas, como Debian y AlmaLinux 9, ya tienen fix; otras, como Ubuntu y RHEL 8/10, seguían vulnerables o sin erratum al 21 de octubre de 2026.
¿Esta vulnerabilidad permite ejecutar código en el host?
Los investigadores de pwn.ai reportaron ejecución de código con privilegios root en el host, pero solo en máquinas propias que usaron para el laboratorio, con KVM y Firecracker. Esa ejecución de código no fue confirmada en la infraestructura de producción de Vercel, y la cadena técnica completa todavía no se publicó.
Conclusión
PwnEscape le pone un nombre concreto a algo que las revisiones de aislamiento venían pasando por alto: el stack de red del host es parte del límite de aislamiento, le guste o no al diagrama de arquitectura. El fix ya está disponible desde el 14 de octubre, así que la acción inmediata es clara, actualizar el kernel del host, no del guest, y confirmar la build exacta contra el advisory de tu distro.
Lo que no está resuelto es más interesante que lo que sí. La cadena completa de ejecución de código sigue sin publicarse, y el propio parche admite que falta validación más completa en la entrada. Si administrás hosts KVM que corren workloads de terceros, la pregunta que vale hacerte no es si parcheaste, es si alguien probó el límite de aislamiento por el canal que el guest efectivamente puede usar.
