Vulnerabilidad en LXD y MicroCloud con CVSS 10.0 permite a atacantes suplantar clientes de confianza sin clave privada.

⟫ 01/11/2026 ⟫ info@thehackernews.com (The Hacker News)

Fuente: The Hacker News

**Vulnerabilidad Crítica en LXD y MicroCloud de Canonical: Un Riesgo para la Seguridad de los Sistemas Virtuales**

En un entorno digital cada vez más interconectado, la seguridad de los sistemas de virtualización es de vital importancia. La reciente detección de una vulnerabilidad crítica en LXD y MicroCloud de Canonical resalta la importancia de proteger los accesos a estos entornos. Esta falla permite a un atacante autenticarse como un cliente de confianza sin poseer la clave privada correspondiente, lo que podría tener consecuencias devastadoras para la integridad y la disponibilidad de los sistemas afectados. La magnitud de esta vulnerabilidad no solo afecta a los usuarios individuales, sino que también representa un riesgo significativo para organizaciones que dependen de la virtualización para sus operaciones diarias.

La vulnerabilidad, catalogada como CVE-2026-112816, ha sido evaluada con la puntuación máxima en el Sistema de Puntuación de Vulnerabilidades Comunes (CVSS), con un total de 10.0. Esto indica la gravedad de la falla y su potencial para ser explotada en entornos de producción. Canonical, la empresa detrás de estas tecnologías, ha lanzado versiones corregidas de ambos productos, LXD y MicroCloud, pero es fundamental comprender los mecanismos subyacentes que permitieron esta brecha de seguridad.

LXD y MicroCloud facilitan el acceso remoto a sus APIs mediante TLS mutuo, un protocolo de seguridad que requiere que el cliente presente un certificado para autenticar su identidad. Un cliente es considerado de confianza cuando su certificado se encuentra en el almacén de confianza del servidor, que es la lista de identidades aceptadas por este último. Sin embargo, la vulnerabilidad radica en la manera en que el servidor valida este certificado. El servidor compara cada certificado proporcionado por el cliente con el almacén de confianza, pero una conexión TLS solo valida que el cliente posee la clave privada del primer certificado en la cadena, conocido como el certificado "leaf". Los certificados adicionales de la cadena pueden ser elegidos arbitrariamente por el cliente.

Esto significa que un atacante podría tomar el certificado público de un cliente de confianza, que no es secreto, adjuntarlo a su propia cadena de certificados y engañar al servidor para que lo acepte como ese cliente legítimo. Para explotar esta vulnerabilidad, el atacante necesita tener acceso a la red para llegar a la API HTTPS y poseer el certificado público de un cliente ya confiable.

Es importante señalar que un servidor LXD independiente no expone la API por defecto; esta solo escucha en un socket local a menos que un administrador active la API de red mediante la configuración `core.https_address`. Sin embargo, MicroCloud, que agrupa varias máquinas que ejecutan LXD en un solo clúster, presenta un punto débil específico. Canonical ha advertido que un atacante que logre capturar el certificado público de un miembro al unirse al clúster podría iniciar sesión como ese miembro.

Los registros de CVE indican que las versiones afectadas de LXD incluyen la 4.0.14, 5.0.10, 5.21.8 y 6.9, todas anteriores a las versiones corregidas que se han lanzado. Canonical ha proporcionado las versiones de snap corregidas, subrayando la importancia de actualizar a estas versiones para mitigar el riesgo de explotación.

Es relevante mencionar que la vulnerabilidad no se originó en Canonical. El proyecto Incus, que comenzó como un fork comunitario de LXD, fue el que reportó la falla, y Canonical confirmó que también afectaba a LXD. Incus ha corregido la misma vulnerabilidad en su versión 7.6.0. Las versiones de paquetes archivados de LXD de Ubuntu no están afectadas o no se han distribuido, lo que significa que las versiones corregidas son las de snap.

Hasta la fecha, no hay evidencia pública de que esta vulnerabilidad haya sido utilizada en un ataque real. El registro de CVE incluye una evaluación de la Agencia de Seguridad Cibernética e Infraestructura de EE. UU. (CISA), datada el 30 de octubre, indicando que la falla no se conoce por haber sido explotada y no figura en la lista de Vulnerabilidades Conocidas Explotadas de CISA. Además, no se ha publicado ningún exploit funcional.

Para protegerse, se recomienda encarecidamente actualizar LXD y MicroCloud a las versiones corregidas. Para aquellos que utilizan una instalación de snap, se debe ejecutar `sudo snap refresh lxd` y `sudo snap refresh microcloud`. Canonical ha indicado que las versiones de LXD corregidas se estaban distribuyendo desde el canal candidato al canal estable en el momento de su aviso, por lo que es crucial verificar la versión tras la actualización en lugar de asumir que la corrección ya está presente.

El aviso de Canonical no proporciona una solución temporal para LXD. Dado que el ataque requiere acceso a la red para la API, limitar quién puede acceder a ella reduce el riesgo hasta que se realice la actualización. El proyecto Incus, que reportó la misma vulnerabilidad, ha afirmado que no hay una solución de configuración, y la única medida viable es restringir el acceso a la red al oyente.

Los usuarios de Incus deben actualizar a la versión 7.6.0, que corrigió esta falla junto con otros 17 problemas de seguridad. La gestión proactiva de la seguridad en sistemas de virtualización es esencial para prevenir incidentes críticos que puedan comprometer la integridad de la infraestructura tecnológica.

◢ VULNERABILIDADES ◣

CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key

⟫ 01/11/2026 ⟫ info@thehackernews.com (The Hacker News)

Source: The Hacker News

A critical flaw in Canonical's LXD and MicroCloud let an attacker log in as a trusted client without holding that client's private key. To do it, the attacker had to reach their HTTPS API over the network and have the trusted client's public certificate. Once in, the attacker would act as that client, with access to the cluster and its virtual machines. If the impersonated account is privileged, the attacker could gain "root access to the host machine," Canonical said. The flaw, tracked asCVE-2026-112816, carries a maximum CVSS score of 10.0, and Canonical hasreleased fixed versionsof both products. LXD and MicroCloud let remote clients access their APIs over mutual TLS, a setup in which the client presents a certificate to prove who it is. A client is trusted when its certificate is in the server's trust store, the list of identities the server will accept. The flaw was in how the server checked that certificate. It compared every certificate the client sent against the trust store, but a TLS connection only proves the client owns the private key for the first certificate in the chain, the leaf. The rest of the chain is whatever the client chose to attach. So an attacker could take a trusted client's public certificate, which is not secret, attach it to the chain behind their own, and the server would accept them as that client. Using the flaw takes two things: network access to the HTTPS API, and the public certificate of a client the server already trusts. A standalone LXD server does not expose that API by default. It listens only on a local socket unless an administrator turns on the network API with the core.https_address setting. MicroCloud, which ties several machines running LXD into one cluster, has a specific weak point. Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member. The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before the fixed release that follows. Canonical lists these fixed snap versions: The bug did not start at Canonical. The Incus project, which began as a community fork of LXD,reported it, and Canonical confirmed it affected LXD as well. Incus fixed the same flaw in version 7.6.0. Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps. There is no public sign the flaw has been used in an attack. The CVE record carries a U.S. CISA assessment, dated October 30, that the flaw is not known to have been exploited; it is not on CISA's Known Exploited Vulnerabilities list, and no working exploit has been published. Update LXD and MicroCloud to the fixed versions. On a snap install, run sudo snap refresh lxd and sudo snap refresh microcloud. Canonical said the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, so check the version you actually have after the refresh rather than assume the fix arrived. Canonical's advisory gives no temporary workaround for LXD. Because the attack requires network access to the API, limiting who can reach it reduces risk until you update. The Incus project, reporting the same flaw, said there is no configuration fix and that the only step is to restrict network access to the listener. Incus users should move to7.6.0, which fixed this flaw along with 17 other security issues.

← VOLVER A CIBERSEGURIDAD