Canonical ha publicado un aviso sobre una vulnerabilidad crítica que afecta a LXD y MicroCloud y que permite a un atacante iniciar sesión como un cliente de confianza sin disponer de la clave privada de ese cliente. El problema requiere, eso sí, dos condiciones: acceso de red a la API HTTPS del servidor y el certificado público del cliente que el servidor ya considera de confianza.
Cómo funciona la suplantación
LXD y MicroCloud usan mutual TLS (mTLS) para autenticar clientes: el cliente presenta un certificado y el servidor comprueba que dicho certificado figura en su almacén de confianza. La comprobación vulnerable comparaba cada certificado enviado por el cliente contra la lista de certificados de confianza sin verificar correctamente que la posesión de la clave privada correspondiera al certificado en cuestión.
En TLS sólo se garantiza que el cliente posee la clave privada del primer certificado de la cadena (el certificado leaf). Un atacante puede encadenar su propio certificado como primer elemento y adjuntar, detrás, el certificado público de un cliente legítimo. Dado que el servidor comparaba cualquier certificado de la cadena con su almacén de confianza, aceptaba la identidad del cliente legítimo aunque el atacante no tuviera la clave privada correspondiente.
Qué puede hacer un atacante y a quién afecta
- Si el atacante consigue conectarse a la API HTTPS del servicio y dispone del certificado público de un cliente confiable, podrá operar con la identidad de ese cliente frente al servidor LXD/MicroCloud.
- En un clúster MicroCloud, Canonical explica que un atacante que capture el certificado público de un miembro al unirse al clúster podría luego autenticarse como ese miembro.
- Si la cuenta suplantada tiene privilegios elevados, el atacante podría acceder a recursos sensibles del clúster y, según Canonical, incluso obtener “acceso root a la máquina host”.
Versiones afectadas y corrección
La vulnerabilidad está registrada como CVE-2026-112816 y tiene una puntuación CVSS máxima de 10.0. Canonical ha liberado versiones corregidas de LXD y MicroCloud (disponibles como paquetes snap). Incus, el proyecto que inicialmente reportó el fallo, también publicó la corrección en su versión 7.6.0.
Canonical recomienda actualizar las instalaciones snap con los comandos de actualización correspondientes (por ejemplo, sudo snap refresh lxd y sudo snap refresh microcloud) y comprobar la versión tras la actualización, pues en el momento del aviso las correcciones podían estar aún propagándose del canal candidate al estable.
Mitigaciones temporales y consideraciones prácticas
No existe una solución de configuración que elimine el fallo en LXD; la medida temporal sugerida es limitar el acceso de red a la API HTTPS para reducir la exposición. En instalaciones standalone LXD la API no se expone por defecto: solo se abre en red si el administrador activa el ajuste core.https_address. Por tanto, auditar quién puede acceder a ese listener y aplicar restricciones de red (firewall, listas de control de acceso) reduce el riesgo hasta que se instale la actualización.
Incus también indicó que no hay una configuración que mitigue completamente el problema y que la única alternativa segura es restringir el acceso de red al servicio y actualizar a la versión corregida.
¿Hay indicios de explotación activa?
Según el registro del CVE y la evaluación incluida por CISA con fecha del 30 de octubre, no hay constancia pública de explotación en entornos reales y no se ha publicado un exploit funcional. Aun así, la alta gravedad y el requisito relativamente accesible (certificado público y acceso a la API) hacen prioritaria la actualización para instalaciones expuestas.
Qué deben hacer los administradores
- Actualizar LXD y MicroCloud a las versiones corregidas publicadas por Canonical (y, para usuarios de Incus, migrar a Incus 7.6.0 o superior).
- Verificar la versión instalada tras ejecutar la actualización, especialmente si se usan snaps cuyos canales pueden tardar en sincronizarse.
- Si no es posible actualizar de inmediato, restringir el acceso de red a la API HTTPS (firewall, VPN, ACL) y desactivar la escucha en red si no es necesaria.
- Auditar certificados de clientes y la exposición de procesos de unión de nodos en clústeres para evaluar la posibilidad de que se hayan capturado certificados públicos.
Lee también:
- Fallas en Arista y Nextcloud: parches disponibles y alcance para administradores web
- Cloudflare reporta 18,2 millones de ataques DDoS a nivel de red en el tercer trimestre, un aumento del 38%
Fuente: The Hacker News
