Descubren forma de eludir la autenticación TLS en LXD y MicroCloud sin necesidad de la clave privada

Un certificado público común resultó suficiente para eludir la protección de los servidores y obtener acceso a máquinas virtuales. La empresa Canonical confirmó una vulnerabilidad crítica en LXD y MicroCloud que permite a un atacante hacerse pasar por un cliente de confianza sin conocer la clave privada. El fallo recibió el identificador CVE-2026-112816 y la puntuación máxima de 10 según CVSS 4.0.
LXD gestiona contenedores del sistema y máquinas virtuales en Linux, y MicroCloud agrupa varios servidores en un clúster. Para la gestión remota, las plataformas admiten una API HTTPS con autenticación TLS mutua. El servidor verifica el certificado del cliente y compara los datos proporcionados con la lista de credenciales de confianza. La vulnerabilidad rompía el propio principio de esa verificación, permitiendo aceptar la identidad digital de otro.
La causa residía en el manejo incorrecto de la cadena de certificados TLS. El servidor comparaba con la lista de confianza todos los certificados recibidos del cliente, aunque la verificación criptográfica confirmaba la posesión de la clave privada solo para el primer certificado de la cadena. Un atacante podía añadir el certificado público de un cliente de confianza después del propio, haciendo que el servidor aceptara la conexión en nombre de otro usuario.
Para la explotación se requiere acceso de red a la API HTTPS y el certificado público de un cliente de confianza. La clave privada, que normalmente confirma el derecho a conectarse, no es necesaria. Tras una autenticación exitosa, el atacante obtiene las facultades de la cuenta suplantada, incluido el acceso a las máquinas virtuales gestionadas. Con privilegios suficientemente altos, es posible el control total del host con permisos de root.
El fallo representa un peligro particular para MicroCloud. Al conectarse un nuevo miembro al clúster, un atacante puede interceptar el certificado TLS público del servidor y luego usar la información obtenida para suplantar al miembro. LXD normal, por defecto, solo está disponible a través del socket Unix local. Un ataque remoto se vuelve posible si el administrador ha permitido la conexión de red mediante el parámetro core.https_address.
El problema afecta a las ramas LXD 4.0.14, 5.0.10, 5.21.8 y 6.9. Las correcciones se publicaron el 29 de octubre en las versiones 4.0.15, 5.0.11, 5.21.9 y 6.10.1 respectivamente. Para MicroCloud se prepararon las compilaciones 2.1.5 y 3.4.1. Inicialmente fueron los desarrolladores de Incus, un fork independiente de LXD, quienes detectaron el fallo. Se corrigió una vulnerabilidad similar en Incus 7.6.0 junto con otros problemas de seguridad.
Al 2 de noviembre no hay confirmaciones públicas de explotación de CVE-2026-112816 en ataques reales. La vulnerabilidad tampoco figura en el catálogo de fallos activamente explotados de CISA. Canonical recomienda actualizar inmediatamente LXD y MicroCloud con los comandos sudo snap refresh lxd y sudo snap refresh microcloud. Dado que las correcciones se distribuyeron de forma gradual, tras actualizar hay que comprobar la versión instalada. Hasta aplicar los parches, reducir el riesgo limitando el acceso de red a la API.