As cadeias de exploits da Anthropic: o problema não é o modelo, é o atraso nos patches

É assustador que uma IA consiga escrever um exploit funcional para Chrome, Safari e Linux? Menos do que a pergunta chata por trás disso: quando o próximo for encontrado, quem vai tê-lo em mãos antes de o patch sair?

Eis o que aconteceu. Em 27 de outubro, o Frontier Red Team da Anthropic publicou um artigo de pesquisa dizendo que, nos últimos meses, um modelo interno de pesquisa ainda não lançado encontrou vulnerabilidades críticas em navegadores e sistemas operacionais. Segundo o The Hacker News, o modelo encadeou falhas em exploits de prova de conceito funcionais para Chrome, Safari, Android, Windows e Linux. Esses exploits foram criados em laboratório, depois de receber instruções, não foram vistos em ataques reais, e cada falha foi comunicada antes ao fabricante, então todas já foram corrigidas.

Um caso mostra como a coisa funciona. O bug do Linux, CVE-2026-98432, é um use-after-free no handshake do TCP que existe desde o Linux 4.4. O Frandroid conta que, após uma instrução inicial de um pesquisador, o modelo escreveu um exploit remoto com acesso root: 48 minutos para vazar um endereço do kernel e mais cinco para assumir o controle.

A habilidade é a manchete, mas não é a história

Modelos encontrarem bugs já não surpreende. O que muda é a economia. Uma falha que vive no kernel do Linux desde 2016 ganhou um exploit remoto com root funcional em menos de uma hora de tempo de modelo. Achamos que o recurso escasso no ataque costumava ser o tempo de pessoas qualificadas, e essa escassez está diminuindo.

A divulgação da Anthropic também mostra contenção, o que merece crédito. A empresa não publicou seu exploit, comunicou as falhas aos fabricantes primeiro e diz trabalhar com empresas de segurança externas para triar e validar as descobertas. O Frandroid observa que, até 30 de outubro, nenhuma reprodução independente havia sido relatada. Mesmo assim, cerca de quarenta repositórios do GitHub já mencionam a falha, e pelo menos sete se apresentam como provas de conceito. A contenção de um laboratório não impede que outros construam seu próprio exploit à mão ou com suas próprias ferramentas.

O patch não é a linha de chegada

Todo mundo gosta da frase de que todas já foram corrigidas. Teríamos cuidado com ela. A correção do Linux tinha quatro linhas, foi escrita em 5 de outubro e chegou aos kernels estáveis em 11 e 15 de outubro. Mas, na manhã de 2 de novembro, segundo o Frandroid, o Ubuntu ainda listava sua correção como "em andamento" para as versões 22.04 a 26.10, embora pacotes corrigidos já estivessem referenciados em sua página de acompanhamento. A Red Hat só começou a distribuir suas correções em 1º de novembro e elevou a gravidade para crítica em 30 de outubro, depois de ela e outros fabricantes terem avaliado o bug inicialmente entre 5,9 e 8,1.

Essa é a lacuna de verdade. Escrever o exploit levou menos de uma hora para um modelo, enquanto triagem, pontuação de gravidade, empacotamento e a reinicialização do seu servidor continuam em velocidade humana e burocrática. A Red Hat alertou que empresas asiáticas precisam aplicar patches mais rápido diante das ameaças de IA. Nós estenderíamos isso a todos. Se um modelo consegue comprimir a exploração, a defesa que importa é comprimir a correção e a implantação.

Quem chega primeiro decide tudo

A Anthropic não lançou esse modelo, o que é tranquilizador e, suspeitamos, também temporário. A questão é se os defensores terão ferramentas equivalentes antes dos atacantes. Aqui ficamos com um otimismo cauteloso: um laboratório que comunica falhas aos fabricantes antes de publicar faz um favor aos defensores. Mas isso só funciona se os fabricantes conseguirem absorver o volume. Uma enxurrada de relatórios críticos bem validados pode sobrecarregar uma equipe pequena de mantenedores tanto quanto um ataque.

Há também um ângulo político que vale observar com ceticismo. A Radio France observa que laboratórios de modelos fechados, como a Anthropic, pediram regulação, o que poderia favorecer seu modelo de negócios em detrimento dos abertos. Na nossa visão, a capacidade ofensiva é um argumento conveniente para essa agenda. Pode ser sincero e, ainda assim, interesseiro.

O que fazer na segunda-feira

Nossa recomendação é prática, não apocalíptica. Trate "patch disponível" como gatilho de emergência, não como um chamado para o próximo trimestre. Se você administra servidores Linux, verifique o status real do seu kernel, incluindo variantes de nuvem e HWE, e reinicie após atualizar; contêineres compartilham o kernel do host. Onde a correção ainda não chegou, as mitigações listadas pelo Frandroid (filtrar pacotes TCP com opções IPv4, desativar o MPTCP) reduzem a exposição, embora a Red Hat diga que só um kernel corrigido resolve o problema.

O veredito: não entre em pânico por causa do modelo, preocupe-se um pouco com a sua cadência de atualizações. O próximo bug crítico provavelmente chegará mais rápido que o último, e quem vencerá será quem encurtar o tempo entre a existência de uma correção e a correção em execução.