La vulnerabilidad de LXD registrada como CVE-2026-112816 permite entrar como un cliente de confianza sin tener su clave privada. Basta con llegar por red a la interfaz de programación HTTPS y tener el certificado público de ese cliente, un dato que no es secreto. Canonical puntuó el fallo con un 10.0 en la escala CVSS, la nota máxima, y publicó las versiones corregidas el 29 de octubre.
LXD es el gestor de contenedores de sistema y máquinas virtuales de Canonical, la empresa detrás de Ubuntu. MicroCloud usa LXD para unir varias máquinas en un clúster privado. Quien explota el fallo actúa con la identidad del cliente suplantado: entra al clúster, toca sus máquinas virtuales y, si la cuenta copiada tiene privilegios altos, puede quedarse con acceso de administrador total al equipo que aloja los contenedores. Canonical lo advirtió con esa misma claridad en su aviso del 28 de octubre.
La diferencia con un contenedor común importa en este caso: un contenedor de sistema corre una distribución Linux completa, con sus servicios y sus usuarios, casi como una máquina virtual ligera. Suplantar al cliente que manda sobre ese conjunto equivale a quedarse con varias máquinas a la vez, no con una sola aplicación aislada.
El error estaba en la revisión de la cadena de certificados
LXD y MicroCloud aceptan clientes remotos con TLS mutuo, un esquema donde el cliente presenta un certificado digital para probar su identidad. Un cliente es de confianza cuando su certificado figura en la lista que guarda el servidor. El problema vivía en esa comprobación: el servidor comparaba cada certificado enviado por el cliente contra su lista, pero una conexión TLS solo prueba la posesión de la clave privada del primer certificado de la cadena, el certificado hoja. El resto de la cadena lo arma el propio cliente, a su gusto.
El truco queda entonces a la vista. Un atacante toma el certificado público de un cliente legítimo, lo coloca como certificado intermedio detrás del suyo y el servidor lo deja pasar como si fuera ese cliente. The Hacker News publicó hoy el desglose del fallo y lo describió como una suplantación que no exige robar ninguna clave. La vulnerabilidad de LXD queda registrada con el código CWE-295, validación incorrecta de certificados.
El fallo no nació en casa de Canonical. Lo reportó el proyecto Incus, la bifurcación comunitaria que salió de LXD, y Canonical confirmó que su producto cargaba el mismo error. Incus lo corrigió en su versión 7.6.0, dentro de un paquete con otros 17 problemas de seguridad, y sus responsables avisaron de que no existe un ajuste de configuración que tape el hueco.
Quién está expuesto y quién respira tranquilo
Dos condiciones separan a un servidor expuesto de uno a salvo: que la interfaz HTTPS se pueda alcanzar por red y que el atacante consiga el certificado público de un cliente aceptado. Un LXD instalado solo, con su configuración de fábrica, no expone esa interfaz: escucha en un conector local del propio equipo. La exposición aparece cuando un administrador activa la dirección HTTPS con el ajuste core.https_address para gestionar el servidor desde fuera.
MicroCloud guarda un punto débil propio. Cuando una máquina se une al clúster, su certificado público viaja en el proceso de incorporación; un atacante que lo intercepte en ese momento puede presentarse después como ese miembro ya aceptado. Las versiones afectadas de LXD son 4.0.14, 5.0.10, 5.21.8 y 6.9. Los paquetes de LXD del archivo de Ubuntu figuran como no afectados o no distribuidos: la corrección viaja en los paquetes snap.
Del uso malicioso no hay rastro público. El registro del CVE trae una valoración de CISA, la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos, fechada el 30 de octubre: el fallo no consta como explotado, no entró al catálogo de vulnerabilidades explotadas conocidas y no circula código de explotación publicado. El aviso llega en días movidos para quien administra servidores Linux, con el fallo del núcleo de Linux todavía fresco en la lista de parches de cada equipo de sistemas.
La ficha de valoración de CISA marca dos casillas que explican la prisa: explotación automatizable e impacto técnico total. El ataque no pide interacción de ningún usuario ni privilegios previos, y quien entra hereda todo lo que la cuenta suplantada podía tocar. Por eso Canonical pidió actualizar de inmediato, aun sin ataques conocidos contra instalaciones reales.
Versiones corregidas de LXD y MicroCloud: cómo actualizar
Canonical fijó el parche en LXD 6.10.1 para el canal 6/stable, 5.21.9 para 5.21/stable, 5.0.11 para 5.0/stable y 4.0.15 para 4.0/stable. MicroCloud queda corregido en 3.4.1 y 2.1.5. La actualización en una instalación snap se resuelve con dos comandos: sudo snap refresh lxd y sudo snap refresh microcloud. Quien use Incus debe pasar a la 7.6.0.
Ojo con un detalle del despliegue. Canonical avisó de que las versiones corregidas de LXD todavía bajaban del canal candidato al estable cuando salió su aviso, en un despliegue progresivo iniciado el 29 de octubre. Tras actualizar conviene comprobar la versión real instalada, porque dos servidores actualizados el mismo día pueden mostrar números distintos esta semana. Sin parche aplicado, la única defensa práctica es recortar quién puede llegar a la interfaz por red. CVE-2026-112816 no perdona la espera: un certificado público, que cualquiera puede copiar, quedó convertido en la llave de entrada al clúster.
Fuente: Canonical
