Todo cloud tiene un muro que jura que es estructural. En un host virtualizado, ese muro es el hipervisor: la capa fina de código que convence a cada cliente de que su trozo de máquina le pertenece solo a él. El 3 de noviembre, el Proyecto Xen le dijo al mundo que un muro que mantiene desde 2016 tiene una puerta, y que la puerta la encontró una IA.
El aviso es XSA-523. Los dos CVE son CVE-2026-102703 y CVE-2026-102704. El impacto, en la redacción cuidadosa del proyecto: «Un invitado malicioso puede leer y escribir memoria arbitraria de otros dominios, incluido Dom0».
Léelo dos veces. No es «un invitado puede tumbar a su vecino». No es «un invitado filtra unos bytes». Un invitado puede llegar a la memoria de otro cliente y a la de Dom0, el dominio de control que ejecuta el host. XCP-ng, la plataforma abierta basada en Xen, lo dice aún más claro en sus notas: «un solo invitado comprometido puede salir de su aislamiento y tomar el control de todo el host».
Y no hay mitigación. Solo parches y un reinicio.
Qué se rompió exactamente
La grant table de Xen es el mecanismo que permite a las máquinas virtuales compartir memoria sin confiar las unas en las otras. Un invitado declara «estas páginas mías pueden ser leídas por esa VM» y Xen hace cumplir la promesa. La hiperllamada GNTTABOP_copy realiza esas copias en lotes y, como los elementos adyacentes de un lote suelen tocar memoria adyacente de la misma página, Xen guarda en caché la descripción validada del elemento anterior y la reutiliza cuando el siguiente parece equivalente.
Esa caché es donde se agrietó el muro.
El primer fallo, CVE-2026-102703, es una comprobación de validez que confunde dos tipos de identificador. Cuando el nuevo elemento copia por número de marco de máquina, Xen compara ese número con la entrada en caché sin confirmar antes que la entrada en caché fuera también un marco. Una referencia de grant de un elemento anterior puede confundirse con un número de marco físico y el buffer cacheado se reutiliza para memoria que el invitado no tiene derecho a tocar.
El segundo, CVE-2026-102704, es una comprobación de permisos colocada en el lugar equivocado. Copiar por número de marco en lugar de por referencia de grant solo es legal cuando el invitado trabaja sobre su propia memoria, y Xen lo verifica dentro de una función que llama al volver a bloquear los dominios implicados. Si el siguiente elemento nombra los mismos dominios que el anterior, esa función se salta por completo y la regla «solo tu propia memoria» nunca se ejecuta.
Ninguna de las dos rutas necesita configuración especial, root dentro del invitado ni una cadena de explotación pública. Ambas necesitan una cosa: una grant table funcional. Todas las versiones de Xen desde la 4.6 son vulnerables. Eso es una década de hipervisor, y por eso esto importa mucho más allá de la lista de correo de Xen.
La parte que debería cambiar cómo contratas seguridad
El Proyecto Xen atribuye el hallazgo a Anthropic, usando Claude. Stephan Lipp, de Ada Logics, validó el resultado. El equipo de investigación de CodeAnt reportó el mismo fallo de forma independiente.
Piensa en esa secuencia. Un modelo encontró un error de lógica de memoria en la grant table de un hipervisor que lleva diez años siendo leído por expertos humanos. Un equipo humano de validación confirmó que el hallazgo era real. Un segundo equipo de investigación con IA llegó al mismo fallo por su cuenta.
Es la misma semana en la que el grupo de inteligencia de amenazas de Google describió operaciones de LLMjacking que extraen más de un millón de dólares en uso robado de IA en la nube, y en la que Wiz contó más de nueve plataformas de desarrollo de IA comprometidas en octubre. Dos curvas se están cruzando: los atacantes automatizan el descubrimiento y la monetización con IA, y los defensores ahora tienen IA encontrando fallos reales en la capa más profunda de la pila.
La lectura práctica para un CTO es incómoda: tu cadencia de parcheo ya no se calibra contra investigadores humanos. Se calibra contra máquinas que leen código de kernel toda la noche.
Quién está expuesto y quién no
Si alquilas una VM a un hiperescalador, el parche es suyo y tu exposición depende de su ventana de mantenimiento. Pregúntales. En un cloud gestionado, la visión que tiene el invitado puede ir por detrás del estado real del host, así que la única respuesta válida llega por escrito del proveedor.
Si operas tu propio entorno Xen o XCP-ng, algo habitual en proveedores de hosting, agencias que gestionan infraestructura de clientes y cualquiera que virtualice on-premise, el reloj es tuyo.
- Xen unstable hasta 4.19.x: aplica xsa523-1.patch y xsa523-2.patch.
- Xen 4.18.x a 4.17.x: aplica xsa523-4.18-1.patch y xsa523-4.18-2.patch.
- Xen 4.6.x a 4.16.x: sin parche upstream. Esas ramas están en fin de vida. Si estás aquí, esto es un momento de migración, no de parcheo.
- XCP-ng 8.3 LTS: instala xen-4.17.7-4.2.xcpng8.3 y reinicia el host. Vates califica el impacto como crítico.
- Qubes OS 4.3: paquetes Xen 4.19.6-3 en dom0, requiere reinicio de dom0. Si usas Anti Evil Maid, vuelve a sellar tu passphrase, porque los nuevos binarios de Xen cambian PCR18 y PCR19.
Dos verdades operativas de sustos anteriores del hipervisor siguen aplicando. Primera: los parches están preparados contra ramas estables, así que actualiza a la punta de la rama antes de aplicarlos. Segunda: parchear detiene ataques futuros, no te dice si ya ocurrió uno. Un invitado que lee la memoria de su vecino no deja rastro en los logs del vecino. Si corres inquilinos no confiables, el parche es el principio de tu revisión de incidentes, no el final.
Qué hacemos nosotros, y qué haríamos por ti
En aratech tratamos los parches de hipervisor como un cambio de clase uno: ventana de reinicio programada, aviso a inquilinos, snapshot antes del reinicio y revisión posterior del changelog del paquete para poder demostrar que la rama incluye el número XSA en lugar de suponerlo. Los clientes sobre infraestructura virtualizada compartida reciben una pregunta respondida por escrito: qué hipervisor, qué versión y qué estado de parche.
La versión corta de lo que hacer esta semana:
- Inventaria el hipervisor, no solo la VM. Ejecuta
xl info | grep '^xen_version'en hosts Xen y confirma concat /sys/hypervisor/typedentro de los invitados. La mayoría de los equipos conoce sus versiones de sistema operativo y no tiene idea de qué hay debajo. - Pide a cada proveedor el estado de XSA-523 por escrito, con la rama y la fecha de reinicio. «Estamos parcheados» sin número de versión es una suposición.
- Parchea, reinicia y verifica. Un parche de hipervisor que nunca reinicia es una nota en un ticket, no un arreglo.
- Si operas ramas en fin de vida, trata XSA-523 como el disparador de un plan de migración. No habrá parche para 4.6 a 4.16.
- Asume que el descubrimiento ahora va a velocidad de máquina. Reduce el tiempo entre «aviso publicado» y «host reiniciado» a horas, y escribe el runbook antes de necesitarlo.
El muro resiste si lo reconstruyes
El muro del hipervisor sigue siendo el mejor que tenemos. Aguantó una década frente a investigadores humanos, y aguantó porque las comprobaciones estaban casi bien. «Casi» es ahora todo lo que necesita un auditor de IA para encontrarte.
La puerta en Xen está parcheada. Si la puerta de tu infraestructura está cerrada depende de una pregunta aburrida: ¿sabes hoy qué versión de hipervisor sostiene tus cargas de producción?
Si la respuesta honesta es «tendría que preguntar», ese es el hallazgo que vale la pena atender antes del próximo aviso.