CVE-2026-112816: Bypass de Autenticación Crítica en LXD y MicroCloud Permite la Toma de Control del Clúster

Canonical ha lanzado actualizaciones de seguridad para abordar el CVE-2026-112816, una vulnerabilidad crítica de omisión de autenticación que afecta a LXD y MicroCloud. El fallo tiene un puntaje máximo de CVSS de 10.0 y puede permitir que un atacante remoto no autenticado se haga pasar por un cliente de TLS de confianza sin poseer la clave privada de ese cliente.

La explotación exitosa puede proporcionar acceso a la API de LXD o MicroCloud con los privilegios asignados a la identidad suplantada. Cuando la identidad de confianza tiene permisos suficientes, un atacante puede obtener acceso completo al clúster, a las máquinas virtuales administradas y posiblemente acceso a nivel root al host subyacente.

La vulnerabilidad surge de la validación inadecuada de las cadenas de certificados de cliente utilizadas para la autenticación TLS mutua. En lugar de autenticar solo el certificado de hoja para el cual el cliente demuestra la posesión de la clave privada correspondiente, las implementaciones vulnerables comparan cada certificado suministrado en la cadena controlada por el cliente con los certificados de confianza.

Un atacante que puede acceder a la API HTTPS y obtener el certificado público de un cliente ya confiable puede, por lo tanto, anexar ese certificado detrás de un certificado de hoja controlado por el atacante y ser aceptado como la identidad de confianza.

Canonical divulgó el problema a finales de octubre de 2026 después de que la vulnerabilidad fuera referida por el proyecto Incus. Las versiones fijas de LXD y MicroCloud ya están disponibles, y se recomienda encarecidamente a los administradores que actualicen de inmediato.

La falla es especialmente significativa en entornos de infraestructura porque LXD gestiona contenedores del sistema y máquinas virtuales, mientras que MicroCloud coordina la infraestructura agrupada. La compromisión de una identidad administrativa puede extenderse más allá de un solo servicio y proporcionar control sobre cargas de trabajo o el propio host.

Para la detección del CVE-2026-112816, los equipos de seguridad deben priorizar la identificación de APIs HTTPS de LXD y MicroCloud accesibles desde internet o la red, revisar los certificados de cliente de confianza y correlacionar la autenticación exitosa basada en certificados con sistemas fuente inesperados u operaciones administrativas inusuales.

La Plataforma de Inteligencia de Detección Nativa de AI de SOC Prime permite a los equipos de seguridad fortalecer la cobertura para el comportamiento de explotación y post-compromiso en la telemetría de red, Linux, nube, contenedor e identidad.

Contactar a Ventas

Haga clic en Explorar Detecciones para acceder al contenido de detección relevante y a la lógica de caza. Para Detectar CVE-2026-112816, los defensores deben combinar el inventario de versiones vulnerables con el monitoreo de acceso a la API, la telemetría de autenticación de certificados y la actividad administrativa sospechosa que afecta a los contenedores, las máquinas virtuales o la configuración del clúster.

Análisis del CVE-2026-112816

El CVE-2026-112816 es una vulnerabilidad de validación incorrecta de certificados en el listener HTTPS utilizado por Canonical LXD y MicroCloud.

Ambos productos pueden usar TLS mutuo para autenticar clientes remotos. Bajo el comportamiento normal de mTLS, el cliente que se conecta presenta un certificado y demuestra la propiedad de la clave privada asociada con el certificado utilizado como la hoja de la cadena TLS.

El problema surge porque las implementaciones vulnerables de LXD y MicroCloud inspeccionan más que solo ese certificado de hoja autenticado.

Según Canonical, la lógica de autenticación de la API remota comparó todos los certificados presentados por un cliente con entradas en el almacén de certificados de confianza. Sin embargo, TLS demuestra posesión de la clave privada solo para el certificado de hoja. Los certificados adicionales en la cadena presentada son suministrados por el cliente y no prueban de forma independiente la propiedad de sus claves privadas correspondientes.

Esto crea una brecha de autenticación.

Un atacante puede generar un certificado y una clave privada que controlan, usar ese certificado como hoja y añadir el certificado público de un cliente confiable en otro lugar de la cadena presentada. El servidor vulnerable puede encontrar el certificado de confianza y asociar la conexión con esa identidad confiable aunque el atacante no posea su clave privada.

Por lo tanto, los detalles para CVE-2026-112816 muestran que la explotación depende principalmente de dos requisitos previos:

• El atacante puede acceder a la API HTTPS de LXD o MicroCloud.
• El atacante posee el certificado público de una identidad ya confiable por el objetivo.

No se requiere la clave privada del cliente de confianza.

Esta distinción explica la gravedad crítica de la vulnerabilidad. Se espera que la autenticación basada en certificados demuestre la posesión de una clave privada secreta, pero la lógica afectada permite efectivamente que la posesión del certificado público solo satisfaga parte de la decisión de confianza.

Una instalación de LXD independiente no expone su API HTTPS remota por defecto. The Hacker News señala que LXD normalmente escucha solo en su socket Unix local a menos que un administrador habilite el acceso a la red, por ejemplo, a través de la configuración core.https_address.

Esto significa que no todas las instalaciones vulnerables de LXD son explotables remotamente desde otro host.

La exposición se vuelve significativamente mayor cuando los administradores habilitan la API a través de una red de gestión o la exponen a internet.

MicroCloud presenta otro escenario de ataque relevante. Canonical afirma que un atacante que pueda interceptar el certificado TLS público de una máquina que se une a un clúster de MicroCloud puede posteriormente autenticarse como ese miembro unido.

CVE-2026-112816 afecta las versiones vulnerables de Canonical LXD incluidas las 4.0.14, 5.0.10, 5.21.8 y 6.9 antes de sus correspondientes lanzamientos corregidos.

Canonical enumera estas versiones parchadas de LXD:

• LXD 6.10.1 para el canal 6/estable
• LXD 5.21.9 para 5.21/estable
• LXD 5.0.11 para 5.0/estable
• LXD 4.0.15 para 4.0/estable

Para MicroCloud, las versiones corregidas son:

• MicroCloud 3.4.1 para 3/estable
• MicroCloud 2.1.5 para 2/estable

El registro CVE de Ubuntu describe la explotación exitosa como permitir a un atacante no autenticado autenticarse como un cliente de confianza y obtener acceso completo al clúster y a las máquinas virtuales administradas a través de una cadena de certificados manipulada.

La puntuación máxima de CVSS de 10.0 refleja la accesibilidad a la red, la baja complejidad del ataque, sin privilegios requeridos y sin necesidad de interacción del usuario, combinados con un impacto potencialmente alto en la confidencialidad, integridad y disponibilidad.

El impacto depende en última instancia de los privilegios de la identidad que se está suplantando.

Una identidad restringida puede proporcionar capacidades limitadas de API. Un cliente o identidad de clúster altamente privilegiada puede proporcionar acceso sustancialmente mayor.

Canonical advierte explícitamente que la suplantación de un usuario privilegiado de confianza puede resultar en acceso root a la máquina host.

Eso puede potencialmente permitir a un atacante:

• Gestionar o modificar contenedores y máquinas virtuales.
• Acceder a cargas de trabajo gestionadas a través del entorno LXD comprometido.
• Modificar la configuración de la infraestructura.
• Crear nuevas cargas de trabajo o alterar las existentes.
• Interferir con la disponibilidad.
• Acceder a datos disponibles para la identidad suplantada.
• Potencialmente alcanzar el host con privilegios a nivel de root cuando hay permisos suficientes disponibles.

El fallo fue identificado originalmente en el proyecto relacionado con Incus y luego referido a Canonical, que confirmó que el mismo problema de autenticación de cadena de certificados afectaba a LXD.

Incus describe el problema subyacente de manera similar: el servidor solicitó certificados de cliente sin verificar toda la cadena enviada, mientras que las comprobaciones de confianza iteraron a través de cada certificado de igual suministrado en lugar de restringir la autenticación al certificado de hoja real. Incus abordó el problema en la versión 7.6.0.

La vulnerabilidad parece haber existido durante un periodo prolongado. Incus afirma que la lógica de autenticación equivalente había estado presente desde su lanzamiento inicial. El aviso público de Canonical no proporciona una fecha exacta en la que se introdujo por primera vez el comportamiento vulnerable de LXD.

A partir del 2 de noviembre de 2026, se ha publicado públicamente un PoC independiente y una reproducción en laboratorio para CVE-2026-112816. Esto representa un cambio con respecto al informe de The Hacker News publicado el 1 de noviembre, que afirmaba que aún no se había lanzado un exploit funcional. La reproducción pública apareció después de la divulgación y no es la investigación original de la vulnerabilidad.

Canonical y el informe referenciado no han indicado que la vulnerabilidad haya sido explotada en ataques reales.

The Hacker News informa que no se sabía que el problema había sido explotado a partir de la evaluación de CISA de EE.UU. fechada el 30 de octubre y no se incluyó en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA en ese momento.

Por lo tanto, no hay IOCs específicos de campaña para CVE-2026-112816, como direcciones IP maliciosas confirmadas, dominios, hashes de malware o infraestructura de atacante conocida asociada con la explotación.

Los defensores deben centrarse en cambio en la exposición a la vulnerabilidad y el comportamiento.

Las oportunidades potenciales de caza incluyen:

• Conexiones remotas a APIs HTTPS de LXD o MicroCloud desde sistemas inesperados.
• Autenticación exitosa de la API originando desde redes no utilizadas normalmente por administradores de confianza.
• Una identidad de certificado de confianza apareciendo desde múltiples sistemas fuente no relacionados.
• Actividad de la API administrativa que no coincide con el propietario esperado de un certificado.
• Creación, eliminación o modificación inesperadas de contenedores y máquinas virtuales.
• Cambios en las entradas de certificados de confianza.
• Nuevos o alterados miembros del clúster.
• Cambios inesperados en almacenamiento, redes, perfiles, proyectos o configuración de instancias.
• Operaciones privilegiadas que ocurren poco después de una autenticación basada en certificados inusual.
• Conexiones API con interfaces de gestión que no estaban destinadas a ser accesibles remotamente.

Las organizaciones también deberían inventariar los certificados de confianza asociados con administradores anteriores, hosts retirados, sistemas de automatización y miembros del clúster.

Debido a que la explotación requiere el certificado público en lugar de la clave privada, los defensores no deben tratar la confidencialidad de las claves privadas como una protección suficiente contra esta vulnerabilidad específica.

La monitorización también debería considerar las redes compartidas de gestión.

Una API que no está expuesta directamente a internet todavía puede ser explotable por un atacante que ya haya obtenido un punto de apoyo en otro sistema capaz de llegar a la interfaz de gestión.

Esto hace que el movimiento lateral sea particularmente relevante. Una estación de trabajo comprometida, servidor, corredor CI/CD, host de gestión o carga de trabajo en la nube con acceso a la red a la API de LXD podría proporcionar la posición necesaria para explotar un sistema expuesto de forma interna.

Mitigación del CVE-2026-112816

Canonical recomienda actualizar inmediatamente las implementaciones afectadas de LXD y MicroCloud a las últimas versiones corregidas.

Para las implementaciones basadas en Snap, los administradores pueden actualizar usando:

sudo snap refresh lxd

y:

sudo snap refresh microcloud

Después de actualizar, verifique la versión realmente instalada en lugar de asumir que la actualización se aplicó con éxito.

Canonical señaló durante la divulgación que algunas versiones puntuales de LXD estaban progresando de los canales candidatos a los estables. Los administradores deben confirmar explícitamente que su sistema está ejecutando una de las versiones corregidas.

La principal mitigación del CVE-2026-112816 es actualizar a:

Producto	Versión corregida
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical no ha publicado una solución basada en configuración que elimine por completo el defecto subyacente de autenticación.

Si es imposible actualizar de inmediato, restrinja el acceso a la red a la API HTTPS de manera tan agresiva como lo permitan los requisitos operacionales.

Solo los hosts de gestión autorizados y la infraestructura de confianza deben poder establecer conexiones con el listener.

Para las instalaciones de LXD que no requieren gestión remota, los administradores deben evaluar si la API de red necesita permanecer habilitada en absoluto.

Para entornos que requieren acceso remoto:

• Restrinja la API usando firewalls de host o de red.
• Permita conexiones solo desde redes de gestión dedicadas.
• Evite exponer la API directamente a internet.
• Use acceso administrativo basado en VPN o bastión donde sea apropiado.
• Segmente la infraestructura de gestión de contenedores y virtualización de las redes de usuario.
• Monitoree todas las solicitudes API administrativas exitosas.
• Revise los certificados de confianza y elimine las entradas que ya no sean necesarias.

Estos controles reducen la exposición pero no corrigen la lógica de validación de certificados vulnerable.

Las organizaciones que ejecutan MicroCloud deben priorizar la actualización de todos los miembros relevantes del clúster y revisar la actividad de incorporación reciente en busca de sistemas o identidades de certificado inesperados.

Los administradores también deben revisar sus almacenes de certificados de confianza.

Elimine certificados pertenecientes a hosts desmantelados, administradores anteriores, sistemas de automatización no usados, o identidades que ya no requieran acceso.

Cuando se descubra actividad sospechosa, investigue el host afectado y el clúster antes de rotar credenciales o modificar evidencia.

Fuentes relevantes de telemetría pueden incluir:

• Registros de servicio de LXD y MicroCloud
• Registros del sistema Linux
• Registros de flujo de red y firewall
• Telemetría de proxy inverso, si aplica
• Datos de EDR de host
• Registros de red en la nube
• Historial de configuración y membresía del clúster
• Registros de cambios administrativos

Busque creación, modificación, eliminación, actividad de snapshot, operaciones de almacenamiento, cambios de red y actualizaciones de configuración inesperadas de instancias.

Si se sospecha de explotación y se suplantó una identidad de certificado privilegiado, los defensores deben tratar seriamente el compromiso potencial a nivel del host porque Canonical confirma que el acceso root puede ser posible dependiendo de los permisos de la identidad de la víctima.

Los respondedores de incidentes deben preservar la evidencia relevante e inspeccionar el sistema en busca de persistencia, cuentas o certificados no autorizados, servicios modificados, nuevas cargas de trabajo, procesos sospechosos y comunicación de red saliente anormal.

Las organizaciones que utilicen Incus en lugar de Canonical LXD deben actualizar por separado a Incus 7.6.0 o la versión corregida soportada relevante, ya que el proyecto relacionado fue afectado por el mismo problema subyacente de confianza en la cadena de certificados.

Ubuntu también señala que sus versiones de LXD empacadas en archivos para las versiones actualmente listadas de Ubuntu no se envían a través de la ruta de paquetes afectada o no están afectadas, mientras que la guía de seguridad de Canonical se centra en las versiones Snap. Los administradores aún deben verificar la distribución real de LXD y la versión que se ejecuta en su entorno en lugar de asumir la exposición según la versión de Ubuntu solamente.

Exención de responsabilidad: El contenido de detección puede no estar disponible para todos los CVE. Verifique la Plataforma SOC Prime para conocer la cobertura actual. Si las detecciones relevantes aún no están disponibles, vuelva a verificar ya que se siguen añadiendo continuamente nuevos contenidos de inteligencia de amenazas y detecciones.