Resumo executivo

Nota: Este alerta destina-se a administradores de infraestrutura, equipes de segurança e pesquisadores.

Uma vulnerabilidade de use-after-free na pilha SCTP do kernel Linux, apelidada SCTPhantom (CVE-2026-64564), permite que um atacante com acesso local não privilegiado escale para root no host e, em testes públicos, realize escape de container para o host. A falha está presente desde o kernel 2.6.25 (há ~18 anos) e foi corrigida no upstream em agosto/2026.

Atualização importante (01/09/2026): na divulgação inicial (06/08) não havia código de exploração público. Isso mudou. Já circulam PoCs públicos de escalada local e de escape de container (mirrors de comunidade visando, por exemplo, Debian 13 com kernel 6.12.95). Com exploit público disponível, a urgência de aplicação do patch aumentou de forma significativa em relação ao cenário original.

Para ambientes Proxmox VE e outras plataformas de virtualização baseadas em kernel PVE, o risco é alto em hosts com o módulo sctp carregado ou carregável por código não confiável, especialmente em cenários multi-tenant, laboratórios e ambientes de pesquisa.

---

O que é SCTPhantom?

SCTPhantom é um bug de use-after-free no tratamento de ASCONF (Dynamic Address Reconfiguration) do protocolo SCTP no kernel Linux. O ASCONF é definido pela RFC 5061 (o SCTP base é a RFC 4960).

Em termos simples:

• Uma associação SCTP pode ter múltiplos caminhos (multihoming), cada um representado por um struct sctp_transport.
• O chunk ASCONF permite adicionar/remover endereços dinamicamente (ADD-IP, DEL-IP, SET-PRIMARY).
• A vulnerabilidade surge de uma inconsistência de identidade: o endereço usado para validar um DEL-IP (o endereço de origem do pacote) é diferente do endereço usado para selecionar qual transport permanece cacheado para o processamento subsequente do ASCONF.

Com uma sequência ordenada de parâmetros ASCONF, o atacante consegue:

1. Fazer o kernel remover um transport da lista de peers.
2. Manter um ponteiro cacheado (asconf->transport, primary_path, active_path) apontando para esse transport já liberado.
3. Acessar esse ponteiro “fantasma” em operações posteriores, caracterizando um use-after-free explorável.

---

Impacto comprovado

Pesquisadores do Tencent Zhuque Lab (via pipeline de pesquisa multi-agente Corvus AI) demonstraram:

• Escalada local para root em múltiplas distribuições e versões de kernel, entre elas Debian 13 (kernel 6.12.95), Ubuntu 24.04 (6.8.0-134), Rocky Linux 9 / RHEL 9 (kernel vendor 5.14, com SCTP carregado) e OpenCloudOS. O exploit foi ainda validado no kernel de pesquisa 7.2-rc2.
• Escape de container para o host em configurações padrão, desde que o exploit consiga usar sockets SCTP e as primitivas necessárias. Em um conjunto de testes reportado, foram obtidos seis escapes bem-sucedidos para root do host em oito tentativas em container — o que não significa que todo container esteja exposto: as condições variam por distribuição e por plataforma de container.

A cadeia de exploração, em alto nível, inclui:

• Sobrevivência do UAF do sctp_transport.
• Reuso da memória via pg_vec (TPACKET / PACKET_TX_RING) para obter vazamento de endereço do kernel (direct-map).
• Leitura controlada de 4 bytes via SCTP_STATUS.
• Recuperação de KASLR via IDT.
• Reuso da memória por dados controlados de autenticação SCTP e chamada a commit_creds() para root global.
• Variante com call_usermodehelper_exec() para escape de container.

Sobre a pontuação e o vetor: local × remoto

Aqui há uma nuance que vale registrar, porque os CNAs divergem:

• O writeup da Tencent reporta CVSS v4.0 8.5 (High), com vetor de acesso local (AV:L), refletindo a cadeia de escalada de privilégios demonstrada.
• A Red Hat pontua em CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H e classifica o impacto como Moderate em seus produtos, porque o módulo sctp vem desabilitado por padrão no RHEL 8, 9 e 10.
• O registro no cve.org traz CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — ou seja, vetor de rede.

A diferença não é acadêmica. A escalada de privilégios demonstrada é local, mas a corrupção de memória em si tem superfície de gatilho acessível pela rede em hosts que efetivamente rodam serviços SCTP: um atacante remoto pode enviar uma sequência maliciosa de chunks ASCONF/DEL-IP e disparar o use-after-free, com potencial de crash (negação de serviço) e, potencialmente, execução de código. Para hosts que expõem serviços SCTP legítimos (sinalização, telecom, HA), esse vetor de rede deve entrar na modelagem de risco, e não apenas o cenário de atacante local.

---

Disponibilidade de exploit público

No momento da divulgação coordenada (06/08/2026), não havia código de exploração público, e a falha não constava no catálogo KEV da CISA em 07/08. Desde então, surgiram PoCs públicos mantidos por terceiros, incluindo implementações de escalada local para root e de escape de container, com offsets ajustados para kernels específicos (por exemplo, Debian 13 / 6.12.95).

Consequências práticas:

• A barreira para exploração caiu: não é mais necessário reproduzir a pesquisa original do zero.
• A janela entre “vulnerável” e “explorado” tende a encurtar em ambientes expostos.
• A prioridade de patch deve ser tratada como elevada em qualquer host que atenda às pré-condições, mesmo que ainda não haja registro em KEV.

---

Por que isso importa em Proxmox / virtualização

Ambientes Proxmox VE rodam kernels PVE derivados do kernel Linux principal (base Debian). O advisory PSA-2026-00037-1 (10/08/2026) descreve exatamente o CVE-2026-64564 e indica:

• Correção nos kernels:
  • proxmox-kernel-7.0.14-10-pve(-signed) (produtos baseados em Trixie)
  • proxmox-kernel-6.8.12-41-pve(-signed) (produtos baseados em Bookworm)
• Mitigação imediata: impedir o carregamento do módulo sctp onde ele não for necessário.

Um ponto crítico específico do ecossistema Debian/Proxmox: ao contrário do RHEL — onde o sctp é desabilitado por padrão — distribuições baseadas em Debian tendem a autocarregar o módulo sob demanda quando um processo (mesmo não privilegiado) cria um socket SCTP.

É por isso que “não uso SCTP” não é, por si só, garantia de segurança: sem bloqueio explícito, o próprio atacante pode provocar o carregamento do módulo e, então, montar a cadeia de exploração.

Em um host Proxmox:

• Um usuário local ou processo em container/VM com acesso à rede pode, em tese, abrir sockets SCTP e disparar o autoload do módulo.
• Se o módulo sctp estiver disponível e o atacante puder criar associações multihomed, as condições para exploração podem ser atendidas.
• Um escape de container compromete o host inteiro, afetando todas as VMs/containers e serviços rodando nele.

---

Condições necessárias para exploração

Apesar da gravidade, a exploração exige uma cadeia de condições:

• SCTP disponível: módulo sctp carregado ou carregável no kernel (lembrando o autoload sob demanda em distros Debian-based).
• ASCONF utilizável: o ASCONF pode ser habilitado por socket (SCTP_ASCONF_SUPPORTED, SCTP_AUTH_SUPPORTED), mesmo com net.sctp.addip_enable=0 em kernels mais recentes.
• Associação multihomed com caminho secundário ACTIVE: o exploit precisa de um transport confirmado e ativo.
• Acesso local / container: para a cadeia de escalada de privilégios, o atacante já precisa ter execução de código no host ou em um container que compartilha o kernel. (O vetor de rede descrito acima é relevante à parte, para DoS/potencial RCE em serviços SCTP expostos.)
• Primitivas de socket, namespace, seccomp, capabilities e LSM que permitam montar a cadeia (varia por distribuição e política).

Em servidores web/API genéricos, sem SCTP em uso e com políticas restritivas, a probabilidade pode ser baixa, mas o impacto permanece severo — e a existência de exploit público reduz a margem de conforto.

---

Versões corrigidas (kernel Linux)

O fix upstream está no commit 9b2854f86f0b e foi backportado para as seguintes primeiras versões estáveis, conforme o anúncio do Linux kernel CVE team:

• 6.6.y → a partir de 6.6.148
• 6.12.y → a partir de 6.12.101
• 6.18.y → a partir de 6.18.42
• 7.1.y → a partir de 7.1.6
• Mainline → 7.2-rc5

Kernels vendor (incluindo PVE) podem carregar o backport mantendo strings de versão de base mais antigas; portanto, compare sempre com o advisory do fornecedor, e não apenas com o número de versão do kernel.

No caso Proxmox, usar ao menos:

• proxmox-kernel-7.0.14-10-pve (Trixie)
• proxmox-kernel-6.8.12-41-pve (Bookworm)

---

Recomendações para administradores

1. Atualizar o kernel dos hosts

Em hosts Proxmox e outros servidores Linux:

• Aplique as atualizações de kernel indicadas pelo fornecedor.
• Reinicie os hosts para carregar o novo kernel.
• Verifique a versão com uname -r e compare com os advisories.

2. Avaliar a necessidade de SCTP e bloquear o módulo

Verifique se SCTP está em uso:

lsmod | grep sctp
cat /proc/net/sctp/associations 2>/dev/null

Se SCTP não for necessário, bloqueie o carregamento do módulo. O ponto essencial é neutralizar o autoload sob demanda — por isso a diretiva install ... /bin/true, e não apenas um blacklist:

cat > /etc/modprobe.d/disable-sctp.conf <<'EOF'
install sctp /bin/true
blacklist sctp
EOF

Regenere o initramfs conforme a distribuição, se necessário, e valide que o módulo não sobe:

update-initramfs -u        # Debian/Proxmox
modprobe sctp; lsmod | grep sctp   # deve permanecer vazio

Isso reduz drasticamente a superfície de ataque, mesmo antes da atualização do kernel — e vale especialmente em distros Debian-based (Proxmox incluído), onde o módulo não vem desabilitado por padrão como no RHEL.

3. Revisar políticas de containers e usuários locais

• Restrinja o uso de raw/packet sockets e capacidades de rede em containers não confiáveis.
• Reforce perfis seccomp, AppArmor/SELinux e políticas de user namespaces. Em Kubernetes, o Restricted Pod Security Standard remove parte das primitivas usadas pela cadeia pública.
• Em ambientes multi-tenant ou de pesquisa, trate qualquer código de terceiros como potencialmente hostil.

4. Monitoramento

Como camada adicional:

• Monitore o carregamento repentino do módulo sctp em hosts que nunca o utilizaram.
• Considere alertas para:
  • modprobe sctp / autoload do módulo;
  • criação de sockets SCTP em hosts/serviços que não deveriam usar o protocolo.

---

Cenários de risco

Cenário	Probabilidade	Impacto	Prioridade
Host genérico (web/API), SCTP não usado e módulo bloqueado	Muito baixa	Severo	Média/Baixa (após confirmar SCTP indisponível)
Host Debian-based sem SCTP em uso, mas com autoload não bloqueado	Baixa a média	Severo	Média/Alta (bloquear módulo + patch)
Host com SCTP em uso, mas sem ASCONF/multihoming intencional	Baixa	Severo	Média
Hosts de sinalização/telecom/HA com SCTP + ASCONF + multihoming (inclui superfície de rede)	Elevada	Severo	Alta (patch imediato)
Containers/VMs em qualquer um dos cenários acima	Depende do host	Severo	Alta para o host (risco de escape)

---

Contexto de descoberta e implicações para segurança

SCTPhantom foi descoberta e desenvolvida por um pipeline de pesquisa multi-agente (Corvus AI) do Tencent Zhuque Lab, que manteve registro detalhado de evidências, restrições e resultados negativos ao longo do processo. É mais um caso, em 2026, de falha antiga de kernel trazida à tona com auxílio de máquina.

Isso ilustra uma tendência importante:

• IA está sendo usada para encontrar bugs em protocolos obscuros e pouco testados.
• A suposição de que “stacks raras são seguras por serem raras” está cada vez mais frágil.

Para equipes de segurança: cobertura de patch e monitoramento deve incluir também os “cantos quietos” da plataforma, ou seja, protocolos legados, módulos pouco usados e caminhos de código raramente exercitados.

---

Referências

• Proxmox Security Advisory PSA-2026-00037-1: forum.proxmox.com
• Tencent Zhuque Lab – SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free: matrix.tencent.com
• Divulgação oss-sec (openwall): seclists.org/oss-sec/2026/q3/457
• Anúncio do Linux kernel CVE team: lore.kernel.org
• Red Hat – CVE-2026-64564: access.redhat.com
• Registro CVE (cve.org): cve.org
• NVD: nvd.nist.gov
• Tenable: tenable.com
• Threat modeling de SCTPhantom (MSBiro): msbiro.net
• Commit do fix upstream (9b2854f86f0b): git.kernel.org
• Commit que introduziu a sequência vulnerável (42e30bf3463c, 2.6.25): git.kernel.org

---