Canonical ha publicado correcciones para un fallo en la comprobación de certificados que permite a los atacantes suplantar a clientes confiables de LXD y MicroCloud sin sus claves privadas, según informa The Hacker News. El aviso de seguridad de Ubuntu del 30 de octubre identifica la vulnerabilidad de LXD como CVE-2026-112816, que puede dar a un atacante no autenticado acceso completo a un clúster y a sus máquinas virtuales gestionadas.
La explotación requiere acceso de red a la API HTTPS, la interfaz cifrada que se usa para gestionar el servicio, y al certificado público de una identidad en la que confía el servidor. El atacante obtiene el acceso de esa identidad. Según declaraciones de Canonical recogidas por The Hacker News, suplantar a una cuenta con privilegios también podría dar acceso root a la máquina host.
Las instalaciones independientes de LXD no exponen esta interfaz de red de forma predeterminada. Escuchan en un socket local, a menos que un administrador habilite el acceso de red mediante core.https_address. MicroCloud, que combina máquinas que ejecutan LXD en un clúster, tiene una exposición particular: Canonical explicó que un atacante que capture el certificado público de un miembro mientras este se une al clúster puede suplantar después a ese miembro.
La vulnerabilidad tiene una puntuación máxima de gravedad en el Common Vulnerability Scoring System de 10,0, mientras que Ubuntu le asigna una prioridad de corrección distinta, Media. The Hacker News informa de que una evaluación de CISA del 30 de octubre, incluida en el registro CVE, describió la explotación como no conocida. El fallo no figuraba en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA, y no se había publicado ningún exploit funcional.
Cómo un certificado público se convierte en un inicio de sesión
LXD y MicroCloud admiten TLS mutuo, una configuración de conexión en la que los clientes presentan certificados para establecer su identidad. Los servidores guardan las identidades aceptadas en un almacén de confianza. Un certificado público no es secreto; se supone que su clave privada correspondiente demuestra que el cliente es el propietario de la identidad.
El fallo rompe esa distinción. Durante la configuración de la conexión, TLS solo demuestra la posesión de la clave privada del primer certificado presentado, llamado certificado hoja (leaf). Sin embargo, las comprobaciones de autenticación vulnerables comparaban todos los certificados de la cadena del cliente con el almacén de confianza, incluidos los certificados adicionales que el cliente podía adjuntar libremente.
Por tanto, un atacante podía presentar primero su propio certificado y añadir después el certificado público de un cliente confiable. El servidor aceptaría la identidad confiable aunque el atacante no tuviera su clave privada.
El proyecto Incus, una bifurcación comunitaria de LXD, informó del problema, y Canonical confirmó que LXD también estaba afectado, según The Hacker News. Incus publicó su propio aviso de seguridad el 29 de octubre, un día antes del aviso de Ubuntu. Según el aviso, este comportamiento existe desde la primera versión de Incus y afecta a las versiones anteriores a la 7.6.0.
Incus describe rutas adicionales de acceso
El aviso de Incus detalla consecuencias dentro de ese producto que van más allá de suplantar a un cliente común. Cualquiera que pueda acceder a su escucha HTTPS puede suplantar a un cliente de confianza, una identidad de métricas o un certificado de servidor cuyo certificado público posea. Suplantar a un miembro del clúster evita por completo la autorización.
Obtener un certificado público adecuado puede no requerir acceso previo en Incus, ya que los servidores devuelven sus certificados durante cada negociación TLS. Añadir el propio certificado del servidor de destino concede acceso a la pasarela de la base de datos; añadir el certificado de otro miembro del clúster concede acceso interno al clúster. Los clientes de confianza también pueden recuperar certificados de cliente a través de la API de certificados, y se pueden obtener certificados de los servidores con los que esos clientes han contactado.
Incus afirma que el fallo también permite renovar o eliminar cualquier entrada del almacén de confianza mediante rutas de autoservicio, y que afecta a la autenticación de la conexión del agente entre los hosts y las máquinas virtuales.
Otra consecuencia afecta al script de autorización, un script que se usa para tomar decisiones de acceso. Incus pasaba la cadena de certificados sin verificar a ese script, lo que permitía que certificados elegidos por el atacante influyeran en sus decisiones. Esto también afecta a los clientes que se autentican mediante tokens o OpenID Connect, un método de inicio de sesión basado en identidad, porque aun así pueden presentar certificados arbitrarios durante la configuración de TLS.
Estos impactos detallados son hallazgos del aviso de Incus, que registra el problema como GHSA-xg75-xf37-cph9 y no indica ningún identificador CVE conocido.
Versiones corregidas y pasos para los administradores
El aviso de Ubuntu indica que LXD 4.0.14, 5.0.10, 5.21.8 y 6.9 están afectados antes de sus respectivas versiones corregidas. The Hacker News informa de estas versiones corregidas de los snaps, agrupadas por producto y canal:
- LXD
6/stable: 6.10.1. - LXD
5.21/stable: 5.21.9. - LXD
5.0/stable: 5.0.11. - LXD
4.0/stable: 4.0.15. - MicroCloud
3/stable: 3.4.1. - MicroCloud
2/stable: 2.1.5.
El estado de los paquetes del archivo de Ubuntu es independiente de estas instalaciones snap. Sus paquetes de LXD para Ubuntu 20.04, 18.04 y 16.04 están marcados como no afectados; LXD figura como no presente en las versiones 22.04, 24.04, 26.04 y 26.10.
Los administradores que usen snaps deben actualizar los productos instalados con sudo snap refresh lxd y sudo snap refresh microcloud. Canonical explicó que, cuando apareció su aviso, las versiones puntuales corregidas de LXD seguían pasando del canal candidate al canal stable, por lo que los administradores deben verificar la versión instalada después de actualizar.
The Hacker News informa de que el aviso de Canonical no ofrece ninguna solución temporal para LXD. Restringir el acceso de red a la API HTTPS reduce la exposición mientras se aplican las actualizaciones. Incus recomienda explícitamente limitar su escucha HTTPS a hosts de confianza y afirma que no existe una solución alternativa basada en la configuración. Los administradores de Incus deben actualizar a la 7.6.0, que corrige este fallo junto con otros 17 problemas de seguridad.
