Uma vulnerabilidade crítica no LXD, identificada como CVE-2026-112816, colocou em alerta administradores de servidores Linux e ambientes de infraestrutura virtualizada. Classificada com a pontuação máxima de 10,0 no CVSS 4.0, a falha permite que invasores se autentiquem como clientes legítimos do LXD e do MicroCloud sem precisar obter a chave privada dos usuários autorizados.
O problema está relacionado à validação incorreta de certificados digitais durante o processo de autenticação mTLS (Mutual TLS). Dependendo das permissões associadas à identidade falsificada, um invasor pode conseguir controle completo sobre clusters, máquinas virtuais e até acesso root ao sistema operacional hospedeiro. A vulnerabilidade também afeta o projeto comunitário Incus, derivado do LXD.
A gravidade merece atenção especial porque o LXD e o MicroCloud são utilizados para administrar contêineres, máquinas virtuais e clusters em servidores Linux, incluindo infraestruturas corporativas e ambientes bare metal. A Canonical já disponibilizou atualizações de segurança, enquanto o projeto Incus publicou sua própria correção. O aspecto mais preocupante é que a exploração não depende do roubo de uma chave privada: basta reunir determinadas condições de acesso à API e obter o certificado público de um cliente confiável.
Como funciona a vulnerabilidade crítica no LXD e a falha de validação mTLS
O mTLS é um mecanismo de autenticação baseado em certificados digitais no qual servidor e cliente comprovam suas identidades durante o estabelecimento de uma conexão TLS. Diferentemente do TLS convencional, em que normalmente apenas o servidor apresenta um certificado, o modelo mútuo também exige que o cliente seja autenticado.
No LXD e no MicroCloud, esse mecanismo ajuda a proteger as APIs administrativas contra acessos não autorizados. Cada cliente confiável utiliza um certificado digital associado à sua identidade, enquanto a respectiva chave privada comprova que ele realmente controla aquele certificado.
O problema identificado na CVE-2026-112816 está justamente na maneira como o servidor verifica a cadeia de certificados apresentada pelo cliente.
Em uma conexão legítima, o cliente apresenta seu certificado e demonstra a posse da chave privada correspondente por meio do processo criptográfico de autenticação TLS. Entretanto, a implementação vulnerável não validava corretamente todos os certificados apresentados na cadeia.
Isso permitia uma situação particularmente perigosa: um invasor poderia apresentar um certificado próprio, cuja chave privada realmente controla, e incluir o certificado público de outro cliente confiável como certificado intermediário na cadeia apresentada.
Como certificados públicos não são informações secretas, o invasor não precisa descobrir a chave privada da vítima. A falha está na interpretação incorreta da cadeia de confiança pelo servidor, que pode acabar reconhecendo a identidade privilegiada do certificado inserido na cadeia.
Na prática, o atacante consegue personificar outro cliente autorizado, contornando a autenticação esperada pelo LXD.
A consequência depende das permissões atribuídas à identidade falsificada. Se o certificado pertencer a uma conta com privilégios administrativos, o invasor poderá assumir o controle das operações gerenciadas pelo serviço, incluindo recursos capazes de resultar em acesso root ao host.
A classificação máxima de CVSS 10.0 reflete características especialmente perigosas: exploração pela rede, baixa complexidade, ausência de privilégios prévios e inexistência de interação do usuário.
Ambientes afetados pela vulnerabilidade no LXD, MicroCloud e Incus
A CVE-2026-112816 não significa que qualquer instalação do LXD esteja automaticamente acessível pela internet. O cenário depende principalmente da configuração da API HTTPS e da possibilidade de alcançar o serviço pela rede.
Por padrão, uma instalação autônoma do LXD utiliza um socket Unix local para comunicação administrativa. Nesse cenário, a API não fica automaticamente exposta por uma interface de rede.
A situação muda quando o administrador habilita o acesso remoto por meio da configuração core.https_address. Essa opção permite que o daemon disponibilize sua API HTTPS em um endereço de rede, tornando a restrição de acesso um elemento fundamental da segurança.
Para verificar a configuração atual, execute:
lxc config get core.https_addressSe o comando retornar um endereço IP ou uma interface de rede, existe um listener HTTPS configurado. Isso não significa necessariamente exposição pública, pois regras de firewall e segmentação de rede ainda podem restringir os clientes autorizados.
O MicroCloud apresenta um cenário adicional de preocupação. Durante o ingresso de novos nós em um cluster, certificados públicos utilizados no processo de associação podem ficar disponíveis para outros participantes da comunicação. A vulnerabilidade permite explorar esse contexto para personificar um membro confiável, caso as condições necessárias sejam atendidas.
Isso é particularmente relevante em infraestruturas distribuídas, nas quais diferentes servidores precisam estabelecer relações de confiança para administrar recursos compartilhados.
Incus também recebeu uma correção de segurança
O Incus, projeto comunitário surgido como uma alternativa independente ao LXD, também foi afetado pelo problema de validação de certificados.
A descoberta foi atribuída a Stéphane Graber, desenvolvedor que identificou o comportamento incorreto no ecossistema Incus e colaborou com a Canonical na investigação da vulnerabilidade.
O projeto publicou a correção no Incus 7.6.0, contemplando a falha de autenticação identificada pela CVE-2026-112816.
Portanto, administradores que utilizam Incus também precisam verificar suas instalações e atualizar para a versão corrigida. A correção disponibilizada para o LXD não substitui a atualização independente do Incus.
Versões corrigidas e como atualizar LXD e MicroCloud imediatamente
A Canonical publicou atualizações de segurança em 29 de outubro de 2026, disponibilizando versões corrigidas dos pacotes Snap do LXD e MicroCloud.
Os administradores precisam observar que as versões corrigidas variam conforme o canal de manutenção utilizado. Não basta instalar uma versão numericamente mais recente de outra ramificação: é necessário verificar se a atualização corresponde à linha instalada.
| Componente | Versão afetada | Versão corrigida |
|---|---|---|
| LXD 6.x | 6.9 | 6.10.1 |
| LXD 5.21 | 5.21.8 | 5.21.9 |
| LXD 5.0 | 5.0.10 | 5.0.11 |
| LXD 4.0 | 4.0.14 | 4.0.15 |
| MicroCloud 3.x | 3.4.0 | 3.4.1 |
| MicroCloud 2.x | 2.1.4 | 2.1.5 |
| Incus | Versões anteriores à 7.6.0 | 7.6.0 |
Para instalações realizadas por meio do Snap, a atualização pode ser iniciada com os seguintes comandos:
sudo snap refresh lxdPara atualizar o MicroCloud:
sudo snap refresh microcloudDepois da atualização, confira as versões instaladas:
lxd --version
microcloud --versionNo caso do Incus, os administradores devem atualizar para a versão 7.6.0 ou posterior, utilizando o método de instalação correspondente à distribuição Linux e ao repositório adotado.
Atenção à disponibilidade nos canais Snap
Existe um detalhe operacional importante: a Canonical informou que as versões corrigidas do LXD estavam passando por uma distribuição progressiva do canal candidate para o canal stable.
Isso significa que nem todos os ambientes necessariamente recebem a atualização estável ao mesmo tempo.
É possível verificar o canal e a revisão instalada com:
snap list lxd
snap info lxdO segundo comando apresenta informações sobre os canais disponíveis e suas respectivas versões.
Caso a versão corrigida ainda não esteja disponível no canal estável utilizado pelo servidor, o administrador deve avaliar a utilização do canal candidato, seguindo os procedimentos internos de homologação e controle de mudanças.
Não é recomendável alterar indiscriminadamente os canais de produção sem avaliar compatibilidade, dependências e procedimentos de reversão.
Mitigações de rede enquanto a atualização é homologada
Se a atualização imediata não for possível, a principal medida temporária é restringir o acesso à API HTTPS.
A vulnerabilidade depende da possibilidade de alcançar o listener remoto. Portanto, reduzir a superfície de exposição diminui as oportunidades de exploração.
As recomendações incluem:
- Restringir a porta da API administrativa, normalmente TCP 8443, a endereços IP de administradores e servidores autorizados.
- Utilizar uma rede de gerenciamento dedicada para a comunicação entre os nós do cluster.
- Evitar a exposição direta da API do LXD à internet pública.
- Aplicar regras de firewall nos servidores e nos equipamentos de rede intermediários.
- Revisar as regras de acesso dos clusters e identificar interfaces que estejam aceitando conexões de redes não confiáveis.
- Monitorar tentativas de conexão e atividades administrativas incomuns.
É importante destacar que essas medidas são mitigações temporárias, não substitutos para a atualização. A restrição de rede reduz a possibilidade de exploração, mas não corrige a falha de validação dos certificados.
Também não existe uma configuração alternativa que elimine o problema sem aplicar a correção de software. O caminho definitivo é instalar as versões corrigidas.
A importância de proteger APIs administrativas em servidores Linux
A CVE-2026-112816 demonstra como um erro aparentemente pequeno na implementação de um mecanismo criptográfico pode comprometer toda uma infraestrutura.
O uso de certificados digitais e autenticação mTLS não garante segurança automaticamente. A implementação precisa verificar corretamente a identidade apresentada, a posse da chave privada correspondente e a cadeia de confiança utilizada durante a negociação TLS.
Nesse caso, o problema é especialmente relevante porque o LXD e o MicroCloud são ferramentas administrativas. Uma identidade privilegiada comprometida pode representar muito mais do que o acesso a uma aplicação ou a um contêiner: pode abrir caminho para operações administrativas sobre máquinas virtuais, armazenamento e recursos do próprio host.
A avaliação divulgada pela CISA em 30 de outubro de 2026 não indicava exploração conhecida da vulnerabilidade. A falha também não constava no catálogo Known Exploited Vulnerabilities (KEV) naquele momento.
Entretanto, a ausência de exploração conhecida não deve ser interpretada como garantia de segurança. Vulnerabilidades com pontuação máxima frequentemente atraem a atenção de pesquisadores e grupos criminosos, especialmente quando os detalhes técnicos da correção já estão disponíveis publicamente.
Para administradores de sistemas, a prioridade deve ser identificar instalações potencialmente vulneráveis, verificar a exposição das APIs e aplicar as atualizações correspondentes.
Outro aprendizado importante é evitar que interfaces administrativas de infraestrutura sejam disponibilizadas em redes amplas sem uma justificativa operacional. APIs de gerenciamento precisam permanecer em segmentos controlados, com acesso limitado e monitoramento contínuo.
A vulnerabilidade também reforça a importância de acompanhar os avisos de segurança dos projetos open source utilizados em ambientes corporativos. Mesmo ferramentas maduras, amplamente utilizadas e mantidas por organizações reconhecidas podem apresentar falhas críticas que exigem respostas rápidas.
Se você administra clusters com LXD, MicroCloud ou Incus, compartilhe nos comentários como controla a exposição das APIs administrativas em seus servidores. Acompanhe também o SempreUpdate para conferir outros conteúdos sobre segurança Linux, endurecimento de servidores e proteção de infraestruturas open source.
