Falha crítica no LXD e no MicroCloud pode permitir acesso privilegiado a servidores Linux
Uma vulnerabilidade de gravidade máxima afeta o LXD e o MicroCloud, produtos da Canonical usados para administrar contêineres, máquinas virtuais e clusters Linux. Identificada como CVE-2026-112816, a falha recebeu 10,0 pontos no CVSS e pode permitir que um invasor se autentique como um cliente confiável sem possuir a chave privada correspondente. Em determinadas circunstâncias, esse acesso pode levar a privilégios de root no servidor hospedeiro.
A exploração depende de duas condições: acesso à API HTTPS do ambiente e obtenção do certificado público de um cliente autorizado. Embora ainda não haja evidências públicas de exploração ativa, administradores devem instalar as versões corrigidas e revisar a exposição dos serviços.
Como funciona a vulnerabilidade
O LXD e o MicroCloud usam autenticação mTLS – TLS mútuo – para verificar a identidade de clientes que se conectam às APIs. Nesse processo, o cliente apresenta um certificado digital, e o servidor verifica se ele pertence a uma identidade confiável.
O problema está na maneira como essa validação era feita. Em vez de considerar somente o certificado associado à identidade comprovada durante a conexão TLS, o servidor examinava todos os certificados enviados na cadeia e procurava algum deles na lista de clientes autorizados.
A conexão TLS, porém, comprova que o cliente possui a chave privada correspondente ao primeiro certificado da cadeia, chamado *leaf certificate*. Os certificados adicionais podem ser fornecidos pelo próprio cliente. Assim, um invasor poderia apresentar seu certificado e acrescentar à cadeia o certificado público de um cliente legítimo. Ao encontrá-lo na lista de confiança, o sistema poderia identificar incorretamente o invasor como autorizado.
Como certificados públicos não são secretos, a vítima não precisa ter sua chave privada comprometida para que o ataque seja possível. Ainda assim, o invasor precisa conseguir alcançar a API HTTPS e obter o certificado público de uma identidade confiável.
Quais sistemas estão expostos
Nas instalações independentes do LXD, o acesso à API pela rede não fica habilitado por padrão: normalmente, o serviço usa um socket local. Para permitir conexões remotas, o administrador precisa configurar a opção `core.https_address`.
No MicroCloud, que reúne vários servidores LXD em um cluster, existe uma situação específica de risco. Um invasor que capture o certificado público de um servidor durante seu ingresso no cluster poderá tentar usá-lo posteriormente para se passar por esse membro.
A CVE abrange versões das linhas LXD 4.0, 5.0, 5.21 e 6, além de versões do MicroCloud. A Canonical publicou correções para instalações distribuídas pelos canais Snap:
| Produto | Canal 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 |
Os pacotes do LXD obtidos diretamente dos repositórios do Ubuntu foram classificados como não afetados ou não disponibilizados nas versões correspondentes. As correções listadas pela Canonical se destinam às instalações via Snap.
Incus também recebeu uma correção
A falha foi identificada inicialmente no Incus, projeto comunitário derivado do LXD. Após a divulgação, a Canonical confirmou que o problema também atingia o LXD e o MicroCloud. No Incus, a vulnerabilidade foi corrigida na versão 7.6.0, que inclui ainda ajustes para outras 17 questões de segurança.
Até o momento, não há registro público de exploração ativa da CVE-2026-112816 nem de um exploit funcional divulgado. Uma avaliação da CISA, datada de 30 de outubro, informou que a agência não tinha conhecimento de ataques que explorassem a falha. A vulnerabilidade também não consta no catálogo Known Exploited Vulnerabilities (KEV).
Como reduzir o risco
A medida prioritária é atualizar o LXD e o MicroCloud para as versões corrigidas correspondentes ao canal utilizado. Em instalações Snap, os administradores podem iniciar a atualização com:
“`bash
sudo snap refresh lxd
sudo snap refresh microcloud
“`
Depois, é importante confirmar a versão efetivamente instalada. Quando o comunicado da Canonical foi publicado, algumas versões corrigidas do LXD ainda estavam sendo transferidas do canal `candidate` para o `stable`, o que pode afetar a disponibilidade imediata da atualização.
Não foi indicada uma solução temporária capaz de corrigir o defeito de validação. Enquanto a atualização não puder ser aplicada, restringir o acesso à API HTTPS aos endereços e sistemas que realmente precisam utilizá-la pode diminuir a exposição. Essa medida limita as possibilidades de conexão, mas não substitui a instalação da correção.
Também é recomendável revisar quais serviços estão acessíveis pela rede, confirmar se a API remota do LXD é necessária e verificar as regras de firewall dos servidores. Em clusters MicroCloud, os administradores devem avaliar especialmente a comunicação entre os membros e proteger certificados públicos obtidos durante a entrada de servidores no cluster.
Por fim, a equipe responsável deve inventariar as versões em uso, registrar a data da atualização e acompanhar se todos os nós receberam os pacotes corrigidos. Em ambientes distribuídos, atualizar apenas parte dos servidores pode deixar componentes vulneráveis expostos, mesmo que os demais já estejam protegidos.