Uma falha do tipo *use-after-free* no código de rede SCTP do Linux pode ser explorada para obter controle total de *root* em um host, e pesquisadores da Tencent afirmam tê-la usado para escapar de um contêiner e alcançar a máquina subjacente.
A vulnerabilidade existe desde 2008. O *patch* já foi distribuído: os *kernels* estáveis 7.1.6, 6.18.42, 6.12.101 e 6.6.148, lançados em 3 de agosto, corrigem o problema. Quem ainda roda uma versão mais antiga do *kernel* com SCTP acessível deve atualizar.
Rastreada como
CVE-2026-64564
e batizada de SCTPhantom pelos pesquisadores que a encontraram, a falha foi divulgada publicamente em 6 de agosto, dois dias depois de a equipe de CVE do *kernel* atribuir o identificador. Até o momento da publicação, não havia código de *exploit* público, e informaram não ter encontrado a falha no catálogo Known Exploited Vulnerabilities da CISA em 7 de agosto.
A falha é local, não remota, e exige que o SCTP esteja acessível no alvo, o que reduz a superfície de exposição. Quando essas condições estavam presentes, o Tencent Zhuque Lab afirma ter obtido *root* nas versões de *kernel* que testou em Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 e OpenCloudOS.
SCTP é um protocolo de transporte que permite que uma mesma conexão use vários caminhos de rede ao mesmo tempo. Um recurso complementar, chamado reconfiguração dinâmica de endereços, permite que a outra ponta adicione ou remova esses endereços no meio da conexão.
O erro está em uma confusão de identidade. O *kernel* verifica um pedido de exclusão com base no endereço de origem do pacote, mas age sobre um caminho que escolheu usando outro endereço dentro da mensagem. Segundo o próprio comunicado do *kernel*, uma única mensagem pode carregar um endereço, uma exclusão para esse mesmo endereço e, depois, uma exclusão com curinga. Essa sequência libera o caminho e, em seguida, faz o sistema reutilizar o ponteiro inválido, deixando a conexão apontando para uma região de memória que já foi liberada.
O *patch* passou a recusar exclusões direcionadas ao caminho contra o qual a mensagem está sendo processada. A origem da falha remonta ao Linux 2.6.25, em 2008, e ela esteve presente em todas as versões do *kernel* lançadas desde então.
A alegação da Tencent sobre a fuga do contêiner se baseia em testes próprios. No relatório, o laboratório diz que uma versão inicial do *exploit* exigia que os *sysctls* net.sctp.addip_enable e net.sctp.addip_noauth_enable estivessem ativados, o que fazia o CAP_NET_ADMIN parecer um pré-requisito. Depois, a equipe encontrou um caminho que não altera essas configurações, habilitando os recursos por *socket*.
O laboratório afirma que o teste de fuga manteve o perfil padrão do *seccomp* e não concedeu nem CAP_NET_ADMIN nem CAP_SYS_ADMIN. Segundo a contagem divulgada, seis de oito tentativas chegaram a *root* no host.
Nada disso foi reproduzido por terceiros, e o relatório não informa qual *runtime* de contêiner foi testado. O próprio laboratório observa que o acesso a *sockets*, os perfis de *seccomp* e a política de *user namespaces* deslocam a exposição para outros pontos. Um aviso do openKylin sobre a mesma falha vai apenas até *kernel panic* e negação de serviço.
A gravidade também ainda não está fechada. A Tencent atribuiu nota 8,5 na CVSS v4.0. Até 7 de agosto, a NVD ainda não havia publicado nem pontuação nem classificação de fraqueza.
Fabricantes frequentemente incorporam correções em suas distribuições sem mudar para uma nova versão upstream, então a versão do *kernel* sozinha não basta para saber se o sistema está protegido. É preciso consultar o acompanhamento da própria distribuição. Uma segunda falha *use-after-free* relacionada ao mesmo código foi corrigida em 6 de agosto, depois dos lançamentos estáveis de 3 de agosto, portanto essas versões não a carregam. Quando o SCTP não for necessário, bloquear o módulo elimina a superfície de ataque.
A Tencent credita a descoberta ao Corvus AI, um fluxo de pesquisa com múltiplos agentes criado para trabalho em *kernel*, o que faz de SCTPhantom mais um caso de falhas antigas de *kernel* reveladas com ajuda de máquinas neste ano, ao lado de GhostLock, em julho. O caso também chega no mesmo dia do Zapscape, uma fuga de KVM não relacionada, e as mesmas quatro versões estáveis trazem as duas correções.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...