Segurança da informação

Falha crítica com CVSS 10.0 no LXD e no MicroCloud permite que invasores se passem por clientes confiáveis sem chave privada

Falha crítica com pontuação máxima no LXD e no MicroCloud permite que invasores façam login como clientes confiáveis sem a chave privada. A Canonical já lançou versões corrigidas.


Swati Khandelwal Segunda - 02 de Novembro de 2026 às 07:53
The Hacker News

Uma falha crítica no LXD (plataforma de contêineres e máquinas virtuais) e no MicroCloud, ambos da Canonical, permite que um invasor faça login como um cliente confiável sem possuir a chave privada desse cliente. Para isso, o invasor precisa acessar a API HTTPS (interface de programação de aplicações que usa protocolo seguro) pela rede e ter o certificado público do cliente confiável.

Depois de entrar, o invasor atuaria como esse cliente, com acesso ao cluster e às suas máquinas virtuais. Se a conta personificada tiver privilégios elevados, o invasor poderia obter “acesso root à máquina hospedeira”, afirmou a Canonical.

A falha, catalogada como CVE-2026-112816 (identificador padrão de vulnerabilidades conhecidas), tem pontuação máxima de 10.0 no CVSS (sistema de pontuação de severidade de vulnerabilidades). A Canonical já lançou versões corrigidas dos dois produtos.

Como a falha funciona

O LXD e o MicroCloud permitem que clientes remotos acessem suas APIs por meio de TLS mútuo (Segurança da Camada de Transporte, em que o cliente apresenta um certificado para comprovar sua identidade). Um cliente é considerado confiável quando seu certificado está no armazenamento de confiança do servidor, que é a lista de identidades que o servidor aceita.

A falha estava na forma como o servidor verificava esse certificado. Ele comparava todos os certificados enviados pelo cliente com o armazenamento de confiança, mas uma conexão TLS só comprova que o cliente possui a chave privada do primeiro certificado da cadeia, chamado de certificado folha. O restante da cadeia é o que o cliente decidiu anexar.

Assim, um invasor poderia pegar o certificado público de um cliente confiável, que não é secreto, anexá-lo à cadeia atrás do seu próprio certificado, e o servidor o aceitaria como esse cliente.

Quem é afetado

Explorar a falha exige duas coisas: acesso de rede à API HTTPS e o certificado público de um cliente que o servidor já confia.

Um servidor LXD independente não expõe essa API por padrão. Ele escuta apenas em um socket local, a menos que um administrador ative a API de rede com a configuração core.https_address.

O MicroCloud, que reúne várias máquinas com LXD em um único cluster, tem um ponto fraco específico. Segundo a Canonical, um invasor que consiga capturar o certificado público de um membro ao entrar no cluster pode então fazer login como esse membro.

O registro da CVE lista como afetadas as versões LXD 4.0.14, 5.0.10, 5.21.8 e 6.9, cada uma anterior à versão corrigida seguinte. A Canonical lista as seguintes versões corrigidas em formato snap:

O problema não começou na Canonical. O projeto Incus, uma bifurcação comunitária do LXD, relatou a falha, e a Canonical confirmou que ela também afetava o LXD. O Incus corrigiu a mesma falha na versão 7.6.0.

As versões do LXD empacotadas no arquivo próprio do Ubuntu estão listadas como não afetadas ou não distribuídas, por isso as versões corrigidas são os pacotes snap.

Não há nenhum sinal público de que a falha tenha sido usada em ataques. O registro da CVE traz uma avaliação da CISA (Agência de Segurança de Infraestrutura e Cibersegurança dos EUA), datada de 30 de outubro, segundo a qual não se sabe que a falha tenha sido explorada. Ela também não consta na lista de Vulnerabilidades Conhecidas Exploradas da CISA, e nenhum código de exploração funcional foi publicado.

O que fazer

Atualize o LXD e o MicroCloud para as versões corrigidas. Em uma instalação via snap, execute sudo snap refresh lxd e sudo snap refresh microcloud.

A Canonical informou que as versões pontuais corrigidas do LXD ainda estavam sendo distribuídas do canal candidato para o estável no momento de seu aviso. Por isso, verifique a versão que realmente está instalada após a atualização, em vez de presumir que a correção foi aplicada.

O aviso da Canonical não traz nenhuma solução temporária para o LXD. Como o ataque exige acesso de rede à API, limitar quem pode alcançá-la reduz o risco até a atualização. O projeto Incus, que relatou a mesma falha, disse que não há correção por configuração e que a única medida é restringir o acesso de rede ao serviço de escuta.

Usuários do Incus devem migrar para a versão 7.6.0, que corrigiu esta falha junto com outras 17 falhas de segurança.

LXD MicroCloud Segurança cibernética