Falha CVSS 10 no LXD e MicroCloud permite personificar clientes de confiança

A Canonical publicou correções para uma falha crítica de autenticação no LXD e no MicroCloud que permite a um atacante ser aceite como cliente de confiança da API sem nunca possuir a chave privada desse cliente. Registada como CVE-2026-112816, tem a pontuação CVSS máxima de 10,0.

O que aconteceu

O LXD e o MicroCloud autenticam clientes remotos através de TLS mútuo: o cliente apresenta um certificado e o servidor dá-lhe acesso se esse certificado constar do seu repositório de confiança.

O problema estava em qual certificado o servidor verificava. Durante o handshake TLS, o cliente só prova que possui a chave privada do primeiro certificado (leaf) da cadeia que envia; o resto da cadeia é simplesmente o que o cliente decidir anexar. O código vulnerável comparava todos os certificados da cadeia com o repositório de confiança — pelo que um atacante podia apresentar o seu próprio certificado leaf, juntar-lhe atrás o certificado público de um cliente de confiança e ser tratado como esse cliente.

Os certificados públicos não são secretos, e é isso que torna a falha tão grave: os únicos requisitos reais são acesso de rede à API HTTPS e uma cópia do certificado de um cliente de confiança.

Porque é importante

Depois de aceite, o atacante herda as permissões do cliente personificado sobre o cluster, as suas instâncias e máquinas virtuais. Se essa identidade for privilegiada, a Canonical alerta que o resultado pode ser acesso root à máquina anfitriã.

A exposição depende da configuração:

• O LXD autónomo escuta, por omissão, apenas num socket Unix local. Só fica acessível pela rede se um administrador definir core.https_address.
• O MicroCloud, que agrega várias máquinas LXD num único cluster, tem um ponto fraco adicional: um atacante capaz de capturar o certificado público de um membro enquanto este se junta ao cluster pode, mais tarde, autenticar-se como esse membro.

Estão afetadas as versões LXD 4.0.14, 5.0.10, 5.21.8 e 6.9, bem como as anteriores às respetivas correções. A mesma falha existia no Incus, o fork comunitário do LXD, que a corrigiu na versão 7.6.0. Os pacotes LXD do arquivo do Ubuntu constam como não afetados ou não distribuídos, pelo que as correções chegam através dos snaps.

Até agora não há indícios públicos de exploração. Uma avaliação da CISA norte-americana de 30 de outubro classifica-a como não conhecidamente explorada, não consta do catálogo Known Exploited Vulnerabilities da CISA e não foi publicado nenhum exploit funcional. Dada a simplicidade da técnica, não esperamos que essa janela se mantenha aberta muito tempo.

O que fazer

1. Atualize já. Em instalações snap, execute sudo snap refresh lxd e sudo snap refresh microcloud. Versões corrigidas:

2. Confirme a versão efetivamente instalada. Quando o aviso foi publicado, as versões corrigidas do LXD ainda estavam a ser promovidas do canal candidate para stable — confirme com snap list em vez de assumir que a atualização trouxe a correção.
3. Restrinja o acesso à API. Não existe solução por configuração. Até aplicar a correção, limite quem consegue chegar à porta HTTPS do LXD/MicroCloud (8443 por omissão) com regras de firewall, uma VPN ou uma rede de gestão — e nunca a exponha à internet.
4. Os utilizadores do Incus devem passar para a 7.6.0, que fecha esta falha juntamente com outras 17 correções de segurança.
5. Reveja o repositório de confiança e remova os certificados de cliente de que já não precisa: cada certificado de confiança é uma identidade que pode ser personificada.

Falhas deste tipo só são exploráveis se a API estiver acessível, por isso saber exatamente que interfaces de administração expõe é metade da defesa. O nosso serviço de Attack Surface Management mapeia continuamente os anfitriões e serviços expostos à internet e assinala APIs de administração e orquestração expostas, como a do LXD, antes que um atacante as encontre.