Claude Code encontrou uma vulnerabilidade no Linux que ficou escondida por 23 anos

• Claude Code, da Anthropic, detectou automaticamente uma vulnerabilidade explorável remotamente no kernel Linux, encontrando um heap buffer overflow no driver NFS que passou despercebido por 23 anos
• Apenas com o prompt “onde está a vulnerabilidade de segurança?”, ele analisou todo o kernel e identificou a falha quase sem supervisão
• O bug teve origem em um projeto de buffer fixo de 112 bytes no código do kernel de 2003 e surgiu depois que a operação LOCK foi adicionada sem limite para o comprimento do owner ID
• Além disso, Carlini encontrou centenas de potenciais vulnerabilidades no kernel, mas a maioria ainda não foi reportada por causa do gargalo de validação humana
• O modelo mais recente, Claude Opus 4.6, demonstrou capacidade de detecção muito superior às versões anteriores, sendo visto como um ponto de inflexão para a pesquisa de segurança baseada em IA

---

Claude Code encontrou uma vulnerabilidade no Linux que ficou escondida por 23 anos

• Nicholas Carlini, pesquisador da Anthropic, encontrou várias vulnerabilidades exploráveis remotamente no kernel Linux usando o Claude Code
  • Uma delas foi uma vulnerabilidade de buffer overflow no driver NFS (Network File System) que passou despercebida por 23 anos
  • Carlini afirmou que “nunca havia encontrado pessoalmente esse tipo de vulnerabilidade”, expressando surpresa com o desempenho do Claude Code

• Como o Claude Code detecta vulnerabilidades

  • O Claude Code detectou vulnerabilidades de segurança no kernel Linux quase sem supervisão
    • Carlini simplesmente deu o prompt “onde está a vulnerabilidade de segurança?” e configurou a ferramenta para percorrer todos os arquivos-fonte do kernel
  • O script usado foi configurado para que, em cada arquivo, o Claude Code assumisse um cenário de CTF (competição de hacking) e registrasse a vulnerabilidade mais grave em /out/report.txt
    • Com o comando find, ele percorreu todos os arquivos e executou repetidamente o Claude Code para buscar vulnerabilidades em cada um deles
  • O processo foi projetado para evitar relatórios duplicados da mesma falha, analisando individualmente todos os arquivos do kernel

• Vulnerabilidade no NFS (Network File System)

  • A principal vulnerabilidade encontrada pelo Claude Code foi um heap buffer overflow no driver NFS do Linux, que permite a um invasor ler a memória do kernel pela rede
  • O cenário de ataque envolve dois clientes NFS cooperando entre si (Cliente A e Cliente B) contra um único servidor NFS
    • O Cliente A solicita e obtém aprovação para um bloqueio de arquivo usando um owner ID longo de 1024 bytes
    • Depois, quando o Cliente B solicita um bloqueio para o mesmo arquivo, o servidor o rejeita e gera uma mensagem de resposta
  • O problema é que esse buffer da resposta de rejeição tem apenas 112 bytes, enquanto a mensagem real chega a 1056 bytes no total ao incluir o owner ID
    • Como resultado, o kernel grava 1056 bytes em um buffer de 112 bytes, sobrescrevendo a memória do kernel com dados controlados pelo invasor
  • Ao reportar essa vulnerabilidade, o Claude Code incluiu automaticamente até mesmo um diagrama de protocolo em ASCII

• Por que ela não foi descoberta por 23 anos

  • O bug se originou em um código introduzido no kernel Linux em março de 2003
    • Na época, a mensagem de commit afirmava que o buffer fixo de 112 bytes chamado NFSD4_REPLAY_ISIZE era suficiente para operações NFSv4 como OPEN e CLOSE
    • Depois, quando a operação LOCK foi adicionada, a limitação de comprimento do owner ID não foi considerada, o que levou à vulnerabilidade
  • Esse código é anterior à adoção do Git (2005) e faz parte de uma base antiga a ponto de hoje nem sequer ser possível criar um link direto para ela

• Centenas de vulnerabilidades adicionais ainda não reportadas

  • Carlini encontrou ainda centenas de potenciais vulnerabilidades no kernel Linux, mas a maioria ainda não foi reportada devido ao gargalo no processo de validação humana
    • Ele comentou: “Como não posso enviar resultados não verificados aos mantenedores do kernel, ainda há centenas de crashes que não consegui confirmar”
  • Até o momento, as vulnerabilidades que Carlini confirmou pessoalmente, corrigiu ou reportou somam 5 casos
    • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
    • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
    • futex: Require sys_futex_requeue() to have identical flags
    • ksmbd: fix share_conf UAF in tree_conn disconnect
    • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

• Avanços na detecção de vulnerabilidades com IA

  • Carlini encontrou essa vulnerabilidade usando o Claude Opus 4.6 (lançado 2 meses antes)
    • Com versões anteriores, como Opus 4.1 (8 meses antes) e Sonnet 4.5 (6 meses antes), ele não conseguiu reproduzir o mesmo resultado
    • O modelo mais recente conseguiu detectar muito mais vulnerabilidades
  • Segundo ele, “nos próximos meses, à medida que pesquisadores e atacantes reconhecerem o poder desses modelos de IA, virá uma onda de descoberta de vulnerabilidades de segurança em grande escala”

• Apresentação e outras informações

  • O conteúdo foi apresentado na [un]prompted AI security conference 2026
  • O caso descoberto pelo Claude Code é visto como um exemplo de como a IA pode aumentar dramaticamente a produtividade da pesquisa real em segurança

[m3op0w94]

Lado esperançoso: descoberta de uma vulnerabilidade no Linux
Lado desesperador: descontinuação do bounding no curl

[GN⁺]

Comentários do Hacker News

• Não é surpreendente. O ponto que não foi mencionado no artigo, porém, é que o Claude Code também encontrou 1.000 bugs falso-positivos, e os desenvolvedores levaram 3 meses para filtrá-los

  • Hoje em dia não funciona mais assim. O próprio LLM filtra bugs que não podem ser reproduzidos em um pipeline secundário. Confirmar se é uma vulnerabilidade realmente acionável é muito mais fácil do que encontrá-la, então quase só sobram bugs reais, com precisão perto de 100%. Ainda há muita gente que nega o avanço dos LLMs, mas é difícil negar sua utilidade
  • Queria saber a fonte disso. Nunca vi nada nesse sentido. Pela minha experiência, a taxa de falso-positivo na detecção de vulnerabilidades do Claude Opus 4.6 ficou abaixo de 20%
  • Ferramentas de análise estática/dinâmica também sempre encontram vulnerabilidades. A maioria dos grandes projetos já tem um backlog de issues despejado por scanners. O problema é separar o que de fato é perigoso. É interessante que o Claude tenha encontrado um bug antigo, mas isso sempre acontece quando aparece um scanner novo
  • O artigo não diz que há muitos falso-positivos. Pelo contrário, menciona que “ainda há bugs demais que não conseguimos validar”
  • A lição não é que o Claude Code é inútil, e sim que, nas mãos certas, ele pode ser uma ferramenta poderosa

• Colar um monte de código novo de uma vez e perguntar ao Claude “o que deixei passar? onde está o bug?” é uma abordagem muito convincente para desenvolvedores que estão começando a usar IA. Ele encontra rápido especialmente bugs de threading e de sistemas distribuídos. A essa altura, imagino que códigos de criptomoedas estejam sendo analisados em massa

  • Eu gosto de enviesar o prompt para que o Claude assuma que existe um bug. Pergunto algo como “há um bug neste código. Você consegue encontrá-lo?” ou acrescento “o bug não é óbvio”, e isso aumentou minha taxa de sucesso
  • Eu também uso o CC/codex quase exatamente assim
  • Uso perguntando algo como “Foi o Codex que escreveu esse código; tem algo estranho aqui?”

• Em vez de um bug “escondido”, seria mais correto dizer que “ninguém olhou”. A estrutura do código escrevia 1056 bytes em um buffer de 112 bytes. É o tipo de problema que um analisador estático também pegaria facilmente, mas se você mandar um LLM “verificar todos os buffers de tamanho fixo”, ele também pode misturar alucinações no resultado. Ainda assim, é um bom ponto de partida

  • A maioria das vulnerabilidades permanece porque “ninguém olhou”. A complexidade dos sistemas vai se acumulando e fica difícil para humanos acompanharem. Se isso puder ser resolvido, é uma grande notícia. Analisadores estáticos reportam todos os caminhos possíveis de cópia de buffer, mas muitas vezes a entrada real é limitada, então isso não se encaixa tão bem no kernel Linux
  • Na verdade, o fato de “ninguém olhou” se deve à falta de mão de obra. Havia poucas pessoas e pouco tempo para encontrar vulnerabilidades em open source. Mas agora os modelos ficaram capazes o suficiente, e esse limite está sendo rompido. Acho que este ano vai ser muito interessante
  • Dizem que um analisador estático poderia encontrar isso facilmente, mas na prática ninguém encontrou por mais de 20 anos. É engraçado como, sempre que um LLM faz algo legal, a reação é “isso não é nada demais”

• Curiosamente, 3 ou 4 dos 5 bugs encontrados provavelmente teriam sido mitigados pelos patches do linux-hardened, por exemplo desativando io_uring, forçando crash do kernel em caso de UAF e impedindo a exploração de heap overflow

• É engraçado esse tipo de anúncio: “estamos divulgando uma arma perigosa, então ajudem a tornar o mundo mais seguro. Só que pagando assinatura”. Parece um bioquímico soltando uma bomba química e dizendo “se quiser impedir isso, pague”. A indústria de software hoje em dia é realmente irônica

  • Isso não faz sentido. Comparar encontrar e reportar vulnerabilidades com disseminar armas bioquímicas é um exagero total

• Reproduzi o experimento em várias bases de código de produção, e havia muitos duplicados, falso-positivos e bugs não exploráveis. Mesmo assim, também havia várias vulnerabilidades críticas (crit) de verdade

• Durante o Q&A da apresentação, fiquei curioso com o vídeo reproduzido ao fundo. Era uma demo de exploit usando um bug de NFS por rede USB?

• É um trabalho relacionado ao nosso laboratório de segurança. Só neste ano encontramos 23 vulnerabilidades com agentes de segurança de IA

  • Relatório do Security Lab
  • Guia de execução do Taskflow

• Parece que o estoque de 0-days das agências de três letras vai encolher rapidamente

• Em vez de esperar mais relatórios de vulnerabilidade, é melhor esperar mais tentativas de ataque daqui para frente