Os 500 Zero-Days do Claude Opus 4.6: O que Três Patches Mostram

Em 5 de fevereiro de 2026, a Frontier Red Team da Anthropic publicou uma pesquisa relatando que o Claude Opus 4.6, lançado no mesmo dia, havia encontrado e validado mais de 500 vulnerabilidades de alta severidade em software de código aberto — sem ferramentas específicas para a tarefa, estruturas de suporte personalizadas ou prompts especializados. Três descobertas são descritas em detalhe: uma verificação ausente de limites da pilha no Ghostscript, uma série não verificada de chamadas strcat no OpenSC, e um estouro de buffer no codificador GIF CGIF que depende de como a compactação LZW se comporta quando seu dicionário é preenchido. A Anthropic afirma que as três já foram corrigidas por seus mantenedores e, segundo seu relato, os bugs foram encontrados, validados e relatados. Muitos dos projetos são mantidos por equipes pequenas ou voluntários sem equipe de segurança dedicada, observa a publicação, então o ônus de relatar e corrigir recaiu sobre eles. O próprio registro do arquivo para a descoberta, classificado com severidade informativa e sem danos reais registrados, fica no Orca AI Incident Archive, ao lado dos outros registros de políticas e divulgações de fevereiro de 2026.

O que a Anthropic realmente publicou

O post tem como título "Avaliando e mitigando o risco crescente de 0-days descobertos por LLMs" e é atribuído à Frontier Red Team: Nicholas Carlini, Keane Lucas e Evyatar Ben Asher como contribuidores em igualdade, com Newton Cheng, Hasnain Lakhani, David Forsythe e Kyla Guru. A página traz uma data de publicação de 5 de fevereiro de 2026 e uma nota de edição datada de 6 de fevereiro de 2026, registrando que a lista de autores foi atualizada. O arquivo cita o post em red.anthropic.com, que agora redireciona para anthropic.com/research/zero-days.

O método importa mais do que o número de destaque. A Anthropic diz que colocou o modelo dentro de uma máquina virtual com acesso às versões mais recentes de projetos de código aberto e lhe deu utilitários padrão e as ferramentas que um pesquisador de segurança humano usaria — depuradores e fuzzers —, mas nenhuma instrução sobre como usá-las e, nas palavras do post, “nenhum harness personalizado que lhe teria dado conhecimento especializado sobre como encontrar vulnerabilidades melhor”. O que estava sendo testado era o comportamento do modelo pronto para uso.

A equipe restringiu a busca a bugs de corrupção de memória, partindo do raciocínio de que um crash é mais fácil de confirmar do que um erro de lógica. A Anthropic deixa explícito que isso é um filtro, não uma garantia: “nem todas as entradas que fazem um programa travar são vulnerabilidades de alta gravidade”. Então os crashes voltaram ao modelo para crítica, desduplicação e repriorização, e depois foram para pessoas. “Em nossa rodada inicial de descobertas, nossos próprios pesquisadores de segurança validaram cada vulnerabilidade e escreveram patches manualmente. À medida que o volume de descobertas cresceu, trouxemos pesquisadores de segurança externos (humanos) para ajudar na validação e no desenvolvimento de patches.” A automação de patches, segundo o post, ainda estava sendo construída.

Três bugs, e os patches que se seguiram

Os três exemplos resolvidos compartilham um padrão: uma ferramenta automatizada já havia falhado, e o modelo encontrou o bug raciocinando sobre algo diferente de mutação de entrada.

• Ghostscript, o interpretador de PostScript e PDF. O fuzzing e a análise manual subsequente não revelaram nada. O modelo então leu o histórico Git do projeto, encontrou um commit descrito no post como a adição de "verificação de limites da pilha para valores de mesclagem MM" a charstrings Type 1, deduziu que o código anterior a esse commit era vulnerável e passou a procurar outros locais de chamada que não tinham recebido o mesmo tratamento. Encontrou um em gdevpsfx.c — o post cita a linha 292 — e criou um arquivo que faz o programa travar. O repositório confirma isso: o commit 87486fb801, de Chris Liddell, datado de 5 de setembro de 2025, tem o título "Type 1 charstrings: add stack bounds checking for MM blend values". Uma correção posterior de Ken Sharp, o commit 4e392a82, datado de 26 de janeiro de 2026, adiciona verificações de limites imediatamente antes dessa chamada no conversor de fontes, registrada no Bug 709080, cujo relatório tem o título “Ghostscript Incomplete fix for Type 1 MM blend stack bounds check”. Um commit de 13 de fevereiro de 2026 estendeu as verificações de limites no mesmo conversor. Nenhuma das mensagens de commit diz quem relatou o bug.

• OpenSC, um utilitário de linha de comando para dados de cartão inteligente. Aqui o modelo procurou chamadas de função arriscadas e encontrou sucessivas operações strcat gravando em um buffer filename de 4096 bytes, após um cálculo de tamanho que subtraía o comprimento de uma string de entrada, mas depois anexava mais strings sem verificar novamente. A publicação observa que os fuzzers existentes raramente chegavam a esse caminho devido às precondições envolvidas. O commit 33ab343a5c do OpenSC, de 19 de janeiro de 2026, adicionou uma verificação de que a string anexada tem exatamente 64 bytes, e o pull request #3554, mesclado em 25 de janeiro de 2026, substituiu as chamadas strcat restantes em todo o projeto por strlcat; seu autor chamou a função de "ímã para quaisquer ferramentas de análise estática e CVEs."

• CGIF, um codificador de GIF. A biblioteca presumia que os dados comprimidos seriam sempre menores que a entrada não comprimida, o que é quase sempre verdade. O modelo raciocinou que o LZW constrói um dicionário de tamanho fixo e que, quando o dicionário se enche, códigos de limpeza inseridos no fluxo podem fazer a saída "comprimida" ficar maior que a entrada — então um buffer dimensionado para N+2 códigos poderia receber mais de N+1. O post diz que até 100% de cobertura de linhas e ramificações pode não expor isso, porque é necessária uma sequência específica de operações. O pull request #84 do CGIF, mesclado em 19 de janeiro de 2026 e lançado no mesmo dia como v0.5.1, corrige exatamente isso: "Os códigos de limpeza de redefinição estavam ausentes no cálculo para o limite superior do tamanho dos dados LZW."

Essas correções foram aplicadas antes da publicação da pesquisa — CGIF e OpenSC em 19 de janeiro de 2026, OpenSC novamente em 25 de janeiro, Ghostscript em 26 de janeiro — e a Anthropic disse no post que havia "começado a reportá-las e está vendo nossos patches iniciais serem aplicados" antes de tornar isso público. Os repositórios registram as alterações de código; não registram quem enviou os relatórios, então a ligação entre as descobertas do modelo e esses commits específicos depende do relato da Anthropic e de quão de perto os defeitos descritos correspondem aos diffs.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

A parte da governança: sondagens, bloqueio e 90 dias

O que faz disto um registro de política, e não uma simples nota de pesquisa, é a segunda metade do post. Junto com o lançamento do modelo, a Anthropic diz que introduziu sondas específicas para segurança cibernética que medem ativações dentro do modelo enquanto ele gera uma resposta, e que atualizou seus fluxos de trabalho de aplicação para usar detecção baseada em sondas. Vai além da detecção: "podemos instituir intervenção em tempo real, incluindo o bloqueio de tráfego que detectarmos como malicioso." A Anthropic admite o custo — "Isso criará atrito para pesquisas legítimas e parte do trabalho defensivo" — e diz que quer trabalhar com a comunidade de pesquisa em segurança nisso. Nenhuma taxa de detecção, taxa de erro ou processo de recurso é publicada.

A publicação também argumenta que o próprio calendário de divulgação agora é um problema. “Janelas de 90 dias, padrão do setor, podem não resistir à velocidade e ao volume de bugs descobertos por LLM”, afirma, e adverte que os modelos “podem logo superar a velocidade e a escala até mesmo de pesquisadores humanos especialistas”. Trata-se de um fornecedor argumentando que a norma pela qual será avaliado precisa ser substituída, e é a parte do registro com o alcance mais longo.

O que mudou depois

Em 20 de fevereiro de 2026, a Anthropic abriu o Claude Code Security como uma prévia de pesquisa limitada para clientes Enterprise e Team, com acesso acelerado gratuito para mantenedores de código aberto — a capacidade foi transformada em produto quinze dias após a pesquisa. O VentureBeat noticiou o lançamento e afirmou ter solicitado à Anthropic a taxa de falsos positivos antes e depois da autoverificação, o número de vulnerabilidades divulgadas com patches implementados versus ainda em triagem, e as salvaguardas que distinguem o uso por atacantes do uso por defensores; informou que o pesquisador principal do projeto estava indisponível e que a empresa se recusou a compartilhar mecanismos específicos de detecção de atacantes.

Os patches continuaram se movendo também, e nem sempre em uma única direção. A correção do CGIF para a alocação que a Anthropic descreveu foi lançada na v0.5.1 em 19 de janeiro de 2026; em 21 de fevereiro de 2026, o pull request #103 corrigiu um estouro de inteiro de 32 bits introduzido por esse mesmo cálculo de alocação, lançado como v0.5.2 no dia seguinte para GIFs no máximo de 65.535 por 65.535 pixels. Consertar um cálculo de limites, ao que parece, é uma pequena fonte própria de bugs de limites.

Lendo o número corretamente

A própria frase da Anthropic é “mais de 500 vulnerabilidades de alta gravidade”. A Axios, à qual a empresa forneceu as informações em primeira mão, descreveu-as no dia da publicação como “mais de 500 vulnerabilidades zero-day anteriormente desconhecidas”, cada uma validada por um membro da equipe da Anthropic ou por um pesquisador de segurança externo. Ambas as descrições apontam para o mesmo conjunto, mas apenas uma é a formulação do fornecedor, e nenhuma delas é acompanhada por uma lista, um mapeamento CVE ou uma distribuição de gravidade. A contagem é da Anthropic, as classificações de gravidade são da Anthropic, e os três projetos abordados no artigo são os únicos que o público pode verificar.

A análise independente que se seguiu, em grande parte, aceitou o número pelo valor de face e discutiu o que ele significa. Mitch Ashley, do Futurum Group, escreveu em 24 de fevereiro de 2026 que o resultado "importa mais pelo que o método revela do que pela contagem" e que a verdadeira restrição está a jusante: "Expor mais vulnerabilidades mais rapidamente não reduz a superfície de ataque. Isso cria uma fila maior diante de um processo a jusante que não consegue absorver o volume." Trata-se de uma crítica ao fluxo de divulgação, e não à constatação, e ela chega ao mesmo ponto que a Anthropic levantou sobre janelas de 90 dias.

O que o registro não estabelece

O arquivo classifica este registro com confiança A, severidade info, sem nenhum dano real registrado e sem sinalização de disputa. Essa classificação diz respeito a quão bem o evento está documentado, não a quão bem a alegação subjacente foi auditada, e vale a pena manter essa distinção. Ninguém fora da Anthropic verificou os 500. Nenhuma taxa de falsos positivos foi publicada. Os patches dos três projetos nomeados são reais e datáveis, e são a corroboração mais forte disponível — mas corroboram três exemplos, não o total.

O que resta, então, é um anúncio bem documentado, com um núcleo verificável e um restante não verificável: um fornecedor que relata uma capacidade, três diffs upstream que correspondem à sua descrição dos bugs e uma intenção declarada de coibir o uso indevido dessa capacidade na camada do modelo. O arquivo o classifica como política, que é a prateleira certa. A alegação sobre a capacidade será resolvida por quem publicar o quarto patch.