¿Escape de KVM en Vercel? Fue un zero-day del kernel Linux

El 3 de octubre de 2026, un investigador de seguridad anunció la vulnerabilidad que toda nube multi-tenant espera en silencio que nunca llegue: un escape de invitado a host en Vercel Sandbox. La cobertura inicial —incluida una versión anterior de este artículo— lo presentó como un zero-day de KVM o del hipervisor. El 14 de octubre, Vercel publicó los hallazgos de su desafío Sandbox de 1.000.000 USD, y el panorama ahora es más nítido y, en un aspecto importante, distinto: la ruptura pasó por el kernel Linux, no por el hipervisor.

Las noticias de última hora cambian, y aquí se ocultaron detalles a propósito a la espera de los parches, así que la disciplina más importante es separar lo confirmado de lo afirmado. Lo hacemos primero —ahora anclados al relato de Vercel— y luego explicamos por qué la arquitectura sigue haciéndolo grave y qué debería hacer un líder de seguridad antes de que exista un CVE.

Qué está confirmado y qué se afirma

• Confirmado por Vercel (análisis del 14 de octubre): el hallazgo más grave es un defecto en la pila de red del kernel Linux upstream, alcanzable con paquetes manipulados desde dentro de la microVM. Se demostró que hace tres cosas: filtrar memoria del host a través de la red (demostrado contra la producción de Vercel), colgar el host con dos paquetes y ejecutar comandos con privilegios completos de administrador en el host. El cuelgue y la ejecución de código solo se demostraron en el laboratorio KVM/Firecracker del propio investigador, con la misma configuración que Sandbox, no en la producción de Vercel. Vercel dice que ningún informe mostró a nadie accediendo a datos de clientes. El desafío pagó 242.000 USD entre 1.285 informes; el investigador es Paulos Yibelo (pwn.ai).
• Revisado de forma independiente: Trail of Bits dedicó cuatro semanas-ingeniero al código de Vercel, entregó 20 hallazgos y concluyó que la frontera de virtualización es sólida desde el punto de vista arquitectónico; por eso se lee como un bug del kernel alcanzado a través del invitado, no como un escape del núcleo del hipervisor.
• Todavía no público: no hay identificador CVE, lista de versiones de kernel afectadas, cadena de explotación ni evidencia de explotación activa. Las correcciones están en revisión privada; el investigador trabajó con los maintainers del kernel en parches candidatos y Vercel se coordina con AWS. La pregunta abierta ya no es «¿es KVM?», sino hasta dónde llega el defecto del kernel cuando se publique el CVE.

Mantén ambas mitades a la vez: los hechos confirmados son graves, y el radio de impacto no confirmado del bug del kernel es lo que hay que vigilar.

La arquitectura: por qué «microVM→EC2» lo es todo

Vercel Sandbox ejecuta la carga de trabajo de cada cliente dentro de un contenedor Linux, pero ese contenedor vive dentro de su propia microVM Firecracker —una máquina virtual ligera con un kernel invitado dedicado— sobre un host Amazon EC2 bare-metal. Lo crucial es que la propia documentación de Vercel señala la microVM, no el contenedor, como la frontera de seguridad. Esa decisión de diseño es la correcta: los contenedores comparten el kernel del host, así que un bug del kernel afecta a todos por igual; una microVM da a cada cliente un muro de VM real.

Debajo de Firecracker está KVM, el hipervisor integrado en el kernel Linux, que impone la frontera de CPU y memoria entre invitado y host. Ese es el muro que todos supusieron roto. Según los hallazgos de Vercel, no se rompió: la frontera del hipervisor resistió (y Trail of Bits la revisó como sólida). Lo que el invitado alcanzó fue la pila de red del kernel Linux del host —el código que procesa los paquetes que envía el invitado—, y un defecto ahí permitía que esos paquetes filtraran memoria del host, lo colgaran o ejecutaran código en él. El escape es real, pero el componente roto es el kernel, no el monitor de virtualización. Esa distinción cambia quién está expuesto: no «todos los que usan KVM», sino «todos los que ejecutan un kernel Linux vulnerable a través del cual invitados no confiables pueden enviar paquetes».

Por qué un bug del kernel alcanzable desde el invitado sigue siendo la pesadilla multi-tenant

El kernel Linux es la única capa que está debajo de todo: contenedores, microVM y los propios hosts. Todo el modelo económico de la computación serverless y de sandbox —meter a muchos clientes en hardware compartido— se basa en una suposición: un invitado no puede alcanzar el host ni a sus vecinos. Un defecto del kernel que un invitado puede alcanzar con paquetes de red normales, y usar para leer memoria del host o ejecutar código en él, es esa suposición fallando, aunque el hipervisor haya hecho su trabajo. El invitado nunca tuvo que vencer a KVM; solo tuvo que enviar paquetes que el kernel del host manejaba mal.

Las consecuencias concretas que demostró Vercel: memoria del host —la máquina que un cliente comparte con otros— filtrándose de forma continua en paquetes que el invitado envía por internet; el host colgándose con dos paquetes, lo que tumba todos los sandboxes que aloja; y código ejecutándose con privilegios completos de administrador en el host. En un mundo de computación compartida, tu radio de impacto ya no es solo tu propia cuenta: es quien estuviera alojado contigo. Por eso Vercel mantiene un desafío público que paga hasta 1 millón de USD por escapes de Sandbox, y por eso este, aunque la frontera de virtualización resistió, se pagó como Crítico.

La parte sana: la divulgación responsable funcionando

Si quitas el tono sensacionalista, el proceso aquí es un modelo de cómo debería ir. Vercel abrió su frontera más sensible al escrutinio público con una recompensa de siete cifras, pagó cuando alguien la rompió, confirmó públicamente el tipo de bug y se comprometió a publicar un análisis. El investigador lo comunicó al proveedor, trabajó con los maintainers del kernel en parches candidatos y aceptó la recompensa en lugar de vender o publicar un exploit. El propio pago de seis cifras es una señal: los escapes fiables de invitado a host —de hipervisor o de kernel— son raros y valiosísimos, y por eso encontrarlos con una recompensa es mejor que encontrarlos en un incidente.

Qué debería hacer un líder de seguridad antes del CVE

No puedes parchear un bug sin CVE y sin lista de versiones afectadas. Lo que sí puedes hacer es el trabajo de arquitectura que hace sobrevivible un fallo de aislamiento del host —del hipervisor o del kernel— y adelantarte al aviso:

• ☐ Inventaría cuánto dependes del aislamiento entre clientes a nivel de hipervisor. ¿Dónde se ejecutan tus datos o tu código más sensibles sobre computación multi-tenant compartida: funciones serverless, runners de build/CI en sandbox, PaaS multi-tenant, sandboxes de ejecución de código de IA? Esa lista es tu exposición si un escape de KVM o microVM se generaliza. Modela explícitamente la frontera de confianza con nuestro Threat Model Studio →.
• ☐ No apoyes la confidencialidad de tus joyas de la corona en una sola frontera. Asume que la capa de aislamiento puede fallar: cifra los datos sensibles con claves que el cliente de cómputo no tiene, aplica mínimo privilegio para que una carga escapada llegue a poco y segmenta para que un host comprometido no sea todo tu entorno.
• ☐ Separa lo realmente sensible de lo realmente multi-tenant. Las cargas de mayor valor y mayor secreto son las que más te conviene tener en cómputo dedicado o de un solo cliente, no junto a código arbitrario no confiable.
• ☐ Define bien la línea de responsabilidad compartida. El parche del hipervisor es trabajo de tu proveedor; una arquitectura que sobreviva a un fallo de aislamiento del lado del proveedor, y un plan de respuesta para cuando salga el aviso, son tuyos. Regístralos como riesgos con responsable en tu Risk Register →.
• ☐ Prepara tu respuesta de antemano. Sigue el análisis de Vercel, el futuro CVE y los avisos de KVM/Firecracker; sabe hoy cuáles de tus proveedores funcionan sobre KVM/Firecracker y qué tan rápido parchean su flota de hosts. Evalúalo con la herramienta de riesgo de proveedores →.
• ☐ Ensáyalo. «Se confirma un escape entre clientes en un proveedor del que dependemos» es un ejercicio de mesa que vale la pena hacer ahora, no durante el incidente: practica la llamada en la Cyber War Room →.

La conclusión

Un pago Crítico en un desafío y un zero-day del kernel Linux alcanzable desde dentro de un sandbox no son solo una historia de Vercel: recuerdan que el aislamiento multi-tenant es una pila de fronteras (hipervisor, kernel, contenedor) y que a un cliente le basta con vencer la más débil que tenga a su alcance. Aquí el hipervisor resistió y el kernel no. La divulgación responsable le dio tiempo al sector antes del CVE; el trabajo de cada líder de seguridad es aprovecharlo. Trata el aislamiento del host como un control que puede fallar en cualquier capa, diseña para que su fallo sea sobrevivible y sé el equipo que ya sabía dónde estaba expuesto cuando llegue el parche.

Actualizado el 17 de octubre de 2026 según los hallazgos propios de Vercel. Modela la frontera de confianza con el Threat Model Studio, pon a prueba una cadena de ataque con el simulador de rutas de ataque y sigue el riesgo de aislamiento de proveedores en tu Risk Register. Para saber más sobre cómo sobrevivir a zero-days de infraestructura, lee el zero-day de Citrix NetScaler y por qué el perímetro y la infraestructura siguen sufriendo brechas, y mantente al día en PlayCISO AI Labs.