Quando seu agente encontra uma vulnerabilidade

Nicholas Carlini, cientista pesquisador da Anthropic, apontou o Claude Code para o código-fonte do kernel do Linux e pediu para ele encontrar vulnerabilidades. A configuração: um script bash de 10 linhas mais um container Docker com builds instrumentados com ASAN. Percorrer os arquivos-fonte em loop, pedir ao modelo que procure bugs, passar para o próximo arquivo.¹³

O resultado, detalhado no texto de Michael Lynch sobre a palestra:² um heap buffer overflow explorável remotamente no cache de replay do NFSv4 LOCK, presente desde março de 2003, anterior ao próprio Git. Dois clientes NFS cooperando podem ler memória sensível do kernel ao transbordar um buffer de 112 bytes com um ID de proprietário de lock de 1.024 bytes. Carlini encontrou pelo menos quatro vulnerabilidades adicionais no kernel na mesma varredura. Separadamente, a mesma metodologia produziu 122 inputs que causaram crashes enviados à Mozilla, dos quais 22 receberam CVEs.³ Ele descreveu “várias centenas de crashes” que ainda não teve tempo de validar e reportar.²

Carlini confirmou essas vulnerabilidades e as reportou aos mantenedores. Ele as encontrou com o Opus 4.6, a mesma classe de modelo que profissionais usam diariamente para revisão de código, refatoração e desenvolvimento de recursos. Carlini apresentou as descobertas na conferência de segurança de IA [un]prompted em abril de 2026.¹

Sim, agentes de IA podem encontrar vulnerabilidades de segurança reais que especialistas humanos deixaram passar por décadas. Um pesquisador da Anthropic usou Claude Code com um script bash de 10 linhas para descobrir um heap buffer overflow explorável remotamente de 23 anos no kernel do Linux e produziu 22 CVEs no Firefox a partir de 122 inputs que causaram crashes. A metodologia não exige nenhum framework customizado: iterar sobre arquivos-fonte com builds instrumentados com ASAN e solicitar ao modelo que encontre bugs.

TL;DR

A metodologia de Carlini foi mínima: iterar sobre arquivos-fonte, solicitar ao Claude que encontrasse vulnerabilidades em cada um, verificar acertos com asserções do ASAN. O Opus 4.6 encontrou substancialmente mais vulnerabilidades do que o Opus 4.1 (8 meses mais antigo) ou o Sonnet 4.5 (6 meses mais antigo), sugerindo que a capacidade cruzou recentemente um limiar.² O gargalo agora é a validação humana, não a descoberta pela IA. A mudança traz implicações diretas para como profissionais constroem hooks de segurança, executam revisão de código e pensam em auditoria assistida por agentes.

Pontos principais

• Engenheiros de segurança: A capacidade é real e está melhorando rapidamente. Se você executa revisão de código assistida por agente, seus hooks de segurança PreToolUse importam mais do que nunca. Não para bloquear o Claude, mas para controlar o que ele pode fazer com o que encontra.
• Construtores de harness: O gargalo de verificação (“várias centenas de crashes que não validei”) é um problema de harness. Triagem automatizada, deduplicação e classificação de severidade são a próxima camada de infraestrutura.
• Todos os outros: O mesmo modelo que introduz regressões de desempenho de 446x também encontra bugs que 23 anos de revisão humana deixaram passar. Ambos são verdadeiros simultaneamente.

A metodologia

A abordagem de Carlini não exigiu um framework de segurança customizado, um modelo com fine-tuning ou prompts especializados. Ele a descreveu como um “script bash de 10 linhas mais um container Docker”:³

1. Compilar o alvo com instrumentação ASAN (AddressSanitizer)
2. Iterar pelos arquivos-fonte, usando o modelo para avaliar a relevância de segurança
3. Solicitar ao Claude Code com um enquadramento de capture-the-flag para arquivos de alta relevância
4. Executar múltiplas passadas por alvo (5-20 dependendo da codebase)
5. Usar agentes de crítica automatizados para verificar descobertas antes da divulgação

O enquadramento de capture-the-flag importa. Dizer ao modelo “este código tem um bug” ativa um modo diferente de “revise este código em busca de problemas”. Desenvolvedores notam o mesmo padrão no uso diário: o Claude encontra mais problemas quando você diz que existe um problema do que quando pergunta se poderia existir um.²

A varredura custa API em tokens, não pessoas-mês. Carlini encontrou cinco vulnerabilidades confirmadas no kernel do Linux e 22 CVEs no Firefox usando um agente comum CLI.³ A mesma ferramenta que escreve seus testes unitários e formata seus imports.

O limiar de capacidade

A descoberta mais marcante é a diferença entre gerações de modelos. Carlini tentou reproduzir seus resultados com modelos mais antigos:²

• Opus 4.6 (lançado cerca de 2 meses antes da palestra): encontrou o heap overflow e múltiplas vulnerabilidades adicionais
• Opus 4.1 (8 meses antes): encontrou apenas uma pequena fração
• Sonnet 4.5 (6 meses antes): encontrou apenas uma pequena fração

Algo cruzou um limiar entre gerações de modelos. A capacidade de manter uma codebase complexa em contexto, raciocinar sobre fluxo de dados entre limites de funções e identificar discrepâncias sutis em especificações parece ter emergido em vez de melhorar gradualmente.

Carlini afirmou sem rodeios: “Nunca encontrei uma dessas na minha vida. Isso é muito, muito, muito difícil de fazer. Com esses modelos de linguagem, eu tenho um monte.”²

O paradoxo

A mesma arquitetura de agente que introduz regressões de desempenho — 118 funções com lentidões de 3x a 446x — também encontra vulnerabilidades de segurança que décadas de revisão humana especialista deixaram passar. Esses são aspectos complementares do mesmo perfil de capacidade. A pesquisa de vulnerabilidades é fundamentalmente correspondência de padrões contra classes conhecidas (buffer overflows, use-after-free, signedness de inteiros), o que é uma força do LLM.⁴ A otimização de desempenho exige o oposto: raciocinar sobre contextos específicos de execução, comportamento de cache e complexidade algorítmica. O modelo reconhece um buffer overflow em milhões de linhas de código, mas não consegue dizer que um hash map é mais lento que um array ordenado para seu padrão de acesso. Construa seu harness de acordo, com hooks de segurança que sinalizam descobertas e hooks de desempenho que medem antes de comitar.

O gargalo de verificação

A admissão mais reveladora de Carlini: “Tenho tantos bugs no kernel do Linux que não posso reportar porque ainda não os validei.”²

O gargalo agora está na triagem, não na descoberta. Encontrar vulnerabilidades potenciais custa menos do que confirmar que são reais. A inversão cria um novo problema de infraestrutura para equipes de segurança:

A descoberta é automatizada. Um agente pode varrer uma codebase em horas.

A verificação é manual. Cada vulnerabilidade potencial precisa de uma prova de conceito, uma avaliação de impacto e um processo de divulgação responsável.

A triagem é a lacuna. Classificar centenas de descobertas geradas por agentes entre vulnerabilidades reais, falsos positivos e ruído de baixa severidade é o trabalho que ainda não tem boas ferramentas.

O padrão espelha a revisão de código assistida por agente: o agente produz saída bruta mais rápido do que humanos conseguem avaliá-la. O valor vive não na geração, mas na infraestrutura que processa, filtra e encaminha a saída.

Para construtores de harness, isso significa que o próximo hook de alto valor não é um scanner de segurança. É um sistema de triagem de segurança: deduplicação, classificação de severidade, filtragem de falsos positivos e geração automática de provas de conceito. Os hooks de governança que controlam a saída do agente são mais importantes do que as próprias capacidades de escaneamento.

O que isso significa para profissionais

Se você executa Claude Code em codebases de produção, você já está executando um sistema capaz de encontrar vulnerabilidades reais. A questão não é se a capacidade existe, mas se seu harness consegue lidar com o que o agente encontra.

Três movimentos práticos:

Adicione uma varredura de segurança ao seu pipeline de revisão. Um hook PostToolUse em Write/Edit pode disparar uma varredura de segurança direcionada em arquivos alterados. O hook lê o caminho do arquivo a partir do stdin (Claude Code passa eventos JSON pelo stdin para os hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

O hook acima é um ponto de partida, não está pronto para produção. Você adicionaria deduplicação, filtragem de severidade e rate limiting. Mas o padrão central coincide com a metodologia de Carlini: um loop sobre arquivos com um prompt direcionado.³

Construa infraestrutura de triagem. Descobertas brutas de vulnerabilidades sem classificação de severidade são ruído. Se seu agente produz 50 descobertas por varredura, você precisa de deduplicação automatizada e pontuação de prioridade antes que um humano veja a lista. O gargalo é um problema de harness, não um problema de modelo.

Aceite o paradoxo. O mesmo modelo que precisa de guardrails de desempenho é genuinamente excelente em correspondência de padrões de segurança. Projete seu harness para explorar a força e compensar a fraqueza. Hooks de segurança que escaneiam. Hooks de desempenho que medem. Hooks de qualidade que verificam. Cada um cobre o que os outros deixam passar.

A vulnerabilidade de 23 anos no Linux não estava escondida. Estava à vista, em um arquivo que milhares de engenheiros haviam lido. O modelo a encontrou porque correspondência de padrões em escala é o que esses sistemas fazem. A lição não é que agentes são melhores que humanos em segurança. A lição é que agentes cobrem uma superfície diferente — e o harness que orquestra ambos é o que torna a combinação confiável.

Atualização (7 de abril de 2026): a Anthropic anunciou o Project Glasswing, um novo modelo chamado Claude Mythos que escalou a abordagem de Carlini para milhares de zero-days em todas as principais plataformas. O Mythos permanece restrito a 12 parceiros e não está disponível publicamente. O post acima cobre a pesquisa original de Carlini; a sequência cobre a produtização.

Fontes

Perguntas frequentes

Posso reproduzir a abordagem de Carlini com Claude Code?

Carlini documentou a metodologia na entrevista ao podcast.³ O loop central: compilar com ASAN, iterar sobre arquivos-fonte, solicitar ao Claude com um enquadramento de capture-the-flag, verificar acertos. Carlini relatou que o Opus 4.6 encontrou significativamente mais vulnerabilidades do que modelos mais antigos, então resultados com outras gerações de modelos podem variar.

Isso significa que agentes de IA são melhores que humanos em encontrar bugs de segurança?

Não. Significa que agentes cobrem uma superfície diferente. Agentes se destacam em correspondência de padrões contra classes conhecidas de vulnerabilidades em grandes codebases. Humanos se destacam em entender vetores de ataque inéditos, falhas de lógica de negócio e propriedades de segurança dependentes de contexto. A combinação é mais forte do que qualquer um isoladamente.

Devo me preocupar com atacantes usando essa capacidade?

Carlini alertou explicitamente sobre “uma grande onda chegando”. A mesma capacidade que ajuda defensores a encontrar vulnerabilidades está disponível para atacantes. A assimetria é que defensores podem automatizar triagem e patching, enquanto atacantes ainda precisam desenvolver exploits. Mas a lacuna de descoberta está se fechando.