Un fallo CVSS 10 en LXD y MicroCloud permite suplantar a clientes de confianza

Canonical ha publicado correcciones para un fallo crítico de autenticación en LXD y MicroCloud que permite a un atacante ser aceptado como cliente de confianza de la API sin poseer nunca la clave privada de ese cliente. Registrado como CVE-2026-112816, tiene la puntuación CVSS máxima de 10,0.

Qué ha pasado

LXD y MicroCloud autentican a los clientes remotos mediante TLS mutuo: el cliente presenta un certificado y el servidor le da acceso si ese certificado figura en su almacén de confianza.

El problema estaba en qué certificado comprobaba el servidor. En el intercambio TLS, el cliente solo demuestra que posee la clave privada del primer certificado (leaf) de la cadena que envía; el resto de la cadena es simplemente lo que el cliente decida adjuntar. El código vulnerable comparaba todos los certificados de la cadena con el almacén de confianza, de modo que un atacante podía presentar su propio certificado leaf, añadir detrás el certificado público de un cliente de confianza y ser tratado como ese cliente.

Los certificados públicos no son secretos, y eso es lo que lo hace tan grave: los únicos requisitos reales son llegar por red a la API HTTPS y disponer de una copia del certificado de un cliente de confianza.

Por qué importa

Una vez aceptado, el atacante hereda los permisos del cliente suplantado sobre el clúster, sus instancias y sus máquinas virtuales. Si esa identidad es privilegiada, Canonical advierte que el resultado puede ser acceso root a la máquina anfitriona.

La exposición depende de la configuración:

• LXD independiente solo escucha por defecto en un socket Unix local. Solo queda accesible por red si un administrador configura core.https_address.
• MicroCloud, que agrupa varias máquinas LXD en un único clúster, tiene un punto débil adicional: un atacante capaz de capturar el certificado público de un miembro mientras se une al clúster puede autenticarse después como ese miembro.

Están afectadas LXD 4.0.14, 5.0.10, 5.21.8 y 6.9, así como las versiones anteriores a sus respectivas correcciones. El mismo fallo existía en Incus, el fork comunitario de LXD, que lo corrigió en la versión 7.6.0. Los paquetes de LXD del archivo de Ubuntu figuran como no afectados o no distribuidos, por lo que las correcciones llegan a través de los snaps.

Por ahora no hay indicios públicos de explotación. Una evaluación de la CISA estadounidense del 30 de octubre lo considera no explotado conocido, no figura en el catálogo Known Exploited Vulnerabilities de la CISA y no se ha publicado ningún exploit funcional. Dada la sencillez de la técnica, no esperamos que esa ventana dure mucho.

Qué hacer

1. Actualizar ya. En instalaciones snap, ejecute sudo snap refresh lxd y sudo snap refresh microcloud. Versiones corregidas:

2. Comprobar la versión realmente instalada. Cuando se publicó el aviso, las versiones corregidas de LXD aún se estaban promoviendo del canal candidate a stable: confírmelo con snap list en lugar de dar por hecho que la actualización trajo el parche.
3. Restringir el acceso a la API. No existe una solución mediante configuración. Hasta aplicar el parche, limite quién puede alcanzar el puerto HTTPS de LXD/MicroCloud (8443 por defecto) con reglas de cortafuegos, una VPN o una red de gestión, y no lo exponga nunca a internet.
4. Los usuarios de Incus deben pasar a la 7.6.0, que cierra este fallo junto con otras 17 correcciones de seguridad.
5. Revisar el almacén de confianza y eliminar los certificados de cliente que ya no se necesiten: cada certificado de confianza es una identidad que se puede suplantar.

Este tipo de fallos solo es explotable si la API es accesible, así que saber exactamente qué interfaces de administración se exponen es media defensa. Nuestro servicio de Attack Surface Management mapea de forma continua los hosts y servicios expuestos a internet y señala las API de administración y orquestación expuestas, como la de LXD, antes de que las encuentre un atacante.