Imagine o seguinte cenário: uma inteligência artificial recebe acesso a uma vulnerabilidade no kernel do Linux. Sem nenhuma credencial, sem interação humana, ela escreve um exploit funcional do zero. Em 48 minutos, quebra o KASLR. Cinco minutos depois, executa comandos como root no servidor alvo. Total: 53 minutos do momento em que começou até acesso total.

Isso não é ficção. Aconteceu no dia 27 de outubro de 2026, quando a Anthropic publicou os resultados de um teste com um modelo Claude não lançado ao público. O alvo? A CVE-2026-98432, uma falha de use-after-free no stack TCP/IPv4 do kernel Linux que recebeu nota 9.8 no CVSS. Crítica. E pra piorar: enquanto você lê isso, Ubuntu e Red Hat ainda não lançaram um patch.

O que é a CVE-2026-98432

A falha mora na função tcp_v4_syn_recv_sock(), responsável por criar um novo socket quando uma conexão TCP é aceita. Durante o handshake TCP (aquele famoso SYN, SYN-ACK, ACK), o kernel precisa copiar as opções IP do pacote para o socket novo.

O problema: ele não copia. Ele passa um ponteiro.

Enquanto isso, em outro núcleo da CPU, o kernel pode estar processando um SYN retransmitido e chamando ip_options_build() com o mesmo ponteiro. Se o socket novo for liberado primeiro (via kfree()), as opções IP são destruídas. Mas a outra CPU ainda está usando aquele ponteiro. Resultado: use-after-free.

// Simplificação do fluxo problemático
// CPU 0: aceita conexão
new_sk = tcp_v4_syn_recv_sock(sk, skb, req);
// new_sk->inet_opt aponta para req->ireq_opt (SEM copiar)

// CPU 1: processa SYN retransmitido
ip_options_build(skb, inet_opt);  // usa o mesmo ponteiro

// CPU 0: libera o socket
inet_csk_destroy_sock(new_sk);    // kfree(inet_opt)
// CPU 1 agora usa memória já liberada -> BOOM

Esse é um bug de race condition clássico. Duas CPUs acessam o mesmo recurso sem sincronização adequada. O detalhe cruel: o bug foi introduzido em outubro de 2015, no kernel 4.4, como parte de uma otimização de performance na pilha TCP. Ficou ali, dormindo, por 11 anos.

Vale notar que o IPv6 não é afetado. A função equivalente, tcp_v6_syn_recv_sock(), faz a coisa certa: copia as opções em vez de apenas apontar pra elas. Alguém esqueceu de aplicar a mesma lógica no IPv4.

Por que a nota 9.8 no CVSS

O time de CVE do kernel Linux atribuiu a pontuação máxima possível na prática:

Traduzindo: qualquer pessoa na internet pode explorar isso, sem precisar de login, sem precisar que alguém clique em nada. E o resultado pode ser execução de código com privilégios de root.

Nem todo mundo concorda com a nota. A Red Hat atribuiu 5.9 (Moderada), argumentando que o cenário prático mais provável é apenas um denial of service, já que corromper memória do kernel de forma controlável exige condições bem específicas. A Oracle e a SUSE deram 8.1. A Amazon, 7.0.

A discrepância faz sentido: explorar uma race condition de forma confiável é difícil. Mas como a Anthropic mostrou, “difícil” não significa “impossível” quando quem está tentando é uma IA que pode rodar milhares de tentativas sem cansar.

Como a IA da Anthropic explorou o bug

Aqui é onde a história fica realmente interessante.

A Anthropic pegou um modelo Claude não lançado (provavelmente da família de pesquisa, mais avançado que o Claude Opus 4.6 disponível ao público) e deu a ele a tarefa de explorar a CVE-2026-98432 em um ambiente de teste com servidores rodando listeners multipath TCP (MPTCP).

O ataque aconteceu em duas fases:

Fase 1: Vazamento de ponteiros do kernel (48 minutos)

O KASLR (Kernel Address Space Layout Randomization) é uma proteção que randomiza os endereços de memória do kernel a cada boot. Sem saber onde as coisas estão na memória, um atacante não consegue montar um exploit confiável.

A IA encontrou uma forma de usar o próprio bug de use-after-free para vazar endereços do kernel. Cada tentativa falhada (cada race condition que não deu certo) não crashava o servidor, apenas falhava aquela conexão TCP específica. Por isso o modelo pôde tentar centenas de vezes até conseguir o vazamento.

Fase 2: Tomada de controle (5 minutos)

Com os endereços em mãos, a IA construiu um payload que sobrescreveu um callback do kernel, redirecionando a execução para código arbitrário. Cinco minutos depois da fase 1, ela já estava executando comandos como root.

Um detalhe que os autores destacaram: “Uma race perdida apenas falha aquela conexão, não crasha o servidor, então um atacante pode continuar tentando.” Isso torna o bug especialmente perigoso, porque a exploração é silenciosa. Nada nos logs indica que alguém está tentando.

A Anthropic não publicou o exploit nem os detalhes de quais versões do kernel foram testadas. Xinyang Ge, pesquisador da Anthropic, foi quem reportou a vulnerabilidade.

Quem está vulnerável (e quem já corrigiu)

Se você administra servidores Linux, presta atenção nessa tabela:

As versões do kernel com o fix são: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3-rc7.

Ou seja: se você roda Ubuntu ou RHEL em produção (e sejamos honestos, metade da internet roda), você está exposto agora. O fix existe no upstream desde 6 de outubro, mas as distros mais populares ainda não empacotaram.

O caso especial do Go 1.24+ e MPTCP

Tem um detalhe que muita gente vai ignorar e não deveria: a partir do Go 1.24, o runtime do Go habilita MPTCP por padrão nas conexões TCP. Isso significa que qualquer servidor escrito em Go 1.24+ que aceita conexões TCP pode estar expondo um listener MPTCP sem que o desenvolvedor tenha pedido explicitamente.

O exploit da Anthropic foi testado especificamente contra listeners MPTCP. Se seu servidor Go está rodando numa versão do kernel vulnerável, a superfície de ataque pode ser maior do que você imagina.

Para verificar se você tem listeners MPTCP ativos:

ss -tlnM
# ou
cat /proc/net/mptcp

Se aparecer algo, você tem MPTCP ativo. Considere desabilitar se não precisa:

// No código Go, forçar TCP puro
listenConfig := net.ListenConfig{
    Control: func(network, address string, c syscall.RawConn) error {
        // Desabilitar MPTCP
        return c.Control(func(fd uintptr) {
            syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, 43, 0) // MPTCP_ENABLED = 43
        })
    },
}

O que fazer agora: mitigação prática

Se você não pode atualizar o kernel imediatamente (e quem roda Ubuntu ou RHEL não pode, porque o patch não chegou), existem medidas de mitigação:

1. Verifique o sysctl tcp_migrate_req

sysctl net.ipv4.tcp_migrate_req

Se o valor for 0 (que é o padrão), uma das duas race conditions não é atingível. Se for 1, mude para 0 imediatamente:

sysctl -w net.ipv4.tcp_migrate_req=0
echo "net.ipv4.tcp_migrate_req=0" >> /etc/sysctl.d/99-cve-2026-98432.conf

2. Filtre opções IP no edge

O exploit depende de opções IPv4 como Record Route e Timestamp. Se você tem um firewall na borda da rede, bloqueie pacotes com essas opções:

# iptables - bloquear opções IP Record Route e Timestamp
iptables -A INPUT -m ipv4options --rr -j DROP
iptables -A INPUT -m ipv4options --ts -j DROP

Na prática, quase nenhum tráfego legítimo usa essas opções. Você pode bloquear sem medo.

3. Monitore sinais de exploração

Fique de olho nos logs do kernel por mensagens envolvendo ip_options_build ou skb_under_panic. Se aparecerem, alguém pode estar tentando explorar a falha (ou já explorou):

dmesg | grep -i "ip_options_build\|skb_under_panic\|use-after-free"
journalctl -k | grep -i "ip_options_build\|skb_under_panic"

4. Prepare o update antecipadamente

Para RHEL, configure o repositório de errata e habilite atualizações automáticas para quando o patch sair:

# RHEL/CentOS
dnf install dnf-automatic
systemctl enable --now dnf-automatic-install.timer

Para Ubuntu:

# Ubuntu
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

IA como ferramenta de ataque: o debate que ninguém quer ter

Vamos falar do elefante na sala. A Anthropic, empresa que faz questão de se posicionar como a mais “segura” no espaço de IA, acabou de demonstrar publicamente que seu modelo consegue criar um exploit remoto de root em menos de uma hora. Sim, foi em ambiente controlado. Sim, eles reportaram a vulnerabilidade responsavelmente. Sim, o Xinyang Ge é pesquisador de segurança da própria Anthropic.

Mas a mensagem é clara: modelos de IA já são capazes de encontrar e explorar vulnerabilidades de dia zero de forma autônoma. Não estamos mais no território teórico. Um modelo sentou, analisou o código, entendeu a race condition, elaborou uma estratégia de duas fases, e executou tudo em menos tempo do que a maioria dos devs leva pra entender o que um use-after-free significa.

A pergunta que fica: se a Anthropic fez isso com um modelo de pesquisa, o que os adversários estão fazendo com modelos open source ajustados especificamente para hacking? Modelos como o WormGPT e o FraudGPT já existem desde 2023. A diferença é que agora os modelos são bons o suficiente para que o exploit funcione de verdade.

Do lado defensivo, a mesma capacidade pode ser usada para encontrar bugs antes dos atacantes. Empresas como Google (com o Project Zero), Microsoft e a própria Anthropic estão investindo pesado em “AI for security”. O problema é a assimetria: um atacante precisa encontrar um bug. O defensor precisa encontrar todos. E as IAs estão ficando muito boas em encontrar o primeiro.

A timeline completa

Para quem gosta de ter o histórico organizado:

11 anos. O bug ficou 11 anos no código. Um commit de otimização de performance que ninguém questionou, em uma função que todo servidor Linux do planeta usa toda vez que alguém faz uma conexão TCP.

Comparativo: quem corrigiu mais rápido

Vale olhar os tempos de resposta de cada distribuição, porque dizem muito sobre como a segurança é tratada em cada ecossistema:

O Oracle Linux (UEK) foi o mais rápido: em um dia após a publicação da CVE, já tinha pacotes prontos. Amazon seguiu em 9 dias. SUSE demorou 14 dias. Debian, que costuma ser mais conservador, também já corrigiu.

Ubuntu e RHEL, as duas distribuições mais usadas em servidores empresariais, ficaram pra trás. A Red Hat classificou o bug como “deferred” sem data prevista. A Canonical disse que está “em progresso”, mas sem pacotes disponíveis. Se você paga por suporte enterprise, esse é o tipo de situação que justifica abrir um ticket de severidade máxima.

O que isso muda pra você

Se você é dev e não mexe com infraestrutura, talvez ache que isso não te afeta. Mas se seu deploy roda num container Linux (e roda), se sua CI/CD usa runners Linux (e usa), se seu banco de dados está num servidor Linux (e está), então sim, te afeta.

A ação imediata: fale com quem cuida da infra. Pergunte qual kernel vocês estão rodando. Se for Ubuntu ou RHEL, pergunte se as mitigações (sysctl, iptables) já foram aplicadas. Se ninguém souber do que você está falando, mande este artigo.

E se você usa Go 1.24+, cheque se o MPTCP está habilitado nos seus listeners. Essa é a parte que mais gente vai perder.

A CVE-2026-98432 vai ser corrigida eventualmente. Todas são. Mas o fato de que uma IA transformou um bug de race condition em root remoto em menos de uma hora? Isso não é uma vulnerabilidade que se corrige com um patch. Isso é o novo normal.