Falha no LXD permite invasor assumir acesso root em minutos

Segurança

Vulnerabilidade crítica no LXD permite acesso root rápido; atualização urgente é recomendada pela Canonical.

Leia também: Ucraniano é condenado nos EUA por ataques de ransomware

Uma vulnerabilidade crítica nas plataformas LXD e MicroCloud da Canonical, catalogada como CVE-2026-112816 e com pontuação máxima de 10.0 no CVSS, permite que um invasor se autentique como um cliente confiável sem possuir a chave privada legítima, abrindo caminho para acesso ao cluster, às máquinas virtuais e até privilégio de root em hosts comprometidos.

Como a falha funciona e quem está em risco

O problema está na forma como o servidor valida a cadeia de certificados TLS apresentada pelo cliente. Em vez de checar apenas o certificado que de fato comprovou a posse da chave privada na conexão, o servidor compara todos os certificados enviados com a lista de certificados confiáveis. Isso permite que o atacante coloque o próprio certificado na frente e anexe, atrás dele, o certificado público de um cliente já confiável.

Como a conexão TLS só garante a posse da chave privada do primeiro certificado da cadeia, o servidor acaba aceitando o invasor como se fosse o cliente legítimo, mesmo sem qualquer controle daquela chave privada. Na prática, basta ao atacante ter acesso à rede à API HTTPS e ao certificado público do cliente alvo — informação que não é secreta.

Em instalações LXD padrão, a API remota não é exposta: ela só fica acessível em rede quando o administrador ativa o parâmetro core.https_address. Ambientes que fizeram essa exposição, especialmente em redes amplas ou internet, são os mais vulneráveis. No MicroCloud, que agrupa múltiplos nós LXD em cluster, o risco é maior porque é possível capturar o certificado público de um membro durante o processo de junção ao cluster e, a partir daí, fazer login como esse membro.

A Canonical alerta que, ao assumir a identidade de uma conta privilegiada, o atacante ganha poder total sobre o ambiente. “If the impersonated account is privileged, the attacker could gain root access to the host machine”, afirmou a empresa em seu comunicado.

Quais versões do LXD e do MicroCloud foram afetadas

A falha atinge diretamente o LXD nas versões 4.0.14, 5.0.10, 5.21.8 e 6.9, além do MicroCloud, em implantações que utilizam a API HTTPS acessível em rede. O uso típico dessas ferramentas envolve gerenciamento de containers e máquinas virtuais em larga escala, o que torna provedores de nuvem, empresas de tecnologia e grandes ambientes corporativos especialmente sensíveis ao problema.

O impacto vai além do acesso indevido. Uma vez autenticado como cliente confiável, o invasor passa a ter a mesma visão e os mesmos privilégios que o usuário legítimo, podendo criar, alterar ou destruir instâncias, mover cargas de trabalho entre nós e acessar dados sensíveis. Em clusters, isso se traduz em risco sistêmico: comprometer um nó privilegiado pode abrir caminho para comprometer toda a infraestrutura associada.

Atualizações e comandos para correção

A Canonical já distribui versões corrigidas do LXD e do MicroCloud via pacotes snap e recomenda atualização imediata. Em sistemas que utilizam snaps, os comandos indicados são:

sudo snap refresh lxd
sudo snap refresh microcloud

A empresa ressalta que as correções ainda estão em processo de migração do canal candidate para o stable, o que significa que o administrador deve conferir manualmente a versão instalada após o refresh e confirmar se ela já inclui o patch para o CVE-2026-112816.

O projeto Incus, fork comunitário do LXD que descobriu a vulnerabilidade, já havia corrigido o mesmo problema na versão 7.6.0. Usuários do Incus são orientados a atualizar para essa versão, que também resolve outras 17 falhas de segurança identificadas pela comunidade.

Entenda o contexto

LXD e MicroCloud utilizam autenticação mútua por TLS, em que tanto servidor quanto cliente se identificam por certificados digitais. Um cliente passa a ser confiável quando seu certificado público entra no repositório de confiança do servidor, que então aceita conexões apresentando aquela identidade.

No cenário ideal, o servidor deveria validar se o certificado que comprovou posse de chave privada na conexão corresponde exatamente a uma identidade confiável. O erro descoberto pelo Incus e confirmado pela Canonical está justamente na lógica dessa verificação, que aceitava qualquer certificado confiável em qualquer posição da cadeia enviada pelo cliente, e não apenas o certificado autenticado como “dono” daquela sessão.

Esse tipo de falha desmonta a garantia de que apenas detentores legítimos das chaves privadas conseguem se passar por clientes autorizados, criando um atalho perigoso para invasores com presença na rede interna ou em pontos intermediários de comunicação.

Há solução temporária sem atualizar?

Não há uma configuração de LXD ou MicroCloud capaz de mitigar a falha sem atualização; a única medida provisória é restringir o acesso de rede à API. O próprio projeto Incus, que primeiro relatou o problema, é enfático: “There is no configuration fix and the only step is to restrict network access to the listener”.

Na prática, isso significa limitar rigorosamente, via firewall ou controles de rede, quais máquinas podem alcançar o endereço HTTPS exposto pela API. Em instalações LXD que nunca tiveram o parâmetro core.https_address ativado, o risco imediato é menor, já que o serviço não está ouvindo em interfaces de rede externas.

A Canonical não apresentou workaround específico além desse endurecimento de acesso. Para administradores responsáveis por clusters MicroCloud ou infraestruturas em produção, a orientação é revisar com urgência quais redes têm acesso à API, aplicar segmentação e monitorar logs de autenticação e comandos remotos em busca de comportamentos atípicos até que as atualizações estejam completamente implantadas.

A falha já está sendo explorada?

Até o momento, não há indícios públicos de ataques usando a CVE-2026-112816. A avaliação mais recente da agência de segurança cibernética dos Estados Unidos (CISA) registra que “The flaw is not known to have been exploited; it is not on CISA’s Known Exploited Vulnerabilities list”, o que significa que, por ora, ela não aparece na lista oficial de vulnerabilidades exploradas ativamente.

Isso não reduz a criticidade do problema. A combinação de pontuação máxima no CVSS, possibilidade de se passar por clientes confiáveis e chance de acesso root em hosts faz com que especialistas considerem a atualização urgente, especialmente em ambientes com APIs expostas ou clusters com múltiplos nós.

Nas próximas semanas, a expectativa é que a Canonical conclua a liberação das versões corrigidas para todos os canais estáveis. Até lá, a recomendação para equipes de TI é dupla: aplicar as atualizações disponíveis assim que surgirem e reforçar controles de rede e monitoramento para detectar qualquer tentativa suspeita de uso das APIs do LXD e do MicroCloud.