Canonical ha publicado parches para CVE-2026-112816, una vulnerabilidad crítica en los productos LXD y MicroCloud que permite a un atacante autenticarse como cualquier cliente TLS de confianza y obtener acceso completo al clúster y a las máquinas virtuales gestionadas. Para explotarla basta con tener acceso de red al HTTPS API y el certificado público de un cliente de confianza; no se requiere la clave privada. Si la cuenta comprometida tiene privilegios, el atacante puede obtener acceso root a la máquina host. Los administradores de LXD y MicroCloud deben actualizar inmediatamente los paquetes snap a las versiones corregidas.
Mecanismo de la vulnerabilidad
LXD y MicroCloud usan mutual TLS para autenticar a los clientes remotos: el cliente presenta un certificado, y el servidor comprueba su presencia en el almacén de identidades de confianza (trust store). El problema residía en cómo exactamente realizaba el servidor esta comprobación.
Según el aviso de seguridad de Canonical, la lógica de autenticación comparaba todos los certificados enviados por el cliente en la cadena con las entradas del trust store. Sin embargo, el handshake TLS solo confirma la posesión de la clave privada para el primer certificado de la cadena, el de hoja (leaf). El cliente controla por completo el resto de certificados de la cadena.
Esto significa que un atacante podía formar una cadena de certificados colocando su propio certificado de hoja en primer lugar y el certificado público de un cliente de confianza como intermedio. El servidor encontraba el certificado de confianza en la cadena y aceptaba la conexión en nombre de ese cliente, aunque el atacante no poseyera su clave privada.
Versiones afectadas y parches
Según la página del CVE en Ubuntu, las siguientes versiones de LXD son vulnerables:
- LXD 4.0.14 (corregido en 4.0.15)
- LXD 5.0.10 (corregido en 5.0.11)
- LXD 5.21.8 (corregido en 5.21.9)
- LXD 6.9 (corregido en 6.10.1)
Para MicroCloud, Canonical ha publicado las versiones corregidas 2.1.5 y 3.4.1. Todos los parches están fechados el 29 de octubre de 2026 y se distribuyen a través de los canales snap.
La vulnerabilidad no fue descubierta por la propia Canonical. El proyecto Incus, un fork de LXD desarrollado por la comunidad, fue el primero en informar del problema, tras lo cual Canonical confirmó que el mismo error afectaba a LXD. Incus corrigió la vulnerabilidad en la versión 7.6.0; se trata de un producto independiente, y su versión no sustituye a las actualizaciones de LXD ni de MicroCloud.
Aclaración sobre la valoración de criticidad
En varias publicaciones se atribuye a la vulnerabilidad una puntuación CVSS de 10.0. Sin embargo, el aviso de Canonical para LXD y MicroCloud califica el problema como crítico sin indicar una puntuación numérica. La puntuación 10.0 sí aparece explícitamente en el aviso de seguridad de Incus para la misma vulnerabilidad en la cadena de certificados. Dado que se trata del mismo tipo de error, la valoración es aplicable en esencia, pero formalmente ha sido asignada por el proyecto Incus y no por Canonical.
Diferencias en los vectores de ataque: LXD y MicroCloud
Los caminos prácticos de explotación difieren según el producto. Para un servidor LXD autónomo, el ataque requiere que el HTTPS API sea accesible por red, algo que no ocurre por defecto: escucha solo en un socket local, salvo que el administrador haya activado el parámetro core.https_address.
MicroCloud, que agrupa varias máquinas con LXD en un único clúster, crea un vector adicional: según Canonical, un atacante capaz de interceptar el certificado TLS público de un nodo en el momento en que se une al clúster puede, posteriormente, autenticarse en nombre de ese nodo. Esto convierte el procedimiento de incorporación de nuevos miembros al clúster en un punto especialmente sensible.
A la hora de mitigar la vulnerabilidad, se debe dar prioridad a las instalaciones con listeners del API abiertos y a los entornos donde se estén realizando operaciones de ampliación del clúster.
Estado de explotación
Según los datos disponibles, no se han detectado indicios de explotación activa de la vulnerabilidad. CVE-2026-112816 no figura en el catálogo CISA Known Exploited Vulnerabilities, y no se han publicado exploits de forma pública. No obstante, la ausencia en el catálogo KEV no constituye por sí sola una prueba de que no se haya producido explotación.
Recomendaciones
Para mitigar la vulnerabilidad:
- Actualice los paquetes snap:
sudo snap refresh lxdysudo snap refresh microcloud - Tras la actualización, compruebe la versión efectiva: en el momento de la publicación del aviso de Canonical, los parches para LXD se encontraban en fase de transición gradual desde el canal
candidateastable - Los usuarios de Incus deben actualizar a la versión 7.6.0
No existe una solución temporal de configuración; así lo indican explícitamente tanto Canonical como el proyecto Incus. Hasta instalar la actualización, la única medida de reducción de riesgo es restringir el acceso de red al listener HTTPS a hosts de confianza.
Ya antes hemos tratado vulnerabilidades críticas en el ecosistema Ubuntu, por ejemplo, la vulnerabilidad de escalada de privilegios pedit COW en el kernel de Linux. CVE-2026-112816 se diferencia en que el ataque no se dirige al kernel, sino a la capa de orquestación de contenedores y máquinas virtuales, lo que en caso de éxito proporciona acceso a todo el clúster de una sola vez.
Dado que no existen soluciones temporales y el posible alcance de la intrusión abarca desde el acceso a las máquinas virtuales hasta el root del host, la actualización de los paquetes snap de LXD y MicroCloud a las versiones corregidas es la única medida de protección completa y debe aplicarse sin demora, especialmente en las instalaciones con API de red expuesto.
