Omisión de la autenticación mTLS en LXD e Incus (CVE-2026-112816)

TL;DR

• Una falla en la API HTTPS de Canonical LXD, MicroCloud e Incus permite que un atacante de red se autentique como cualquier cliente de confianza sin la clave privada de ese cliente. El proyecto Incus la reportó y Canonical confirmó que LXD y MicroCloud estaban afectados; Canonical publicó su aviso el 28 de octubre de 2026.
• Un demonio afectado y sin parche está expuesto si el atacante puede alcanzar su API HTTPS y obtener el certificado público de una identidad de confianza. Incus presenta certificados de servidor durante TLS; el aviso de MicroCloud describe interceptar el certificado de un miembro que se une. No se requiere autenticación, privilegios ni interacción del usuario.
• El registro CVE de Canonical lo clasifica como Critical, con CVSS v4.0 10.0. No se conoce ninguna explotación y no está en el catálogo KEV de CISA al 1 de noviembre de 2026. Los avisos citados no enlazan ninguna prueba de concepto pública.
• Actualice LXD y MicroCloud con sudo snap refresh lxd y sudo snap refresh microcloud, y lleve Incus a 7.6.0. Restringir quién puede alcanzar el listener HTTPS es la medida provisional recomendada, y no es una corrección.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Se ejecuta un demonio en los rangos afectados de la tabla siguiente: LXD, MicroCloud o Incus.
• Su API HTTPS escucha en una dirección de red que un atacante puede alcanzar. Un demonio LXD independiente sirve por defecto un socket Unix local y enlaza el listener de red solo cuando se configura una dirección, según su código de endpoints; los clústeres y los clientes remotos requieren la API de red.
• El atacante puede obtener el certificado público de una identidad de confianza. Los certificados del servidor se devuelven en cada negociación TLS, por lo que la vía de ataque más directa no necesita ningún acceso previo.

El aviso de Incus indica que el patrón defectuoso está presente desde la versión inicial, por lo que las instalaciones de Incus anteriores a 7.6.0 están afectadas.

Canonical distribuye LXD y MicroCloud como snaps; el archivo de Ubuntu no contiene ningún paquete LXD afectado, y el propio rastreador de Ubuntu clasifica el problema como Medium. Las versiones corregidas que se listan arriba son las versiones snap según el aviso de Canonical.

Compruebe qué ejecuta y si la API de red está activada:

snap list lxd
lxc version
lxc config get core.https_address
lxc config get cluster.https_address
snap list microcloud

Compruebe las direcciones de los listeners de API y clúster: una dirección API vacía no descarta un listener de clúster. Incus usa las mismas claves de configuración:

incus version
incus config get core.https_address
incus config get cluster.https_address

¿Cómo lo corrijo?

Actualice cada demonio LXD y MicroCloud a la versión corregida de su canal, e Incus a 7.6.0:

1. Actualice los snaps: sudo snap refresh lxd y sudo snap refresh microcloud.
2. Confirme que el demonio ejecuta realmente una versión corregida: snap list lxd junto con lxc version. Canonical indica que todas las versiones puntuales de LXD estaban en despliegue progresivo del canal candidate a stable cuando publicó el aviso, así que vuelva a comprobar tras actualizar en lugar de asumir que la corrección llegó.
3. Actualice Incus por su canal de paquetes a 7.6.0, que además corrige otros 17 problemas de seguridad según su anuncio de versión.

No existe ninguna mitigación por configuración. La medida provisional recomendada es restringir el acceso de red al listener HTTPS a hosts de confianza, como recomienda el aviso de Incus hasta que llegue la actualización. Su límite es claro: la falla permanece en el demonio y cualquier vía no confiable hacia el listener la deja abierta.

¿Cuál es la causa raíz?

Las comprobaciones de confianza comparaban cada certificado enviado por el cliente contra el almacén de confianza. Una negociación TLS solo demuestra que el cliente posee la clave privada del primer certificado de la cadena, y el resto de la cadena lo controla el cliente. El listener HTTPS de LXD e Incus pide un certificado de cliente con tls.RequestClientCert de Go, que solicita la cadena sin verificarla.

El demonio de Incus llevaba la forma más clara del defecto, en Authenticate en cmd/incusd/daemon.go antes de la versión 7.6.0:

    // Allow internal cluster traffic by checking against the trusted certficates.
    if r.TLS != nil {
        for _, i := range r.TLS.PeerCertificates {
            trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
            if trusted {
                return true, fingerprint, "cluster", nil, nil
            }
        }
    }

El mismo bucle sobre r.TLS.PeerCertificates se ejecutaba para los certificados de cliente normales y para los certificados de métricas, donde i es cada certificado presentado sucesivamente. r.TLS.PeerCertificates son todos los certificados que el cliente entregó, en el orden que el cliente eligió. CheckTrustState compara un certificado contra las entradas del almacén de confianza, así que el bucle convierte una cadena ensamblada por el cliente en una lista de identidades candidatas.

Añadir el certificado público de una identidad de confianza como elemento adicional de la cadena autentica por tanto al atacante como esa identidad. El certificado hoja demuestra quién es el atacante; el certificado añadido decide en quién cree el servidor que es.

¿Cómo se explota?

El ataque necesita una conexión TLS y un certificado público:

1. El atacante captura el certificado público de una identidad de confianza. Un certificado del servidor se obtiene de cualquier negociación TLS con el demonio, así que no hace falta ningún acceso previo. Un certificado de cliente puede leerlo cualquier cliente de confianza a través de la API de certificados, o recogerse de cualquier servidor al que ese cliente se conectó.
2. El atacante se conecta a la API HTTPS con su propio certificado y clave privada, y añade el certificado público capturado a la cadena presentada.
3. La negociación tiene éxito, porque el listener solo solicita la cadena y no verifica nada más allá de la clave de la hoja.
4. El bucle de confianza recorre la cadena presentada, hace coincidir el certificado añadido con una entrada del almacén de confianza y autentica al atacante como esa identidad.

La suplantación también funciona contra las rutas de certificado de autoservicio. El aviso indica que un cliente podía renovar o eliminar cualquier entrada del almacén de confianza. Indica también que la cadena sin verificar llegaba al scriptlet de autorización, lo que permitía a un cliente introducir certificados elegidos por el atacante en las decisiones del scriptlet. Los avisos citados no enlazan ninguna prueba de concepto pública. Nada de esto requiere más que acceso de red.

¿Cómo fluye el ataque?

Una única conexión al listener HTTPS, con el certificado público de la identidad de confianza colocado en la cadena, basta para convertirse en esa identidad.

¿Qué puede hacer un atacante?

El atacante hereda todo lo que la identidad suplantada puede hacer, en los productos afectados:

• Acceso completo al clúster y a sus máquinas virtuales gestionadas, según el registro CVE. Canonical indica que, cuando el usuario suplantado es privilegiado, el atacante puede obtener acceso root a la máquina anfitriona.
• Acceso a la pasarela de base de datos presentando el propio certificado del servidor, y acceso interno al clúster presentando el certificado de otro miembro, según el aviso de Incus. Suplantar a un miembro del clúster omite por completo la autorización.
• Renovación y eliminación de cualquier entrada del almacén de confianza por las rutas de autoservicio. La misma falla alimenta el scriptlet de autorización, así que un cliente puede influir en las decisiones del scriptlet. Esto incluye a los clientes por token u OpenID Connect, que aún pueden presentar un certificado arbitrario durante la negociación.
• Suplantación de la conexión del agente entre el host y las máquinas virtuales, que presenta la misma falla.

En MicroCloud, Canonical advierte que un atacante capaz de interceptar el certificado TLS público de un miembro mientras se une al clúster puede después autenticarse como ese miembro. Las condiciones siguen siendo las mismas: alcance de red a la API más un certificado público, sin privilegios ni interacción del usuario.

¿Por qué funciona la corrección?

La corrección pública de referencia es el commit de Incus 8381e54c3631c627d7ecdec03945bca14d0bd542, «Only trust the key-proven client certificate», escrito el 13 de octubre de 2026 por Stéphane Graber:

+   // The TLS listener only proves possession of the first peer certificate's key, so the rest of
+   // the presented chain is attacker-controlled and must never be matched against the trust store.
+   var peerCert *x509.Certificate
+   if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
+       peerCert = r.TLS.PeerCertificates[0]
+   }

Las comprobaciones de confianza se ejecutan entonces solo contra peerCert, sustituyendo cada bucle sobre r.TLS.PeerCertificates:

-   if r.TLS != nil {
-       for _, i := range r.TLS.PeerCertificates {
-           trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
-           if trusted {
-               return true, fingerprint, "cluster", nil, nil
-           }
-       }
-   }
+   if peerCert != nil {
+       trusted, fingerprint := localUtil.CheckTrustState(*peerCert, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
+       if trusted {
+           return true, fingerprint, "cluster", nil, nil
+       }
+   }

Un certificado añadido ya no puede coincidir con nada, porque solo se consulta la hoja que la negociación verificó realmente. El commit aplica la misma regla en cada ruta de confianza que el aviso enumera. Eso cubre la autenticación de la API, el registro de certificados con su renovación y eliminación de autoservicio, la conexión del agente host-máquina virtual por ambos lados, el scriptlet de autorización y el tráfico del clúster.

Para LXD y MicroCloud, el aviso de Canonical describe la misma corrección, y las versiones corregidas listadas en «¿Estoy afectado?» la incorporan.

¿Cómo compruebo si he sido comprometido?

Los avisos de los proveedores no publican indicadores de compromiso. Un almacén de confianza sin cambios no descarta la suplantación: un atacante puede usar una identidad existente sin crear otra entrada.

Empiece por buscar entradas inesperadas en el almacén de confianza y los miembros del clúster:

lxc config trust list

lxc cluster list

Revise cada entrada del almacén de confianza buscando un nombre, tipo o conjunto de proyectos inesperado. Preste especial atención a las entradas renovadas, porque la ruta de renovación de autoservicio forma parte de la falla. Si una identidad privilegiada pudo suplantarse en un host, trate ese host como comprometido. Evalúe todas las credenciales accesibles desde ese host, incluidas las claves privadas, y rote las que puedan haberse expuesto durante un compromiso. Reconstruya los hosts según su proceso de respuesta a incidentes.

Cronología

El commit de corrección de Incus se escribió 17 días antes de publicarse el CVE. La fecha de autoría no demuestra cuándo se hizo público el commit.

• 2023-07-22: El repositorio de Incus se crea como bifurcación de LXD. El aviso de Incus indica que el patrón defectuoso está presente desde la versión inicial.
• 2026-10-13: Stéphane Graber escribe la corrección de Incus, commit 8381e54c3631c627d7ecdec03945bca14d0bd542.
• 2026-10-19: Canonical reserva CVE-2026-112816.
• 2026-10-21: Canonical anuncia LXD 6.10.1, primera versión corregida de la rama 6.x.
• 2026-10-28: Canonical publica su aviso de seguridad con las versiones snap corregidas de LXD y MicroCloud.
• 2026-10-29: Incus publica GHSA-xg75-xf37-cph9. Las versiones snap corregidas de LXD y MicroCloud llevan la fecha del 29 de octubre de 2026.
• 2026-10-30: El registro CVE se publica y sale Incus 7.6.0. El ADP de CISA registra que no se conoce explotación, con fecha 30 de octubre de 2026.

Preguntas frecuentes

¿Por qué la negociación TLS no demuestra toda la cadena?

El listener pide un certificado de cliente con tls.RequestClientCert de Go, que solicita la cadena pero no la verifica. La negociación solo demuestra que el cliente posee la clave privada del primer certificado de la cadena; cada certificado posterior son datos que el cliente decidió adjuntar.

¿Una instalación LXD independiente con valores por defecto está expuesta?

No. Un demonio independiente sirve su socket Unix local. Solo enlaza el listener HTTPS cuando un administrador configura una dirección de red, así que la instalación por defecto no es alcanzable por la red. Los clústeres y cualquier cliente lxc remoto necesitan esa API de red.

¿Debo rotar mis certificados tras aplicar la corrección?

La divulgación del certificado público por sí sola no requiere rotación: ese certificado no es secreto. El parche cierra la omisión de autenticación. Si un atacante accedió al host, evalúe por separado la exposición de claves privadas y otras credenciales, rote las comprometidas y revise los cambios no autorizados en el almacén de confianza.

¿Las fallas de LXD e Incus son el mismo defecto?

Comparten un mecanismo en dos bases de código de un linaje común. Stéphane Graber, creador de LXD e Incus, la reportó; Incus la corrigió en 7.6.0 y Canonical corrigió LXD y MicroCloud en las versiones listadas más arriba. El aviso de Canonical cubre LXD y MicroCloud, y el aviso de Incus se publica sin identificador CVE.

¿Se explota en el mundo real?

No se conoce ninguna explotación. El ADP de CISA evaluó la explotación como ninguna el 30 de octubre de 2026, y la falla no está en el catálogo KEV de CISA al 1 de noviembre de 2026. Los avisos citados no enlazan ninguna prueba de concepto pública.

Encuentre sus hosts LXD e Incus expuestos con Ostorlab

El descubrimiento de superficie de ataque de Ostorlab inventaría sus hosts expuestos a Internet, para que pueda identificar qué demonios LXD, Incus y MicroCloud exponen la API HTTPS y corregirlos primero.

Referencias

• Registro CVE-2026-112816, CNA Canonical, CVSS v4.0 10.0: https://www.cve.org/CVERecord?id=CVE-2026-112816 (comprobado el 1 de noviembre de 2026)
• Aviso de seguridad de Canonical con las versiones snap corregidas: https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557 (publicado el 28 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Aviso de Incus GHSA-xg75-xf37-cph9, CVSS v3.1 10.0: https://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9 (publicado el 29 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Commit de corrección de Incus, «Only trust the key-proven client certificate»: https://github.com/lxc/incus/commit/8381e54c3631c627d7ecdec03945bca14d0bd542 (escrito el 13 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Anuncio de la versión LXD 6.10.1: https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024 (publicado el 21 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Anuncio de la versión Incus 7.6, 18 correcciones de seguridad: https://discuss.linuxcontainers.org/t/incus-7-6-has-been-released/27462 (publicado el 30 de octubre de 2026; comprobado el 1 de noviembre de 2026)
• Página del rastreador de Ubuntu para CVE-2026-112816, estado de los paquetes del archivo y prioridad Medium: https://ubuntu.com/security/CVE-2026-112816 (comprobada el 1 de noviembre de 2026)
• Código de endpoints de LXD, socket Unix local por defecto y listener HTTPS configurado: https://github.com/canonical/lxd/blob/lxd-6.10.1/lxd/endpoints/endpoints.go (comprobado el 1 de noviembre de 2026)
• Catálogo KEV de CISA, canal verificado para CVE-2026-112816: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 1 de noviembre de 2026)
• The Hacker News, «CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key»: https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html (publicado el 1 de noviembre de 2026; comprobado el 1 de noviembre de 2026)