O que o SCTPhantom realmente compromete
O CVE-2026-64564 - apelidado SCTPhantom por alguns dos investigadores que o noticiaram - é uma vulnerabilidade use-after-free na implementação SCTP do kernel Linux, o Stream Control Transmission Protocol usado sobretudo na sinalização de telecomunicações, nalguns sistemas de mensagens financeiras e nalgumas pilhas de rede de contentores e clusters. A falha reside especificamente no ASCONF, o código que trata a Reconfiguração Dinâmica de Endereços e que permite a uma associação SCTP ativa adicionar ou remover endereços IP sem encerrar a ligação. O CVE foi anunciado formalmente a 4 de agosto de 2026, após um processo de divulgação privada que já tinha começado a 12 de julho de 2026.
A causa raiz é uma discrepância de identidade: quando o kernel processa um pedido DEL-IP para remover um endereço de uma associação, valida esse pedido com base no endereço de origem do pacote recebido, enquanto um ponteiro em cache separado, dentro do kernel, continua a basear-se no endereço indicado no próprio parâmetro do pedido. Um atacante que construa uma sequência deliberadamente ordenada de chunks ASCONF pode explorar essa lacuna entre as duas verificações para libertar uma zona de memória do kernel enquanto um ponteiro ativo ainda lhe aponta - a definição de manual de uma use-after-free, e um dos recursos mais fiáveis para transformar uma falha do kernel em execução real de código.
Dezoito anos são a manchete, não a lição
O código responsável remonta ao Linux 2.6.25, lançado em dezembro de 2007, o que coloca a falha com cerca de 18 anos no momento em que o Zhuque Lab da Tencent a encontrou. Os investigadores atribuem a descoberta à Corvus AI, um pipeline autónomo multiagente de investigação de vulnerabilidades que a equipa opera internamente, e que sinalizou o percurso de código ASCONF como merecedor de uma revisão manual mais aprofundada. Este pormenor conta quase tanto como a própria falha: não se trata de uma zona do kernel conhecida como arriscada a ser finalmente auditada, mas de um recanto genuinamente pouco visitado que quase ninguém examinou a fundo durante quase duas décadas.
As correções estáveis chegaram a 3 de agosto de 2026 nos ramos do kernel 6.6.148, 6.12.101, 6.18.42 e 7.1.6, e as equipas responsáveis pelas distribuições já começaram a integrá-las nas suas árvores de pacotes. Esta é a parte da história que todos os meios estão a noticiar, e é também a parte que menos importa para a maioria dos leitores. Um intervalo de 18 anos entre o aparecimento da falha e a sua descoberta prova que uma política de espera pela correção já tinha falhado silenciosamente durante dezoito anos precisamente neste percurso de código - não há motivo para presumir que o próximo recanto por examinar do kernel será encontrado mais depressa, razão pela qual reduzir aquilo que é realmente alcançável numa dada máquina importa independentemente de qualquer data de correção específica.
Acesso root e fuga de contentores, demonstrados
O Zhuque Lab da Tencent demonstrou o exploit de ponta a ponta, não apenas um crash. Em sistemas com Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 e OpenCloudOS, a equipa transformou a use-after-free numa escalada completa de privilégios para root a partir de uma conta local sem privilégios, e usou depois a mesma técnica para escapar de um contentor para o anfitrião em seis das oito tentativas, sem necessitar de CAP_NET_ADMIN nem de CAP_SYS_ADMIN, as capacidades elevadas que a maioria dos guias de blindagem de contentores presume como primeiro requisito de um atacante.
A cadeia de exploração contornou a randomização do espaço de endereços do kernel, encadeou uma segunda use-after-free recorrendo a chaves de autenticação SCTP controladas pelo atacante, e construiu um grafo de objetos do kernel falsificado para alcançar root, tudo sem shellcode nem uma cadeia de programação orientada ao retorno, precisamente as técnicas que a maioria das mitigações de exploits de kernel está desenhada para intercetar. Os testes abrangeram versões do kernel desde a 5.14 até ao candidato a lançamento 7.2, e a correção upstream chegou como o commit 9b2854f86f0b antes de ser retroportada para os quatro ramos estáveis referidos acima.
A correção simples que a maioria das equipas ignora
A correção é real e vale a pena aplicá-la, mas trata um sintoma. Quase nenhuma das organizações que utilizam estas cinco distribuições escolheu ativar o SCTP - vem compilado por omissão diretamente no kernel principal, e a maioria dos responsáveis não faz ideia de que está ali, muito menos de que um processo local lhe consegue aceder. Esta é a lição verdadeira escondida no próprio tópico de divulgação oss-security dos investigadores: um participante no tópico salientou que os sistemas da família RHEL mantêm o SCTP desativado por omissão, distribuído como pacote separado kernel-modules-extra com o carregamento automático em lista negra, enquanto os kernels das famílias Debian e Ubuntu integram o SCTP diretamente e deixam-no carregar assim que qualquer processo o solicita. Dois sistemas podem ter exatamente o mesmo CVE e enfrentar um risco real muito diferente, e essa diferença nada tem a ver com a correção instalada.
A medida que vale a pena tomar esta semana não é esperar pela atualização da distribuição, mas verificar se o SCTP está sequer a fazer algo útil numa dada frota de servidores. O comando lsmod | grep sctp mostra se o módulo está atualmente carregado; verificar /etc/modprobe.d/ em busca de uma entrada de lista negra existente mostra se o carregamento automático já está bloqueado. Onde nada depende legitimamente do SCTP - e na maioria dos servidores de uso geral não depende nada - colocar o módulo em lista negra fecha a porta independentemente de qual versão do kernel venha a chegar, um hábito alinhado com o que o CNCS (Centro Nacional de Cibersegurança) recomenda em Portugal para qualquer módulo de kernel não utilizado, não apenas para este.
Leia a seguir: A sua MSP tem uma segunda falha de contorno | A chamada que contorna o MFA da sua empresa
