CVE-2026-112816: Bypass de Autenticação Crítico em LXD e MicroCloud Permite Tomada de Controle do Cluster

A Canonical lançou atualizações de segurança abordando o CVE-2026-112816, uma vulnerabilidade crítica de bypass de autenticação que afeta o LXD e o MicroCloud. A falha possui uma pontuação máxima de CVSS de 10.0 e pode permitir que um invasor remoto não autenticado se passe por um cliente TLS confiável sem possuir a chave privada desse cliente.

A exploração bem-sucedida pode fornecer acesso à API do LXD ou do MicroCloud com os privilégios atribuídos à identidade personificada. Quando a identidade confiável tem permissões suficientes, um invasor pode obter acesso total ao cluster, máquinas virtuais gerenciadas e potencialmente acesso ao nível de root no host subjacente.

A vulnerabilidade decorre de uma validação inadequada das cadeias de certificados do cliente usadas para autenticação mútua TLS. Em vez de autenticar apenas o certificado folha para o qual o cliente prova posse da chave privada correspondente, implementações vulneráveis comparam todos os certificados fornecidos na cadeia controlada pelo cliente com certificados confiáveis.

Um invasor que pode acessar a API HTTPS e obter o certificado público de um cliente já confiável pode, portanto, anexar esse certificado por trás de um certificado folha controlado pelo invasor e ser aceito como a identidade confiável.

A Canonical divulgou a questão no final de outubro de 2026, após a vulnerabilidade ter sido referida pelo projeto Incus. As versões corrigidas do LXD e do MicroCloud já estão disponíveis, e os administradores são fortemente aconselhados a atualizar imediatamente.

A falha é especialmente significativa em ambientes de infraestrutura porque o LXD gerencia contêineres de sistema e máquinas virtuais, enquanto o MicroCloud coordena a infraestrutura em cluster. O comprometimento de uma identidade administrativa pode, portanto, se estender além de um único serviço e fornecer controle sobre workloads ou o próprio host.

Para a detecção do CVE-2026-112816, as equipes de segurança devem priorizar a identificação de APIs HTTPS do LXD e MicroCloud acessíveis pela internet ou rede, revisar certificados de clientes confiáveis e correlacionar autenticações bem-sucedidas baseadas em certificados com sistemas de origem inesperados ou operações administrativas incomuns.

A Plataforma de Inteligência de Detecção Nativa de IA da SOC Prime permite que as equipes de segurança fortaleçam a cobertura para exploração e comportamento pós-comprometimento em toda a rede, Linux, nuvem, contêiner e telemetria de identidade.

Contatar Vendas

Clique em Explorar Detecções para acessar conteúdos de detecção relevantes e lógica de caça. Para detectar o CVE-2026-112816, os defensores devem combinar o inventário de versões vulneráveis com o monitoramento de acesso à API, a telemetria de autenticação de certificado e atividade administrativa suspeita que afete contêineres, máquinas virtuais ou configuração de cluster.

Análise do CVE-2026-112816

CVE-2026-112816 é uma vulnerabilidade de validação inadequada de certificados no ouvinte HTTPS usado pela Canonical LXD e MicroCloud.

Ambos os produtos podem usar TLS mútuo para autenticar clientes remotos. Sob comportamento normal mTLS, o cliente que se conecta apresenta um certificado e prova a posse da chave privada associada ao certificado usado como folha da cadeia TLS.

O problema surge porque as implementações vulneráveis do LXD e MicroCloud inspecionam mais do que aquele certificado folha autenticado.

De acordo com a Canonical, a lógica de autenticação remota da API comparou todos os certificados apresentados por um cliente com as entradas no repositório de certificados confiáveis. No entanto, o TLS prova a posse da chave privada apenas para o certificado folha. Certificados adicionais na cadeia apresentada são fornecidos pelo cliente e não provam independentemente a propriedade de suas chaves privadas correspondentes.

Isso cria uma lacuna de autenticação.

Um invasor pode gerar um certificado e uma chave privada que ele controla, usar esse certificado como folha e adicionar o certificado público de um cliente confiável em outro lugar na cadeia apresentada. O servidor vulnerável pode encontrar o certificado confiável e associar a conexão com essa identidade confiável, mesmo que o invasor não possua sua chave privada.

Os detalhes para o CVE-2026-112816 mostram, portanto, que a exploração depende principalmente de dois pré-requisitos:

• O invasor pode acessar a API HTTPS do LXD ou do MicroCloud.
• O invasor possui o certificado público de uma identidade já confiável pelo alvo.

A chave privada do cliente confiável não é necessária.

Esta distinção explica a gravidade crítica da vulnerabilidade. A autenticação baseada em certificado é esperada para demonstrar a posse de uma chave privada secreta, mas a lógica afetada efetivamente permite a posse do certificado público por si só para satisfazer parte da decisão de confiança.

Uma instalação standalone do LXD não expõe sua API remota HTTPS por padrão. O Hacker News observa que o LXD normalmente ouve apenas em seu socket Unix local, a menos que um administrador habilite o acesso à rede, por exemplo, através da configuração core.https_address.

Isso significa que nem toda instalação vulnerável do LXD é explorável remotamente a partir de outro host.

A exposição se torna significativamente maior quando os administradores habilitam a API em uma rede de gerenciamento ou a expõem na internet.

O MicroCloud apresenta outro cenário de ataque relevante. A Canonical afirma que um invasor que pode interceptar o certificado TLS público de uma máquina que ingressa em um cluster MicroCloud pode, posteriormente, autenticar-se como esse membro ingressado.

O CVE-2026-112816 afeta as versões vulneráveis do Canonical LXD, incluindo 4.0.14, 5.0.10, 5.21.8 e 6.9 antes de seus respectivos lançamentos corrigidos.

A Canonical lista estas versões corrigidas do LXD:

• LXD 6.10.1 para o canal 6/stable
• LXD 5.21.9 para 5.21/stable
• LXD 5.0.11 para 5.0/stable
• LXD 4.0.15 para 4.0/stable

Para o MicroCloud, as versões corrigidas são:

• MicroCloud 3.4.1 para 3/stable
• MicroCloud 2.1.5 para 2/stable

O registro CVE do Ubuntu descreve a exploração bem-sucedida como permitindo que um invasor não autenticado se autentique como um cliente confiável e obtenha acesso total ao cluster e às máquinas virtuais gerenciadas por meio de uma cadeia de certificados criada.

A pontuação máxima de CVSS de 10.0 reflete a acessibilidade à rede, baixa complexidade de ataque, sem privilégios necessários e sem interação do usuário, combinados com um potencial impacto elevado na confidencialidade, integridade e disponibilidade.

O impacto depende, em última análise, dos privilégios da identidade que está sendo personificada.

Uma identidade restrita pode fornecer capacidades limitadas da API. Um cliente ou identidade de cluster altamente privilegiado pode proporcionar um acesso substancialmente maior.

A Canonical alerta explicitamente que a personificação de um usuário confiável privilegiado pode resultar em acesso root à máquina host.

Isso pode potencialmente permitir que um invasor:

• Gerencie ou modifique contêineres e máquinas virtuais.
• Acesse workloads gerenciados através do ambiente LXD comprometido.
• Modifique a configuração da infraestrutura.
• Crie novos workloads ou altere os existentes.
• Interfira com a disponibilidade.
• Acesse dados disponíveis para a identidade personificada.
• Potencialmente alcance o host com privilégios de nível root quando permissões suficientes estão disponíveis.

A falha foi originalmente identificada no projeto Incus relacionado e, em seguida, referida à Canonical, que confirmou que o mesmo problema de autenticação de cadeia de certificados afetou o LXD.

Incus descreve a questão subjacente de forma semelhante: o servidor solicitava certificados de clientes sem verificar toda a cadeia enviada, enquanto verificações de confiança iteravam por cada certificado de par fornecido, em vez de restringir a autenticação ao certificado folha real. Incus abordou a questão na versão 7.6.0.

A vulnerabilidade parece ter existido por um período prolongado. A Incus afirma que a lógica de autenticação equivalente estava presente desde o seu lançamento inicial. O aviso público da Canonical não fornece uma data exata para quando o comportamento vulnerável do LXD foi introduzido pela primeira vez.

Em 2 de novembro de 2026, um PoC independente para o CVE-2026-112816 e uma reprodução em laboratório foram publicados publicamente. Isso representa uma mudança em relação ao relatório do Hacker News publicado em 1º de novembro, que afirmava que nenhum exploit funcional havia sido lançado ainda. A reprodução pública apareceu após a divulgação e não é a pesquisa original da vulnerabilidade.

A Canonical e as denúncias referidas não indicaram que a vulnerabilidade foi explorada em ataques no mundo real.

O Hacker News relata que a questão não era conhecida por ser explorada até a avaliação da CISA dos EUA em 30 de outubro e não foi incluída no catálogo de Vulnerabilidades Conhecidas Exploradas da CISA naquela época.

Portanto, não há IOCs específicos de campanha para o CVE-2026-112816, como endereços IP maliciosos confirmados, domínios, hashes de malware ou infraestrutura conhecida de atacantes associada à exploração.

Defensores devem se concentrar em vez disso na exposição a vulnerabilidades e comportamento.

Oportunidades potenciais de caça incluem:

• Conexões remotas às APIs HTTPS do LXD ou MicroCloud a partir de sistemas inesperados.
• Autenticação bem-sucedida da API originando-se de redes não usadas normalmente por administradores confiáveis.
• Uma identidade de certificado confiável aparecendo de vários sistemas de origem não relacionados.
• Atividade administrativa da API que não corresponde ao proprietário esperado de um certificado.
• Criação, exclusão ou modificação inesperada de contêineres e máquinas virtuais.
• Alterações nas entradas de certificados confiáveis.
• Novos ou alterados membros do cluster.
• Mudanças inesperadas no armazenamento, rede, perfis, projetos ou configuração de instâncias.
• Operações privilegiadas ocorrendo logo após uma autenticação baseada em certificados incomum.
• Conexões de API para interfaces de gerenciamento que não eram destinadas a serem acessíveis remotamente.

As organizações também devem inventariar certificados confiáveis associados a ex-administradores, hosts aposentados, sistemas de automação e membros do cluster.

Como a exploração requer o certificado público em vez da chave privada, os defensores não devem tratar a confidencialidade das chaves privadas sozinha como proteção suficiente contra essa vulnerabilidade específica.

O monitoramento também deve levar em conta redes de gerenciamento compartilhadas.

Uma API que não é exposta diretamente à internet pública pode ainda ser explorável por um invasor que já tenha obtido uma base em outro sistema capaz de acessar a interface de gerenciamento.

Isso torna o movimento lateral particularmente relevante. Uma estação de trabalho comprometida, servidor, executor CI/CD, host de gerenciamento ou workload em nuvem com acesso à rede para a API do LXD pode fornecer a posição necessária para explorar um sistema internamente exposto, caso contrário.

Mitigação do CVE-2026-112816

A Canonical recomenda a atualização imediata das implantações afetadas do LXD e MicroCloud para as versões corrigidas mais recentes.

Para implantações baseadas em Snap, os administradores podem atualizar usando:

sudo snap refresh lxd

e:

sudo snap refresh microcloud

Após a atualização, verifique a versão realmente instalada, em vez de assumir que a atualização foi aplicada com sucesso.

A Canonical observou durante a divulgação que algumas versões do LXD estavam progredindo de candidatos a canais estáveis. Portanto, os administradores devem confirmar explicitamente que seu sistema está executando uma das versões corrigidas.

A principal mitigação do CVE-2026-112816 é a atualização para:

Produto	Versão corrigida
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

A Canonical não publicou uma solução baseada em configuração que elimine totalmente o defeito de autenticação subjacente.

Se a atualização imediata não for possível, restrinja o acesso à rede à API HTTPS da forma mais agressiva possível que os requisitos operacionais permitirem.

Apenas hosts de gerenciamento autorizados e infraestrutura confiável devem poder estabelecer conexões com o ouvinte.

Para instalações do LXD que não exigem gerenciamento remoto, os administradores devem avaliar se a API de rede precisa permanecer habilitada.

Para ambientes que exigem acesso remoto:

• Restrinja a API usando firewalls de host ou de rede.
• Permita conexões apenas de redes de gerenciamento dedicadas.
• Evite expor a API diretamente à internet pública.
• Use acesso administrativo baseado em VPN ou bastion quando apropriado.
• Segmente a infraestrutura de gerenciamento de contêineres e virtualização de redes de usuários.
• Monitore todas as solicitações da API administrativa bem-sucedidas.
• Revise os certificados confiáveis e remova entradas que não são mais necessárias.

Esses controles reduzem a exposição, mas não corrigem a lógica de validação de certificado vulnerável.

Organizações que usam o MicroCloud devem priorizar a atualização de todos os membros relevantes do cluster e revisar a atividade recente de adesão para sistemas ou identidades de certificado inesperados.

Os administradores também devem revisar seus repositórios de certificados confiáveis.

Remova certificados pertencentes a hosts desativados, ex-administradores, sistemas de automação não utilizados ou identidades que não requerem mais acesso.

Quando atividade suspeita é descoberta, investigue o host afetado e o cluster antes de girar credenciais ou modificar evidências.

Fontes relevantes de telemetria podem incluir:

• Logs de serviço do LXD e MicroCloud
• Logs do sistema Linux
• Registros de fluxo de rede e firewall
• Telemetria de proxy reverso, se aplicável
• Dados EDR do host
• Logs de rede em nuvem
• Histórico de configuração e membros do cluster
• Registros de mudanças administrativas

Procure por criação inesperada de instâncias, modificação, exclusão, atividade de snapshot, operações de armazenamento, mudanças na rede e atualizações de configuração.

Se a exploração for suspeita e uma identidade de certificado privilegiada foi personificada, os defensores devem tratar o potencial comprometimento ao nível do host de forma séria, pois a Canonical confirma que o acesso root pode ser possível dependendo das permissões da identidade da vítima.

Os respondedores de incidentes devem preservar evidências relevantes e inspecionar o sistema em busca de persistência, contas ou certificados não autorizados, serviços modificados, novos workloads, processos suspeitos e comunicação de rede externa anormal.

Organizações que usam o Incus em vez do LXD da Canonical devem atualizar separadamente para o Incus 7.6.0 ou a versão corrigida suportada relevante, pois o projeto relacionado foi afetado pela mesma questão subjacente de confiança na cadeia de certificados.

O Ubuntu também observa que suas versões de LXD empacotadas em arquivo para lançamentos do Ubuntu atualmente listados não são enviadas pelo caminho de pacote afetado ou não são afetadas, enquanto a orientação de segurança da Canonical concentra-se nas versões Snap. No entanto, os administradores ainda devem verificar a distribuição real do LXD e a versão em execução em seu ambiente em vez de assumir a exposição com base apenas no lançamento do Ubuntu.

Isenção de responsabilidade: O conteúdo de detecção pode não estar disponível para todos os CVEs. Verifique a Plataforma SOC Prime para obter cobertura atual. Se as detecções relevantes ainda não estiverem disponíveis, verifique novamente, pois novas informações sobre ameaças e conteúdo de detecção são continuamente adicionados.