Uma falha crítica no LXD e no MicroCloud, da Canonical, permitia que um invasor se autenticasse como um cliente confiável sem possuir a chave privada dele. Para explorar o problema, era necessário acessar pela rede a API HTTPS e obter o certificado público do cliente confiável.
Depois de se passar pelo cliente, o invasor poderia acessar o cluster e suas máquinas virtuais. Se a conta representada tivesse privilégios elevados, seria possível obter acesso de administrador ao sistema hospedeiro, informou a Canonical.
Identificada como
CVE-2026-112816
, a falha recebeu a pontuação máxima de 10,0 no CVSS. 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 usando TLS mútuo, configuração na qual o cliente apresenta um certificado para comprovar sua identidade. Um cliente é considerado confiável quando seu certificado está no repositório de confiança do servidor, que reúne as identidades aceitas.
O problema estava na forma como o servidor validava o certificado. Ele comparava todos os certificados enviados pelo cliente com os registros do repositório de confiança. No entanto, uma conexão TLS comprova que o cliente possui a chave privada apenas do primeiro certificado da cadeia, chamado de certificado folha. Os demais certificados podem ser incluídos pelo próprio cliente.
Assim, um invasor poderia obter o certificado público de um cliente confiável, que não é secreto, e anexá-lo à cadeia depois do próprio certificado. O servidor então aceitaria o invasor como se fosse aquele cliente.
Quem está vulnerável
A exploração depende de dois fatores: acesso pela rede à API HTTPS e a obtenção do certificado público de um cliente já considerado confiável pelo servidor.
Por padrão, um servidor LXD independente não expõe essa API. Ele aceita conexões apenas por um soquete local, a menos que o administrador habilite a API de rede usando a configuração `core.https_address`.
O MicroCloud, que conecta várias máquinas com LXD em um único cluster, tem um ponto vulnerável específico. Segundo a Canonical, um invasor que consiga capturar o certificado público de um membro enquanto ele ingressa no cluster pode se autenticar como esse membro.
O registro da CVE aponta como afetadas as versões 4.0.14, 5.0.10, 5.21.8 e 6.9 do LXD, além das versões anteriores às correções correspondentes. A Canonical informa que as seguintes versões dos pacotes snap corrigem a falha:
| Produto | Canal do pacote snap | Versão corrigida |
|---|---|---|
| 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 |
A falha foi inicialmente identificada pelo projeto Incus, criado como uma bifurcação comunitária do LXD. A Canonical confirmou que o problema também afetava o LXD. O Incus corrigiu a mesma falha na versão 7.6.0.
Os pacotes do LXD distribuídos nos repositórios do Ubuntu constam como não afetados ou não disponibilizados. As versões corrigidas são distribuídas como pacotes snap.
Até o momento, não há indícios públicos de que a falha tenha sido usada em ataques. Uma avaliação da CISA incluída no registro da CVE, datada de 30 de outubro, afirma que não há conhecimento de exploração. A vulnerabilidade não aparece na lista de vulnerabilidades conhecidamente exploradas da agência, e nenhum exploit funcional foi publicado.
O que fazer
Atualize o LXD e o MicroCloud para as versões corrigidas. Em instalações feitas por snap, execute `sudo snap refresh lxd` e `sudo snap refresh microcloud`.
Na época em que publicou o alerta, a Canonical informou que as versões de manutenção corrigidas do LXD ainda estavam sendo transferidas do canal candidato para o canal estável. Por isso, confira a versão instalada após a atualização, em vez de presumir que a correção já foi aplicada.
O alerta da Canonical não apresenta uma medida temporária para o LXD. Como o ataque exige acesso à API pela rede, restringir quem pode alcançá-la reduz o risco até a instalação da atualização. Ao relatar a mesma falha, o projeto Incus afirmou que não há uma correção por configuração e recomendou limitar o acesso de rede ao serviço que recebe as conexões.
Usuários do Incus devem atualizar para a versão 7.6.0, que corrige essa falha e outros 17 problemas de segurança.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...