O caso LXD mostra por que certificado confiável não basta para autenticar

A CVE-2026-112816, classificada com CVSS 10,0, permite assumir a identidade de clientes nas APIs HTTPS de LXD e MicroCloud sem possuir a chave privada da vítima.[2] O ataque exige acesso de rede à API e o certificado público de um cliente confiável; os privilégios obtidos acompanham a identidade assumida e podem chegar a root no hospedeiro quando ela é administrativa.[2] O problema não é uma quebra da criptografia, mas a associação incorreta entre prova e identidade.[2]

O que muda para quem desenvolve

Segundo a reportagem, o servidor procurava certificados confiáveis em toda a cadeia apresentada, embora a negociação TLS comprovasse a posse da chave privada apenas do certificado folha.[2] Um certificado legítimo anexado atrás do certificado do atacante podia acabar selecionado como identidade autenticada.[2]

A lição de engenharia é separar três decisões: qual chave teve sua posse comprovada, a qual identidade essa prova corresponde e quais operações essa identidade pode executar. Encontrar um objeto conhecido em uma estrutura enviada pelo cliente não deveria substituir nenhuma dessas decisões.

Isso merece atenção em revisões de gateways e aplicações com mTLS. Recomendo tornar explícito o contrato entre a camada TLS e a autorização, evitando que código de negócio escolha outra identidade apenas porque encontrou um certificado cadastrado.

Como aplicar

Para ambientes com esses produtos, comece pelo inventário de versões e pela exposição efetiva da API. O LXD independente usa socket local por padrão e depende de core.https_address para habilitar sua API de rede; o Incus também comunicou o problema e o corrigiu na versão 7.6.0.[2] Confira a orientação de atualização correspondente ao produto e ao canal instalado antes de encerrar a ação.

Em uma aplicação própria de homologação, crie casos de autenticação com certificados adicionais na cadeia. O critério esperado é simples: anexar um certificado conhecido não pode mudar o principal cuja chave foi comprovada. Registre o principal selecionado e valide também a negação das operações administrativas. Esse é um experimento de contrato de autenticação, não uma orientação para explorar clusters alheios.

Cuidados e limites

Na data da matéria, não havia indicação pública de exploração nem exploit funcional publicado.[2] Isso descreve o conhecimento disponível, não uma garantia de que nenhum ataque ocorreu.

Minha recomendação é restringir o acesso à API enquanto a correção é aplicada, sem confundir redução de exposição com reparo do defeito. Depois da atualização, confirme versão, identidade autenticada e permissões. O cadeado da conexão não responde sozinho à pergunta que importa: quem realmente provou ser quem diz ser?

Fonte

[2] Fonte: The Hacker News