Pesquisadores do Tencent Zhuque Lab identificaram uma vulnerabilidade no kernel Linux relacionada à implementação do protocolo SCTP — Stream Control Transmission Protocol.
A falha recebeu o identificador:
CVE-2026-64564
e foi apelidada pelos pesquisadores de:
SCTPhantom
Segundo a pesquisa divulgada, o problema existe desde o Linux 2.6.25, lançado em 2008, o que significa que permaneceu presente no código por aproximadamente 18 anos.
A vulnerabilidade é classificada tecnicamente como um use-after-free, tipo de falha de gerenciamento de memória em que um programa continua utilizando uma região de memória depois que ela já foi liberada.
Em determinadas condições, esse comportamento pode ser explorado para executar operações não autorizadas dentro do kernel.
O que é SCTP?
O SCTP — Stream Control Transmission Protocol é um protocolo de transporte, assim como TCP e UDP.
Uma de suas principais características é permitir que uma única associação utilize múltiplos endereços e caminhos de rede.
Essa funcionalidade é conhecida como multi-homing.
O SCTP também possui mecanismos capazes de adicionar ou remover endereços dinamicamente durante uma conexão.
É justamente nessa parte da implementação que a vulnerabilidade foi identificada.
Como a vulnerabilidade funciona?
O problema acontece durante o processamento de determinadas operações de reconfiguração de endereços SCTP.
Segundo a descrição técnica divulgada, o kernel pode remover uma estrutura utilizada para representar um caminho de comunicação e posteriormente continuar utilizando uma referência para aquela estrutura.
Em termos simples:
- Uma estrutura de rede é criada na memória.
- Uma operação SCTP provoca sua remoção.
- A memória correspondente é liberada.
- Uma referência antiga continua sendo utilizada.
- O kernel passa a acessar memória que já não deveria estar disponível.
Esse cenário caracteriza um use-after-free.
Como o problema ocorre dentro do kernel Linux, uma exploração bem-sucedida pode ter consequências graves.
Exploração pode permitir acesso root
A vulnerabilidade exige acesso local ao sistema.
Portanto, segundo as informações disponíveis até o momento, ela não representa uma vulnerabilidade de execução remota direta pela internet.
Entretanto, um atacante que já possua acesso limitado a um servidor poderia potencialmente utilizar a falha para aumentar seus privilégios.
Os pesquisadores da Tencent afirmam ter conseguido obter root nos sistemas testados.
Entre os ambientes mencionados nos testes estão versões baseadas em:
- Debian 13;
- Ubuntu 24.04;
- Rocky Linux 9;
- Red Hat Enterprise Linux 9;
- OpenCloudOS.
É importante destacar que esses sistemas representam os ambientes testados pelos pesquisadores e não necessariamente uma lista completa de todas as distribuições afetadas.
Pesquisadores também demonstraram fuga de container
Um dos aspectos mais relevantes da pesquisa envolve ambientes virtualizados através de containers.
O Tencent Zhuque Lab afirma ter utilizado a vulnerabilidade para realizar um container escape.
O que é container escape?
Containers utilizam recursos do kernel Linux para separar aplicações e processos.
A ideia é que um processo executado dentro de um container permaneça isolado do sistema operacional hospedeiro.
Uma fuga de container acontece quando um processo consegue romper essa separação e acessar recursos do host.
Nesse cenário:
Container → exploração do kernel → host Linux → acesso root
Segundo os pesquisadores, o teste foi realizado sem conceder ao container privilégios poderosos como:
CAP_SYS_ADMIN
ou
CAP_NET_ADMIN
na versão final da técnica utilizada.
Exploração não foi confirmada independentemente
Existe um ponto importante.
Até a publicação da pesquisa, a demonstração de container escape havia sido apresentada pelo próprio Tencent Zhuque Lab.
Segundo o The Hacker News, não havia reprodução pública independente dessa técnica no momento da publicação.
O runtime de containers utilizado nos testes também não foi especificado publicamente na matéria.
Portanto, a possibilidade de fuga de container deve ser tratada como resultado relatado pelos pesquisadores, e não como uma exploração universalmente reproduzida em qualquer ambiente de containers.
Quais versões possuem correção?
As correções foram incorporadas às seguintes versões estáveis do kernel Linux, lançadas em 3 de agosto de 2026:
- Linux 7.1.6;
- Linux 6.18.42;
- Linux 6.12.101;
- Linux 6.6.148.
Administradores não devem, entretanto, verificar apenas o número bruto da versão do kernel.
Distribuições como Ubuntu, Debian, Red Hat e outras frequentemente realizam backport de correções, incorporando patches de segurança em versões anteriores sem alterar para a versão mais recente disponibilizada pelo projeto Linux.
Por isso, a recomendação correta é consultar também o boletim de segurança da distribuição utilizada.
Qual é a gravidade?
A Tencent atribuiu à vulnerabilidade uma pontuação CVSS 4.0 de 8,5, classificada como alta.
Porém, segundo as informações disponíveis em 7 de agosto, o NVD ainda não havia atribuído sua própria avaliação oficial de severidade à CVE.
Essa diferença é importante.
A pontuação de 8,5 deve ser apresentada como avaliação dos pesquisadores, e não como pontuação definitiva do NVD.
Existe exploração ativa?
Até a publicação da matéria em 7 de agosto de 2026, não havia indicação pública de código de exploração amplamente disponível.
A vulnerabilidade também não estava listada no catálogo Known Exploited Vulnerabilities — KEV, mantido pela CISA, de acordo com a verificação realizada pelo The Hacker News naquela data.
Isso não significa que exploração seja impossível.
Significa apenas que, naquele momento, não havia evidência pública confirmada de exploração ativa em larga escala.
Como se proteger?
A principal recomendação é atualizar o kernel através dos repositórios oficiais da distribuição Linux utilizada.
Administradores devem verificar especificamente se o patch relacionado à:
CVE-2026-64564
já está presente.
Ambientes que não utilizam SCTP
Caso o servidor não utilize SCTP, reduzir a disponibilidade desse protocolo também diminui a superfície de ataque.
Desabilitar ou impedir o carregamento do módulo SCTP pode ser considerado em ambientes onde o protocolo não possui nenhuma função operacional.
Porém, antes de realizar essa alteração em produção, é necessário verificar se aplicações ou serviços existentes dependem dele.
Servidores e ambientes de containers
A prioridade deve ser maior em:
- servidores multiusuário;
- ambientes de hospedagem;
- infraestrutura cloud;
- clusters de containers;
- servidores Kubernetes;
- plataformas compartilhadas;
- sistemas nos quais usuários ou workloads não confiáveis possuem acesso local.
Análise Técnica CyberX
O principal risco é a escalada de privilégios
A vulnerabilidade não deve ser interpretada como uma falha que permite que qualquer atacante na internet simplesmente assuma o controle de um servidor Linux.
O atacante precisa inicialmente possuir uma forma de executar código localmente e alcançar a funcionalidade SCTP necessária.
O cenário mais preocupante é, portanto:
acesso limitado → exploração do kernel → root
Esse tipo de vulnerabilidade funciona frequentemente como segundo estágio de um ataque.
Um invasor pode inicialmente comprometer uma aplicação web ou obter acesso a um usuário com poucos privilégios.
Posteriormente, utiliza uma vulnerabilidade no kernel para assumir completamente o servidor.
Container escape aumenta significativamente o impacto potencial
A possibilidade relatada de escapar de containers torna o problema especialmente relevante para ambientes cloud.
Containers compartilham o kernel do host.
Essa característica é diferente de máquinas virtuais tradicionais, onde cada VM normalmente possui seu próprio kernel.
Por isso, vulnerabilidades no kernel Linux podem comprometer justamente a camada responsável por manter o isolamento entre container e host.
Se a técnica descrita pela Tencent for reproduzível em outros ambientes, um cenário poderia ser:
Aplicação vulnerável dentro de um container
↓
Execução de código no container
↓
Exploração da CVE-2026-64564
↓
Fuga do isolamento
↓
Acesso root ao host
↓
Possível acesso a outros containers
Esse encadeamento é muito mais grave do que o comprometimento isolado de uma única aplicação.
Não basta olhar a versão do Linux
Outro ponto importante para administradores é o modelo de atualização das distribuições.
Um servidor utilizando um kernel aparentemente "antigo" pode já possuir o patch através de backport.
Da mesma forma, simplesmente comparar:
uname -r
com a versão mais nova publicada pelo kernel.org pode produzir conclusões incorretas.
A validação deve considerar o boletim da distribuição e o pacote efetivamente instalado.
O que equipes de infraestrutura devem verificar
A CyberX recomenda verificar principalmente:
- presença da CVE no boletim da distribuição;
- kernel instalado;
- patches disponíveis;
- necessidade operacional do SCTP;
- possibilidade de usuários não confiáveis executarem código local;
- containers executando workloads de terceiros;
- políticas de seccomp;
- capabilities concedidas aos containers;
- exposição desnecessária de módulos do kernel.
Recomendação CyberX
A prioridade imediata deve ser aplicar as atualizações oficiais fornecidas pela distribuição Linux.
Em ambientes críticos, especialmente aqueles que executam containers ou múltiplos usuários, essa vulnerabilidade merece prioridade elevada porque envolve diretamente a segurança do kernel.
Caso SCTP não seja utilizado, eliminar essa superfície de ataque também pode funcionar como uma medida adicional de hardening.
Conclusão
A CVE-2026-64564 demonstra como um erro antigo no kernel pode permanecer silencioso durante muitos anos e posteriormente adquirir relevância conforme a infraestrutura muda.
Uma falha introduzida em 2008 passa a ter implicações especialmente importantes em 2026 devido ao uso massivo de containers e plataformas cloud baseadas em Linux.
A vulnerabilidade exige acesso local e condições específicas relacionadas ao SCTP, o que reduz sua superfície quando comparada a uma falha remota.
Por outro lado, a possibilidade de elevação para root e o container escape relatado pelos pesquisadores tornam a atualização especialmente importante para servidores compartilhados e ambientes de containers.
O ponto principal para equipes de segurança é simples:
uma aplicação isolada em container continua dependendo da segurança do kernel que existe abaixo dela.
UNC6671 usa ligações falsas de suporte para roubar acessos corporativos e dados d…O grupo de ameaça rastreado como UNC6671 está utilizando ligações telefônicas fraudulentas para se passar por equip…
Ataque ClickFix distribui malware para macOS capaz de roubar senhas e criptomoedasPesquisadores da Huntress identificaram uma campanha de engenharia social baseada na técnica ClickFix que induz usu…
Quase 800 pacotes maliciosos no npm distribuem malware para Windows, Linux e macOSPesquisadores descobriram uma campanha em larga escala que publicou centenas de pacotes maliciosos no npm. Os pacot…
Como uma Página Web Hackeou o AWS KiroUm simples pedido para resumir uma página web era o suficiente para que o assistente de programação da AWS, o Kiro,…
O Fim do Prazo de Segurança!A velocidade com que vulnerabilidades conhecidas são exploradas por cibercriminosos acelerou drasticamente. O antig…
Engenheiro FantasmaUma nova ameaça utiliza ferramentas de IA para automatizar ataques complexos, tornando cibercriminosos novatos em o…