← Volver a artículos
Seguridad· 3 min de lectura

Xen XSA-478 (CVE-2025-58151): un fallo TOCTOU en varstored permite escalar privilegios desde la VM

El 27 de enero de 2026 el proyecto Xen publicó el aviso de seguridad XSA-478, que corrige la vulnerabilidad CVE-2025-58151 en varstored. Se trata de una condición de carrera de tipo TOCTOU (Time-of-Check-Time-of-Use) que puede permitir a un atacante con acceso a nivel de kernel dentro de una máquina virtual escalar privilegios y ejecutar código fuera de ella.

Qué es varstored y dónde está el problema

varstored es un componente del toolstack Xapi (el stack de gestión que utilizan plataformas basadas en Xen, como XenServer/XCP-ng) encargado de gestionar las variables UEFI de las máquinas virtuales. Para hacerlo, varstored accede a un buffer de memoria compartido con el guest.

El fallo nace de barreras de compilador insuficientes al acceder a ese buffer compartido. Como el guest puede modificar el contenido de la memoria entre el momento en que varstored la comprueba y el momento en que la usa (de ahí el nombre TOCTOU), se introducen condiciones de carrera. Según el aviso, dependiendo del código que genere el compilador, un atacante puede llegar a controlar índices de tablas de salto (jump tables), lo que abre la puerta a la ejecución de código arbitrario dentro de varstored.

A quién afecta

La vulnerabilidad afecta exclusivamente a despliegues con el toolstack Xapi y, según el aviso oficial, todas las versiones de varstored son vulnerables.

Para que el problema sea explotable deben darse estas condiciones:

  • El guest debe ser una máquina virtual HVM en x86 configurada como VM UEFI (es decir, con firmware=uefi en los parámetros de arranque HVM).
  • No son explotables los guests PV ni las VM configuradas con BIOS tradicional.

Es importante subrayar que el atacante necesita acceso de nivel kernel dentro de la VM para aprovechar el fallo. No es un ataque que se lance directamente desde fuera del host: el escenario es el de un atacante que ya controla un guest UEFI y quiere salir de él hacia el toolstack del host.

Gravedad e impacto

El aviso clasifica el impacto como escalada de privilegios: un atacante con control del kernel de la VM puede ejecutar código dentro de varstored, que corre en el contexto del host. Esto rompe el aislamiento que se espera entre la máquina virtual y la infraestructura de gestión, lo que en un entorno multi-tenant (varios clientes compartiendo hardware) es especialmente serio. En el listado de incidentes lo hemos catalogado con severidad alta.

Mitigación y parche

Según el aviso de Xen, no existen workarounds: la única forma de mitigar la vulnerabilidad es aplicar el parche publicado por el proyecto (xsa478.patch). Si gestionas una plataforma basada en Xapi (XenServer, XCP-ng o derivados), las recomendaciones prácticas son:

  • Actualizar varstored en cuanto tu distribución o proveedor publique los paquetes corregidos.
  • Mientras tanto, revisar qué VM usan UEFI y valorar el nivel de confianza de quien las opera, ya que el vector requiere control del kernel del guest.
  • Mantener al día el resto de avisos de Xen del mismo lote (XSA-477 y XSA-479 se publicaron la misma fecha), que conviene aplicar de forma conjunta.

Este incidente es un buen recordatorio de que la seguridad de la virtualización no termina en el hipervisor: el toolstack y los componentes auxiliares como varstored también forman parte de la superficie de ataque, y un fallo en la sincronización de memoria compartida puede tener consecuencias tan graves como un fallo en el propio Xen.

Fuente