Um Pesquisador, Uma IA e Um Bug de 23 Anos

Em março de 2003, alguém commitou um código no kernel Linux que implementava o protocolo NFSv4. O código funcionava. Passava nos testes. Foi revisado por outros desenvolvedores. E ficou lá por 23 anos, rodando em milhões de servidores ao redor do mundo.

Até que Nicholas Carlini, pesquisador de segurança da Anthropic, abriu um terminal, apontou o Claude Code para o código-fonte do kernel e perguntou: “onde estão as vulnerabilidades de segurança?”.

A resposta mudou tudo o que a gente achava saber sobre caça a bugs.

O Que Aconteceu na Conferência [un]prompted

Na conferência [un]prompted de 2026, em San Francisco, Carlini subiu ao palco e fez algo que ninguém esperava: uma demonstração ao vivo de caça a vulnerabilidades com IA. Ele apontou o Claude para o Ghost — uma plataforma de publicação com 50.000 estrelas no GitHub que nunca tinha tido uma vulnerabilidade crítica na sua história — e em 90 minutos, a IA encontrou uma blind SQL injection.

Mas o Ghost foi só o aquecimento.

O que realmente chocou a audiência foram os resultados com o kernel Linux. Carlini revelou que vinha usando o Claude Opus 4.6 para varrer o código-fonte do kernel há semanas, e os resultados eram… perturbadores.

“Eu nunca encontrei uma vulnerabilidade no kernel Linux na minha vida”, disse Carlini no palco. “Isso é muito, muito difícil de fazer. Com esses modelos de linguagem, eu encontrei um monte.”

A Vulnerabilidade NFS: 23 Anos Escondida

O bug mais impressionante estava no driver NFS (Network File System) do Linux. Pra quem não conhece, o NFS é o protocolo que permite compartilhar arquivos entre máquinas numa rede — coisa que praticamente todo servidor Linux corporativo usa.

A falha é um heap buffer overflow no cache de replay de LOCK do NFSv4.0. Em termos simples, é quando o programa escreve mais dados do que o espaço reservado na memória permite. O resultado? Um atacante pode sobrescrever partes críticas da memória do kernel.

Como o ataque funciona

O cenário de exploração exige dois clientes NFS cooperando contra um servidor Linux:

1. Cliente A estabelece uma conexão e solicita o lock de um arquivo com um identificador de 1024 bytes
2. Cliente B abre uma conexão separada e tenta acessar o mesmo arquivo lockado
3. Quando o servidor nega o pedido do Cliente B, ele gera uma mensagem de negação que inclui os dados do owner
4. O servidor escreve 1056 bytes em um buffer de 112 bytes — sobrescrevendo memória do kernel

Esse é o tipo de bug que permite a um atacante ler memória sensível do kernel pela rede. E ele existia desde março de 2003, quando a implementação do NFSv4 foi adicionada ao kernel.

Pense nisso: 23 anos. Milhares de revisões de código. Ferramentas de análise estática. Fuzzing automatizado por milhões de horas. E ninguém viu.

5 Vulnerabilidades no Kernel, Uma Atrás da Outra

O bug do NFS não foi um achado isolado. Carlini documentou publicamente cinco vulnerabilidades confirmadas no kernel Linux, todas encontradas pelo Claude:

O ksmbd — a implementação do SMB no kernel — aparece duas vezes na lista. Faz sentido: é um componente relativamente novo e que implementa um protocolo complexo (SMB/CIFS). Exatamente o tipo de código onde bugs se escondem.

E tem mais: Carlini disse que tem centenas de bugs potenciais adicionais que ainda não conseguiu validar. O gargalo não é a IA encontrando falhas — é o humano verificando se elas são reais.

O FreeBSD Também Não Escapou

Se você achou que o kernel Linux era o único alvo, pense de novo.

A equipe do Calif.io publicou um case ainda mais assustador: o Claude não só encontrou uma vulnerabilidade no FreeBSD como escreveu um exploit funcional completo em 4 horas. Estamos falando de uma execução remota de código no kernel (RCE) que dropa um root shell.

A vulnerabilidade (CVE-2026-4747) está no módulo kgssapi.ko do FreeBSD, que implementa autenticação RPCSEC_GSS para NFS. É um stack buffer overflow clássico: a função svc_rpc_gss_validate() copia um corpo de credencial controlado pelo atacante em um buffer de 128 bytes na stack sem verificar o tamanho — permitindo 304 bytes de overflow.

O que impressiona no exploit

O Claude escreveu dois exploits diferentes, e ambos funcionaram na primeira tentativa.

A primeira estratégia usou 15 rounds: primeiro torna a memória do kernel executável, depois escreve shellcode 32 bytes por vez ao longo de 14 pacotes de rede. A segunda estratégia foi mais elegante — em vez de um reverse shell, escreve uma chave pública no .ssh/authorized_keys, reduzindo o exploit para apenas 6 rounds.

Detalhes que mostram o nível de raciocínio da IA:

• O Claude sabia que a VM precisava de 2+ CPUs porque o FreeBSD spawna 8 threads NFS por CPU, e o exploit mata uma thread por round
• Quando encontrou um bug com hardware breakpoints, o Claude diagnosticou que registradores de debug herdados do DDB estavam causando exceções em processos filhos e corrigiu limpando o DR7 antes do fork

Isso não é pattern matching. É raciocínio de segurança de nível profissional.

Claude Code Security: 500+ Zero-Days e Contando

Em fevereiro de 2026, a Anthropic lançou o Claude Code Security como preview de pesquisa. A ferramenta escaneou codebases open-source em produção e encontrou mais de 500 vulnerabilidades de alta severidade que sobreviveram a décadas de revisão humana e milhões de horas de fuzzing.

O que diferencia essa abordagem de ferramentas tradicionais de análise estática?

A diferença fundamental é que o Claude raciocina sobre o código como um pesquisador de segurança humano faria:

• Entende como componentes interagem entre si
• Rastreia fluxos de dados pela aplicação inteira
• Identifica vulnerabilidades que ferramentas baseadas em regras simplesmente não conseguem ver
• Compreende protocolos complexos (como NFS) e suas implicações de segurança

Ferramentas como o Semgrep ou o CodeQL são excelentes para padrões conhecidos. Mas o bug do NFS não era um padrão conhecido — era uma interação sutil entre o tamanho de um campo, a lógica de replay cache e a forma como o servidor serializa respostas de negação. Nenhuma regra estática pegaria isso.

Opus 4.6: O Salto de Capacidade

Um detalhe técnico importante que Carlini mencionou: todos esses resultados foram obtidos com o Claude Opus 4.6, lançado menos de dois meses antes da conferência.

Quando ele tentou reproduzir os mesmos resultados com modelos anteriores — Opus 4.1 e Sonnet 4.5 — eles encontraram apenas uma fração mínima do que o Opus 4.6 descobriu.

Isso levanta uma questão provocativa: se a diferença entre duas gerações de modelo foi tão drástica, o que a próxima geração vai encontrar?

Eu já vi essa dinâmica antes em outras áreas de IA. A cada salto de capacidade, o que parecia impossível vira trivial. Geração de código era medíocre com GPT-3 e virou impressionante com GPT-4. Raciocínio matemático era fraco e melhorou dramaticamente. Agora estamos vendo o mesmo padrão em segurança ofensiva.

A Metodologia: Mais Simples Do Que Você Imagina

Talvez a parte mais surpreendente de tudo isso seja o quão simples é a abordagem de Carlini. Ele não criou um framework elaborado de 15 etapas. Não treinou um modelo especializado. Não fez fine-tuning.

O que ele fez:

# Pseudo-código da abordagem de Carlini
for file in $(find kernel/nfs -name "*.c"); do
  claude-code "Analise este arquivo como se fosse um
  desafio de CTF. Encontre vulnerabilidades de segurança
  exploráveis remotamente." < "$file"
done

O script itera pelos arquivos fonte e pede ao Claude para localizar bugs, enquadrando a tarefa como um desafio de CTF (Capture The Flag). Essa técnica de gamificação ajuda o modelo a focar em diferentes arquivos sistematicamente e evita achados redundantes.

Simples, direto e devastadoramente eficaz.

O Elefante na Sala: E Se Os Atacantes Usarem Isso?

Vamos falar do que todo mundo está pensando.

Se um pesquisador da Anthropic consegue encontrar centenas de zero-days no kernel Linux com uma ferramenta disponível comercialmente… o que impede um grupo de hackers maliciosos de fazer a mesma coisa?

A resposta curta: nada.

A Anthropic reconhece isso abertamente. Na página do Claude Code Security, eles admitem que “o mesmo raciocínio que ajuda o Claude a encontrar e corrigir uma vulnerabilidade poderia ajudar um atacante a explorá-la.”

Mas a situação é mais nuançada do que parece. Existem alguns fatores que equilibram (um pouco) a balança:

A favor da defesa:

• Defensores podem escanear todo o código. Atacantes geralmente focam em superfícies de ataque específicas
• A Anthropic está trabalhando com mantenedores de projetos open-source para corrigir vulnerabilidades antes da divulgação pública
• Organizações podem rodar o Claude Code Security continuamente no CI/CD

A favor do ataque:

• Atacantes precisam de uma vulnerabilidade. Defensores precisam corrigir todas
• O custo de encontrar bugs caiu drasticamente — de semanas/meses para minutos/horas
• Modelos open-source com menos guardrails também vão melhorar nessa capacidade

Na prática, estamos entrando numa corrida armamentista de IA em segurança cibernética. E o resultado vai depender de quem se adaptar mais rápido.

Números Que Assustam

Pra colocar em perspectiva:

Esses números não são de um paper teórico. São de demonstrações ao vivo e de vulnerabilidades confirmadas com CVEs atribuídos.

O Que Muda Pro Desenvolvedor

Se você trabalha com software — especialmente software que lida com rede, protocolos ou kernel — a mensagem é clara: as regras mudaram.

Código que “sempre funcionou” não é mais sinônimo de código seguro. Aquele driver NFS passou por 23 anos de revisões humanas, auditorias e fuzzing. E mesmo assim tinha um heap buffer overflow explorável remotamente.

Algumas implicações práticas:

1. Revisão de código com IA vai virar padrão. Não como substituto da revisão humana, mas como complemento obrigatório. Se você não está rodando análise com LLMs no seu código sensível, está ficando pra trás.

1. Projetos open-source críticos precisam de mais recursos. O OpenSSL, o kernel Linux, o FreeBSD — esses projetos sustentam a infraestrutura da internet. E como vimos, eles têm vulnerabilidades que humanos simplesmente não encontram.

1. O custo de um zero-day despencou. O que antes exigia um time especializado trabalhando por meses agora pode ser feito por uma pessoa com acesso a um LLM em horas. Isso muda fundamentalmente a economia de segurança ofensiva.

1. Fuzzing sozinho não basta. O bug do NFS existiu por 23 anos. Ferramentas de fuzzing rodaram contra o kernel milhões de vezes. LLMs encontram uma classe diferente de bugs — aqueles que exigem entendimento semântico do código e do protocolo.

O Que Vem Pela Frente

Nicholas Carlini disse que tem “tantos bugs no kernel Linux que não consegue reportar porque ainda não validou todos”. O gargalo agora é humano, não computacional.

A Anthropic já está oferecendo acesso acelerado ao Claude Code Security para mantenedores de repositórios open-source. E outras empresas de IA certamente vão seguir o mesmo caminho — o Google já tem iniciativas semelhantes com o Gemini para análise de segurança.

Minha aposta? Em menos de dois anos, toda empresa séria de software vai ter alguma forma de análise de vulnerabilidades com IA rodando no pipeline de CI/CD. Não porque querem, mas porque não fazer isso vai ser considerado negligência.

A IA não vai substituir pesquisadores de segurança humanos. Mas pesquisadores de segurança que usam IA vão substituir os que não usam. E depois do que Carlini mostrou na [un]prompted, essa transição já começou.

Fonte de inspiração: Claude Code Found a Linux Vulnerability Hidden for 23 Years — Michael Lynch

👉 Leia também:
• Vibe Coding Gerou 69 Vulnerabilidades em 15 Apps — E Ninguém Revisou o Código
• 5 Comandos Git que Ninguém Te Ensinou (Mas Deveria)

👉 Leia também: Claude Mythos: A IA Perigosa Demais Para Ser Lançada ao Público