Uso LXD ou MicroCloud no meu servidor: a falha de nota máxima me atinge e como atualizo sem susto?

O que é a falha CVE-2026-112816?

O LXD é um gerenciador de contêineres e máquinas virtuais para Linux, e o MicroCloud monta um pequeno cluster usando o LXD como base. Os dois podem ser controlados por uma API HTTPS, autenticada com certificado de cliente. Segundo o The Hacker News, a falha registrada como CVE-2026-112816 recebeu 10.0 no CVSS, a escala de gravidade que vai até 10, e faz o servidor aceitar um atacante como se ele fosse um cliente confiável.

O atacante precisa de duas coisas: alcançar a API pela rede e ter o certificado público desse cliente. O detalhe que preocupa é a palavra "público". Certificado não é tratado como segredo: ele circula, é copiado para outras máquinas e aparece em repositórios e documentação interna. Quem protege a identidade, no modelo normal, é a chave privada, e aqui ela deixa de ser a barreira.

Por que isso importa para você?

Quem administra o LXD manda em tudo o que roda em cima dele. Conforme a mesma reportagem, quando a identidade imitada é privilegiada, o invasor pode chegar ao acesso root no servidor hospedeiro. Numa empresa que roda ERP, banco de dados e sistema de clientes em contêineres no mesmo servidor, isso significa acesso a todos eles de uma vez.

A notícia boa é que há tempo para agir com calma. Até a publicação não havia exploit público nem sinal de uso em ataques, e a falha não aparecia no catálogo KEV, a lista de falhas exploradas de verdade mantida pela CISA, a agência de segurança cibernética dos Estados Unidos. Isso descreve o momento da reportagem e pode mudar. Nota 10.0 com correção publicada costuma virar alvo, então o que você deve fazer agora é conferir o servidor hoje, sem esperar a próxima janela de manutenção.

Como saber se o meu servidor está exposto?

Comece descobrindo se o LXD ou o MicroCloud estão instalados e em que versão. Em instalação por snap, que é o caminho mais comum no Ubuntu:

snap list | grep -E 'lxd|microcloud'
lxc config get core.https_address
ss -ltnp | grep lxd

Em instalações independentes do LXD, a API de rede só existe se alguém configurou o core.https_address. Se o segundo comando voltar vazio e o terceiro não mostrar nada escutando, a API de rede está desligada e o LXD só atende pelo socket local. Ainda vale atualizar, mas a urgência cai.

Se voltar um endereço, olhe qual. Um IP interno ou de VPN limita quem alcança a API. Já [::], 0.0.0.0 ou o IP público significam escuta em todas as interfaces ou direto na internet, e aí só o firewall separa o servidor do mundo. Teste de fora, a partir de uma rede que não seja a da empresa: tente abrir a porta que o comando mostrou. Se conectar, trate como exposto. No MicroCloud, assuma que a API está ativa, porque os membros de um cluster conversam pela rede.

Qual versão corrige a falha?

Compare com o que apareceu no snap list. Quando a falha foi divulgada, as correções ainda estavam sendo promovidas para o canal stable do snap, então pode ser que a versão corrigida não tenha chegado ao canal que o seu servidor acompanha. Veja com snap info lxd. Se o LXD veio de pacote da distribuição, confira o aviso de segurança dela. Se a sua linha não está na tabela, o caminho é migrar para uma das linhas corrigidas.

O que fazer até conseguir atualizar?

De acordo com o The Hacker News, não há contorno temporário além de restringir o acesso à API. Se ninguém usa a API remota e a máquina não faz parte de um cluster, o mais simples é desligá-la:

lxc config unset core.https_address

Se ela é necessária, feche a porta para todos, menos para quem administra:

iptables -I INPUT 1 -p tcp --dport PORTA_DA_API -s IP_DE_GESTAO -j ACCEPT
iptables -I INPUT 2 -p tcp --dport PORTA_DA_API -j DROP

A regra só toca a porta da API, então o seu SSH continua funcionando. Em cluster, acrescente um ACCEPT para cada membro antes do bloqueio, senão eles param de se falar. E salve as regras, porque regra de iptables sem persistência some na próxima reinicialização. Depois repita o teste de fora: o que vale é a porta fechada vista de outra rede, não a regra escrita.

Como atualizar sem derrubar contêineres e VMs?

1. Faça uma cópia antes. Tire snapshot do servidor no provedor, se ele for virtual, e das instâncias importantes com lxc snapshot NOME antes-da-correcao. Snapshot local não substitui backup fora da máquina; a diferença está em como fazer backup de VPS e testar a restauração.
2. Atualize em janela combinada. Rode snap refresh lxd (ou snap refresh microcloud). A troca reinicia o serviço do LXD, e em geral as instâncias seguem rodando, mas a API fica indisponível por um instante e um servidor de produção não é o lugar para descobrir exceção.
3. No cluster, atualize todos os membros na mesma janela. Membros em versões diferentes podem ficar esperando os outros antes de voltar a atender.
4. Prove o resultado. Rode lxc version e compare com a tabela. Depois revise lxc config trust list e lxc list: cliente confiável ou instância que ninguém reconhece merece investigação, ainda mais se a API ficou aberta para a internet.

Só tire a restrição da API, se for o caso, depois de provar a versão. Muita gente pode mantê-la para sempre: API de gerenciamento não tem motivo para ficar aberta ao mundo, com ou sem falha.

Vale continuar mantendo essa camada sozinho?

Se o LXD foi escolhido de propósito e a equipe acompanha as correções, sim. Se ele foi instalado anos atrás e só uma pessoa lembra como funciona, esta falha é um bom motivo para reavaliar. Quem quer manter o controle da virtualização pode usar um servidor dedicado, com KVM over IP para entrar mesmo quando a rede falha, e quem prefere deixar de cuidar dessa camada pode separar os sistemas em VPS ou numa cloud privada. Os planos Cloud vão de R$ 349 a R$ 1.890 por mês, e snapshot (R$ 50 por VM) e backup mensal (R$ 200) são contratados à parte. A migração assistida é sem custo para cliente novo. Para comparar os dois caminhos, veja VPS ou servidor dedicado.