Grave vulnerabilidad en LXD y MicroCloud permite acceso root sin claves privadas

Canonical ha publicado parches de emergencia para una grave falla de seguridad en su hipervisor de contenedores LXD y su herramienta de agrupamiento MicroCloud. La vulnerabilidad, identificada como CVE-2026-112816, tiene la máxima puntuación de severidad (10.0) según el Sistema Común de Puntuación de Vulnerabilidades (CVSS). Permite a atacantes remotos suplantar a clientes de confianza y obtener acceso no autorizado a la infraestructura sin poseer las claves criptográficas privadas necesarias.

Qué ocurrió

La falla permite a un atacante iniciar sesión como cliente de confianza explotando un error de verificación en el proceso de autenticación mutua TLS. Para tener éxito, el atacante necesita acceso de red a la API HTTPS y el certificado público de un cliente que el servidor ya considera confiable. Una vez autenticado, el atacante actúa como ese cliente, obteniendo acceso completo al clúster y sus máquinas virtuales. Si la cuenta suplantada posee privilegios elevados, el atacante puede escalar hasta obtener acceso root en la propia máquina anfitriona.

Este problema fue reportado originalmente por el proyecto Incus, una bifurcación comunitaria de LXD, que confirmó que el bug afectaba a ambas plataformas. Aunque los paquetes estándar del archivo de Ubuntu para LXD no están afectados, los usuarios que ejecutan LXD o MicroCloud mediante paquetes Snap corren riesgo. Canonical ha declarado que no hay evidencia de que esta vulnerabilidad haya sido explotada en entornos reales, y actualmente no figura en la lista de Vulnerabilidades Explotadas Conocidas de CISA. Sin embargo, el potencial impacto es lo suficientemente grave como para requerir atención inmediata por parte de los equipos de infraestructura.

Cómo funciona

LXD y MicroCloud utilizan TLS mutuo (mTLS) para asegurar el acceso remoto a la API. En esta configuración, un cliente demuestra su identidad presentando un certificado digital. El servidor verifica este certificado contra un almacén de confianza, que contiene las identidades de todos los clientes permitidos. La vulnerabilidad radica en cómo el servidor valida la cadena de certificados durante este intercambio.

En una conexión TLS estándar, el protocolo solo prueba criptográficamente que el cliente posee la clave privada del primer certificado de la cadena, conocido como certificado hoja. El resto de la cadena es simplemente datos adjuntados por el cliente. La implementación defectuosa en LXD comparaba cada certificado de la cadena proporcionada contra el almacén de confianza, en lugar de validar estrictamente el certificado hoja. Un atacante podría tomar el certificado público de un cliente de confianza, que no es secreto, y adjuntarlo a su propia cadena. El servidor aceptaría erróneamente al atacante como el cliente de confianza porque encontraría una coincidencia en la cadena, aunque el atacante no poseyera la clave privada correspondiente a ese certificado específico.

Detalles clave

• ID de la vulnerabilidad: CVE-2026-112816 con una puntuación CVSS de 10.0.
• Productos afectados: Versiones de LXD 4.0.14, 5.0.10, 5.21.8 y 6.9, junto con clústeres de MicroCloud.
• Versiones corregidas: LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15 y MicroCloud 3.4.1 o 2.1.5 a través de canales Snap.
• Requisitos del ataque: Acceso de red a la API HTTPS y posesión del certificado público de un cliente de confianza.
• Origen: Reportado por el proyecto Incus, que publicó su propia corrección en la versión 7.6.0.
• Estado de la explotación: No se conoce ninguna explotación activa ni código de exploit público hasta el 30 de octubre de 2026.

Por qué importa

Para los ingenieros que gestionan infraestructuras contenedorizadas, esta vulnerabilidad socava el modelo fundamental de confianza de mTLS. Se suele confiar en TLS mutuo como un mecanismo de autenticación robusto porque requiere la posesión de una clave privada. Esta falla omite por completo ese requisito, lo que significa que simplemente tener un certificado público, que a menudo se distribuye abiertamente o se captura durante las uniones a la red, es suficiente para la suplantación. Esto es particularmente peligroso en entornos MicroCloud, donde un atacante que capture el certificado público de un miembro durante el proceso de unión al clúster pueda posteriormente suplantar a ese miembro.

El impacto va más allá del simple acceso a datos. Dado que LXD gestiona contenedores a nivel de sistema, una suplantación exitosa de un cliente privilegiado puede llevar al compromiso total del host. Esto otorga al atacante acceso root a la máquina física o virtual subyacente, permitiéndole escapar completamente del entorno del contenedor. Para los equipos que usan LXD en producción, especialmente aquellos que exponen la API a través de una red, esto representa un fallo crítico en el control de acceso que no puede mitigarse únicamente mediante cambios de configuración.

Qué puedes hacer

• Actualiza tus instalaciones de LXD y MicroCloud inmediatamente usando sudo snap refresh lxd y sudo snap refresh microcloud.
• Verifica la versión instalada después de actualizar, ya que las correcciones pueden desplegarse gradualmente desde los canales candidatos a estables.
• Restringe el acceso de red al listener de la API de LXD si no puedes actualizar de inmediato, ya que el ataque requiere acceso directo a la API HTTPS.
• Comprueba si tu servidor LXD independiente tiene habilitado core.https_address; si no lo está, probablemente no esté expuesto a este vector de ataque remoto específico.
• Monitoriza cualquier actividad inusual en la pertenencia al clúster o en los registros de la API que puedan indicar intentos de suplantación.
• Si estás usando Incus en lugar de LXD, actualiza a la versión 7.6.0 o posterior para abordar este y otros 17 problemas de seguridad.