Fallo CVSS 10 en LXD y MicroCloud permite suplantar clientes de confianza

Canonical ha publicado correcciones para un fallo de autenticación de máxima gravedad en LXD y MicroCloud que permite a un atacante suplantar a un cliente de confianza sin tocar nunca la clave privada de ese cliente. Catalogado como CVE-2026-112816 y con una puntuación CVSS de 10.0, el error está en cómo el handshake TLS mutuo del servidor evalúa las cadenas de certificados: si presentas el certificado público de un cliente de confianza —que, por diseño, no es un secreto— detrás del tuyo, el servidor te deja pasar como ese cliente. Según The Hacker News, suplantar con éxito una cuenta privilegiada podría dar al atacante «acceso root a la máquina host», además del clúster y de todas las máquinas virtuales que contiene.

Las condiciones previas importan, y llegaré a si 10.0 es el número correcto. Hacen falta dos cosas: acceso de red a la API HTTPS de LXD o MicroCloud, y el certificado público de un cliente que el servidor ya confía. Nada de phishing, robo de claves ni fuerza bruta. Es el equivalente en cadenas de certificados a colarse detrás de alguien: entras por tu propio pie, pero el guardia revisa la credencial de la persona que va delante.

Cómo falló la comprobación de la cadena de confianza

LXD y MicroCloud autentican a los clientes remotos con TLS mutuo. El cliente presenta un certificado; el servidor lo acepta si ese certificado figura en su almacén de confianza, la lista de identidades que admitirá. Hasta aquí, nada raro. El fallo estaba en qué certificados se molestaba el servidor en comprobar contra ese almacén.

En TLS, el handshake demuestra criptográficamente que el cliente posee la clave privada de exactamente un certificado: el leaf, el primero de la cadena. Todo lo que va después del leaf son simplemente datos que el cliente decidió enviar. El código vulnerable de LXD comparaba todos los certificados de la cadena presentada contra el almacén de confianza, así que un atacante podía generar su propio par de claves, colocar el certificado público de un cliente de confianza detrás de su propio leaf y coincidir con el almacén en la segunda entrada. El servidor nunca verificaba que el atacante tuviera la clave privada de ese certificado de confianza, porque TLS simplemente no funciona así.

# What the attacker presents
chain = [attacker_leaf, trusted_client_public_cert]
# What TLS proves: private key for attacker_leaf ONLY
# What the vulnerable server did:
for cert in chain:
if cert in trust_store:
authenticate_as(cert)   # matches trusted_client_public_cert -> session as trusted client

Una vez autenticado, el atacante hereda todos los privilegios del cliente suplantado: operaciones de clúster, acceso a las VM y, si la cuenta es de administrador, root a nivel de host. Los certificados públicos están pensados para compartirse; viajan en los handshakes, quedan registrados y están presentes en las copias de seguridad de configuración. Tratar uno de ellos como prueba de identidad sin prueba de posesión de la clave rompe todo el modelo de mTLS.

La cronología: de un fork comunitario a la corrección de Canonical

Hay que reconocerlo: el fallo no surgió en Canonical. El proyecto Incus —el fork comunitario de LXD— lo encontró y lo reportó, y luego publicó su propia corrección en Incus 7.6.0, junto con otras 17 incidencias de seguridad. Canonical confirmó que el mismo fallo afectaba a LXD, que había heredado esa ruta de código. Los forks funcionan en ambos sentidos: el código compartido implica vulnerabilidades compartidas, y quien audita primero le hace un favor a todos.

El 30 de octubre, el registro CVE de CVE-2026-112816 incluía una evaluación de CISA: no se sabe que el fallo se haya explotado y no se ha añadido al catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA. No se ha publicado ningún exploit funcional. Esa es la situación a día de hoy: una técnica de ataque totalmente documentada, una corrección pública y ningún abuso confirmado en la naturaleza. La ventana entre «descrito públicamente» y «armado» es donde los defensores parchean o luego explican por qué no lo hicieron.

Las versiones snap corregidas de Canonical son LXD 6.10.1 (canal 6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) y 4.0.15 (4.0/stable), además de MicroCloud 3.4.1 (3/stable) y 2.1.5 (2/stable). El registro CVE indica que las versiones afectadas son LXD 4.0.14, 5.0.10, 5.21.8 y 6.9, y que cada una sigue siendo vulnerable hasta la versión menor siguiente. Hay un matiz: Canonical señaló que las versiones menores corregidas de LXD seguían llegando del canal candidate al stable cuando se publicó su aviso, así que actualizar no garantiza la corrección; verifica la versión que realmente has instalado. Los paquetes deb de LXD del archivo de Ubuntu figuran como no afectados o no distribuidos; aquí el vehículo son los snaps.

¿Encaja CVSS 10.0? Sí y no

A favor de 10.0: es un bypass completo de autenticación, sin interacción del usuario, de baja complejidad, con un impacto que llega hasta root en el host. La técnica es sencillísima: cualquiera que haya pegado alguna vez una cadena de certificados en un archivo PEM tiene las habilidades necesarias.

En contra: ambas condiciones previas reducen de forma real el radio de impacto. Un servidor LXD independiente no expone la API por defecto; escucha en un socket Unix local, salvo que un administrador configure explícitamente core.https_address. Además, hace falta el certificado público de un cliente de confianza, que no es secreto pero tampoco se difunde en internet abierta. La exposición más seria es la de MicroCloud: Canonical indicó que un atacante capaz de capturar el certificado público de un miembro cuando se une al clúster puede después iniciar sesión como ese miembro. El tráfico de arranque del clúster es justo el tipo de tráfico que atraviesa redes de gestión, así que «público pero difícil de obtener» se convierte en «capturado una vez, reproducible para siempre».

Mi lectura: si tu API de LXD es accesible desde algo más que un segmento de gestión dedicado, trátalo como un parche prioritario que hay que aplicar ya. Si solo usa socket, estás parcheando por higiene, no por pánico. El 10.0 describe el fallo; tu topología de red describe tu riesgo.

Sin solución alternativa: parchea o aísla el listener

El aviso de Canonical no ofrece una configuración temporal para LXD, y el proyecto Incus fue muy directo sobre su propio código: no hay solución por configuración, y el único paso provisional es restringir el acceso de red al listener. Esto indica que el fallo está en la propia lógica de verificación, no en un parámetro que puedas ajustar. En instalaciones con snap, la remediación son dos comandos y una comprobación de versión:

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud   # confirm you actually got the fixed point release

Ya que estás, responde con honestidad a la pregunta de exposición:

• Ejecuta lxc config get core.https_address en cada host. Un valor vacío significa solo socket local: la explotación remota queda descartada para esa máquina.
• Si la API debe seguir accesible por red, restríngela a una VLAN de gestión o a una lista de permitidos en el cortafuegos hasta que el snap parcheado llegue al canal stable de tu rama.
• En MicroCloud, trata el tráfico de unión al clúster como sensible: un observador en la ruta que capture el certificado público de un miembro que se une ya ha cumplido la mitad de los requisitos del ataque.
• Los equipos que usan Incus deben pasar a la 7.6.0, que cierra este fallo y otras 17 incidencias de seguridad en una sola versión.
• Tras parchear, revisa las entradas del almacén de confianza y la pertenencia al clúster en busca de identidades que no reconozcas: es un seguro barato por si alguien entró antes de la corrección.

Si la cuenta suplantada es privilegiada, el atacante podría obtener «acceso root a la máquina host», según Canonical.

La lección más amplia es una que aparece una y otra vez en el código de autenticación, desde la RCE por regex en GitLab con CVSS 10 hasta este caso: la comprobación que parece exhaustiva —validar todos los certificados de la cadena— puede ser peor que una estrecha, porque genera una falsa confianza en una suposición rota. TLS demuestra la posesión de la clave solo para el leaf y nada más. Cualquier decisión de confianza basada en certificados más abajo en la cadena necesita su propia prueba, y aquí no había ninguna. Incus lo detectó, Canonical lo corrigió, y ahora la única pregunta es si tu actualización llega antes de que lo haga el exploit de otro.