A SCTPhantom (CVE-2026-64564) é uma use-after-free no processamento ASCONF do protocolo SCTP no kernel Linux. Um usuário local sem privilégio pode explorar a corrupção para obter root; o laboratório também demonstrou escape de container. Existe exploit público, tornando prioritária a confirmação de patch ou o bloqueio do módulo em hosts que não usam SCTP.
O que aconteceu
A falha ocorre quando a reconfiguração dinâmica de endereços SCTP manipula a vida útil de estruturas internas de modo incorreto. A condição de corrida libera um objeto enquanto outro caminho ainda o utiliza. Pulverização de heap e controle do fluxo permitem transformar o defeito em elevação de privilégio no host.
“Local” inclui código executado por uma conta de hospedagem, aplicação comprometida, job de CI ou container. Como containers compartilham o kernel, isolamento de namespace não corrige o componente vulnerável. A rota exige SCTP presente e alcançável; muitos servidores web não precisam desse protocolo e podem bloqueá-lo durante a janela de atualização.
Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.
Versões e ambientes afetados e corrigidos
| Produto ou linha | Afetado / exposto | Corrigido / protegido |
|---|---|---|
| Linux upstream 5.10 | antes de 5.10.265 | 5.10.265+ |
| Linux upstream 5.15 | antes de 5.15.216 | 5.15.216+ |
| Linux upstream 6.1/6.6/6.12 | antes de 6.1.183/6.6.148/6.12.101 | respectivos builds ou posteriores |
| CloudLinux 7h/8/9/10 e CL9 LTS | afetado conforme kernel e disponibilidade SCTP | KernelCare main feed ou kernel vendor corrigido |
| CloudLinux 7, CL8 LTS e CL Ubuntu 22.04 | consultar status específico da linha | mitigação e kernel/ELS conforme advisory |
A existência do arquivo sctp.ko indica código disponível; módulo carregado confirma superfície ativa. Em sistemas com autoload, uma operação de rede pode carregá-lo mesmo que não apareça no lsmod naquele instante. Bloqueio persistente deve ser conferido com modprobe, sem forçar carregamento vulnerável.
Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.
Nível de risco e impacto
Alto, com divergência de pontuação. O CNA Linux registra CVSS 3.1 9,8, enquanto a avaliação usada por CloudLinux/Red Hat cita 7,8 e severidade Moderate. A diferença decorre de premissas de alcance, mas o resultado demonstrado — root e escape de container com exploit público — exige prioridade alta em hosting multi-tenant.
Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.
Como verificar se o servidor ou site está vulnerável
Identifique kernel, disponibilidade do módulo, uso ativo e livepatch. Não rode o exploit. Se SCTP sustenta telecomunicação ou cluster, envolva o responsável antes de bloquear ou descarregar o módulo.
uname -r
modinfo sctp 2>/dev/null | head -12
lsmod | grep '^sctp'
grep -R '^[[:space:]]*install[[:space:]]\+sctp' /etc/modprobe.d 2>/dev/null
kcarectl --patch-info 2>/dev/null | grep CVE-2026-64564Módulo disponível sem bloqueio e kernel no intervalo afetado requer patch ou mitigação. Linha explícita da CVE no patch-info confirma cobertura KernelCare; apenas dizer que KernelCare está ativo não basta. Kernel novo instalado mas uname antigo exige reboot.
Como corrigir ou mitigar
Instale o kernel corrigido da sua distribuição ou aplique o livepatch correspondente e confirme a CVE. Se o servidor não usa SCTP, bloqueie autoload como contenção; descarregue o módulo apenas após verificar dependências e conexões. Linhas ELS e CloudLinux for Ubuntu devem seguir exatamente o status do fornecedor, que pode diferir do feed principal.
dnf update 'kernel*'
kcarectl --update
kcarectl --patch-info | grep CVE-2026-64564
printf 'install sctp /bin/false
' | tee /etc/modprobe.d/disable-sctp.confAntes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.
Validação posterior e resposta a incidentes
Confirme livepatch ou kernel ativo e teste modprobe sctp somente quando a política esperada for bloqueio. Valide rede e aplicações. Durante a janela anterior, procure oops/panics, módulos e namespaces incomuns, processos privilegiados, arquivos SUID, chaves e mudanças em containers. Um sinal de exploração exige reconstrução confiável ou perícia completa.
Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.
Medidas adotadas pela WebinHost
A WebinHost cruza kernel, módulo e workload para aplicar KernelCare quando há cobertura ou bloquear SCTP quando o protocolo não é necessário, evitando reboot sempre que tecnicamente seguro. CloudLinux/CageFS e Imunify360 reduzem a chance de uma aplicação comprometida alcançar o caminho local, mas não são prova de correção desta CVE.
Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.
O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.
Tutoriais, downloads e serviços relacionados
Use estes materiais para continuar a verificação com segurança:
Referências oficiais e técnicas
Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.
Assistente IA WGS