Anthropic afirma que Claude identificou cinco cadeias de exploração e vulnerabilidades críticas

Cinco investigações, não uma auditoria independente

A Anthropic publicou um relato sobre o uso de um modelo interno de pesquisa, ainda não lançado, para procurar vulnerabilidades em softwares amplamente utilizados. A empresa apresenta cinco cadeias de exploração: uma no Chrome, outra no Safari, um bypass da tela de bloqueio do Android, uma negação remota de serviço no Windows e execução remota de comandos no Linux. São afirmações da Anthropic sobre seu próprio trabalho, não resultados verificados de forma independente na documentação disponível.

O relato traz detalhes técnicos e afirma que as vulnerabilidades foram comunicadas aos respectivos fornecedores. A Anthropic diz que as falhas descritas foram corrigidas, mas o nível de detalhe publicado varia entre os cinco casos e não permite tratar cada cadeia como uma prova reproduzida por terceiros. Além disso, o modelo usado era interno e não havia sido lançado: os resultados não demonstram que qualquer pessoa consiga obter as mesmas capacidades com um modelo disponível ao público.

A distinção importante está entre encontrar uma falha, construir uma prova de conceito e demonstrar um impacto em uma configuração específica. O documento oferece exemplos dessas três etapas, mas a descrição da Anthropic não equivale a uma avaliação externa da taxa de sucesso, dos recursos necessários ou da possibilidade de aplicar o método a outros produtos. Tampouco basta para atribuir apenas ao modelo todo o trabalho de análise, seleção e verificação que faz parte de uma investigação de segurança.

Chrome e Safari: cadeias que combinam várias falhas

No Chrome, a Anthropic descreve uma cadeia que começava com uma falha de corrupção de memória no V8, o mecanismo de JavaScript. De acordo com o relato, a exploração avançava por outros defeitos para ultrapassar limites de memória e as proteções de isolamento do navegador, até chegar à execução de código fora do sandbox. A demonstração mencionada pela empresa abria o aplicativo Calculadora em uma instalação do Chrome com configuração padrão no macOS. Esse exemplo ilustra o impacto alegado em uma configuração específica; não demonstra que todas as instalações ou versões eram vulneráveis.

A publicação afirma que o Google atribuiu 62 identificadores CVE aos achados e que, até a data do relato, as falhas haviam sido corrigidas no Chrome 156. A Anthropic descreve todas como de gravidade crítica ou alta. A empresa também atribui a esse conjunto 13 escapes do sandbox e 21 vulnerabilidades que poderiam ter sido usadas para comprometer o processo renderer. Esses números se referem à contagem informada pela Anthropic e não devem ser interpretados como 62 cadeias completas e independentes de exploração.

Para o Safari, o relato descreve um ataque diferente: o objetivo era contornar a política de mesma origem, que normalmente impede uma página de ler dados de outros sites. A Anthropic relata uma combinação de uso após liberação no JavaScriptCore, acesso de leitura e escrita fora de uma área protegida e uma vulnerabilidade no mecanismo IPC do sandbox. A cadeia teria permitido acessar dados locais do navegador e alterar um sinal de segurança para desativar a política de mesma origem. A empresa esclarece que não dependia da execução arbitrária de código: combinava acesso à memória com mudanças de estado.

O caso mostra por que uma falha isolada nem sempre explica todo o risco. Algumas condições descritas seriam comportamentos previstos que, em combinação com outras fragilidades, contribuíram para o ataque. A Anthropic afirma que a Apple reconheceu o relato e implementou uma correção disponibilizada aos usuários. O artigo não apresenta uma avaliação externa que permita medir quantos usuários estiveram expostos ou qual foi a extensão de uma eventual exploração real.

Android, Windows e Linux: três alvos e três tipos de impacto

No Android, a Anthropic descreve um bypass que teria permitido extrair fotos e outras informações pessoais de um telefone Pixel 9 bloqueado. A investigação combinou análise de partes de código aberto, engenharia reversa de componentes do Google Play e testes em um aparelho físico. A cadeia relatada contornava várias proteções: a transferência por USB, a autorização de emparelhamento, a verificação de um código e um controle sobre o envio de arquivos. Segundo a publicação, o Google corrigiu o problema. O relato não oferece, no trecho disponível, uma lista completa das versões afetadas ou dos dispositivos expostos.

No Windows, o achado foi uma leitura fora dos limites na implementação do protocolo QUIC do kernel. A Anthropic afirma que um atacante remoto poderia enviar alguns pacotes a um servidor que respondesse a solicitações HTTP/3 e provocar seu travamento e reinicialização. A empresa diz que a Microsoft corrigiu a falha e atribuiu a ela o identificador CVE-2026-33096. O trabalho descrito se baseou na análise de um executável e em ferramentas de engenharia reversa; o impacto apontado é negação de serviço, não controle remoto do sistema.

No Linux, a Anthropic relata uma vulnerabilidade de uso após liberação causada por uma condição de corrida na pilha de rede do kernel, em sistemas com um listener MPTCP. A cadeia alegada tinha duas etapas: revelar um endereço do kernel e, depois, alterar o fluxo de controle para executar um comando com privilégios de administrador. A empresa afirma que a vulnerabilidade recebeu o identificador CVE-2026-98432, foi corrigida no projeto e incorporada às ramificações estáveis mantidas. A Anthropic estima que sua prova de conceito levava cerca de 48 minutos para revelar um endereço do kernel e mais cinco minutos para chegar à execução de comandos; esses tempos descrevem aquela demonstração, não garantem um desempenho geral.

Os três exemplos não são equivalentes: o caso do Windows é uma interrupção remota do serviço, enquanto os exemplos do Chrome e do Linux descrevem execução de código ou comandos nas condições detalhadas. O Android trata do acesso a dados sem desbloquear o dispositivo. Para avaliar o risco, é preciso considerar o produto, a versão, a configuração e as correções instaladas, não apenas a classificação de gravidade.

O método: muitos scanners e verificação posterior

A Anthropic atribui parte dos resultados a uma plataforma que executa vários agentes de análise em paralelo. A empresa diz que mede a contribuição de cada scanner e acompanha a cobertura do código. As estratégias descritas incluem procurar falhas função por função, perseguir objetivos específicos — como a exposição de dados — e verificar se um aplicativo viola o modelo de ameaças documentado.

O relato também menciona a análise automatizada de variantes: depois que um achado é confirmado, procuram-se casos semelhantes. A Anthropic afirma que os resultados passam por um processo padronizado de verificação e classificação de risco. Isso importa porque gerar uma hipótese de falha não basta para estabelecer que ela seja reproduzível ou explorável. No entanto, a publicação não detalha completamente os critérios de aceitação, a quantidade de falsos positivos ou uma comparação controlada com equipes humanas e ferramentas alternativas.

Como recomendação para desenvolvedores, a Anthropic propõe incorporar a análise de segurança durante a revisão de alterações no código, além de corrigir vulnerabilidades já conhecidas. A lógica é preventiva: examinar novas mudanças pode ajudar a encontrar defeitos antes que sejam incorporados. Mas uma recomendação ou uma análise automatizada não garante que todas as falhas serão detectadas, nem que o software resultante estará livre de vulnerabilidades. A eficácia dependerá do escopo da análise, do contexto disponível, da revisão humana e da resposta da equipe.

A publicação também destaca a ampliação dos recursos computacionais durante os testes e a diversidade de scanners. Segundo a empresa, essas escolhas de configuração e metodologia aumentaram o número de vulnerabilidades encontradas em seu processo. Isso não significa que mais recursos sempre produzam resultados melhores, nem que um modelo gere achados corretos sem revisão. A própria ênfase na verificação mostra que detectar e confirmar são etapas distintas.

O que muda para os defensores e o que o relato não demonstra

O resultado mais relevante para as equipes de segurança é que, segundo a Anthropic, um modelo conseguiu combinar vários defeitos em produtos complexos e construir provas de conceito com diferentes tipos de impacto. A investigação automatizada pode ampliar a capacidade de examinar código e acelerar a análise de variantes. A mesma capacidade também pode ser usada para fins ofensivos, por isso os achados reforçam a importância de gerenciar correções, limitar a exposição e realizar testes autorizados.

A Anthropic sustenta que habilidades antes concentradas em equipes especializadas podem ficar ao alcance de modelos com pouca intervenção humana. Essa é uma interpretação da empresa baseada em seus experimentos; o relato não apresenta uma comparação independente que quantifique quanto trabalho humano foi necessário nem quanto o processo foi mais rápido do que métodos habituais. Tampouco permite concluir que um atacante sem experiência consiga reproduzir facilmente as cinco cadeias.

O documento identifica o modelo como um sistema interno de pesquisa ainda não lançado. Portanto, não é correto transferir automaticamente esses resultados para versões públicas do Claude nem presumir que uma interface acessível ao público reproduza o mesmo comportamento. O acesso a ferramentas, o tempo de computação, as informações iniciais, os limites de segurança e a supervisão humana podem alterar substancialmente o resultado.

Essa cautela é especialmente importante ao comparar a publicação com outros incidentes de segurança. O relato da Anthropic sobre vulnerabilidades em produtos de terceiros não confirma que uma empresa externa tenha invadido os sistemas internos da Anthropic, nem apresenta dados sobre um suposto ataque da Cathedral. São assuntos distintos. Com as informações disponíveis aqui, não há base suficiente para afirmar quem teria acessado quais sistemas, quanto tempo teria levado ou quais dados teria obtido.

Para organizações que administram software, a conclusão prática não é confiar que um modelo encontre todas as falhas. É importante manter um inventário de ativos, instalar atualizações, revisar componentes expostos e validar os achados em um ambiente autorizado. As equipes podem usar ferramentas automatizadas como apoio, mas devem manter controles de acesso, revisão humana e procedimentos de divulgação coordenada. O relato oferece exemplos concretos de riscos e correções comunicadas; não é uma garantia de segurança nem uma demonstração universal de capacidade.

Como interpretar o valor operacional desses achados

Os detalhes técnicos são importantes porque permitem distinguir tipos de impacto e entender como as falhas podem se reforçar. Em uma análise defensiva, uma cadeia pode ser mais relevante do que um defeito isolado quando combina uma vulnerabilidade de memória com um caminho para ultrapassar um limite de segurança. Ainda assim, a prioridade de resposta deve se basear na exposição real, nas versões implantadas, na disponibilidade de correções e nas possibilidades de mitigação, não apenas em uma demonstração chamativa.

As equipes podem usar os achados publicados para verificar inventários e atualizações dos produtos afetados, sem tentar reproduzir uma cadeia contra sistemas alheios. Se uma vulnerabilidade estiver sendo estudada, o trabalho deve ser feito em laboratórios controlados, com autorização e versões preparadas para testes. Provas de conceito de segurança podem provocar efeitos indesejados quando executadas em produção ou contra infraestrutura de terceiros.

A recomendação de incorporar revisões ao processo de desenvolvimento também não elimina a necessidade de defesa em profundidade. Verificações automáticas podem detectar padrões conhecidos ou apontar código suspeito, enquanto a análise humana acrescenta contexto e ajuda a avaliar o risco. Nenhum dos dois mecanismos, sozinho, garante cobertura total. O valor está em combinar detecção, validação, correção e acompanhamento.

Em resumo, o relato apresenta detalhes do que a Anthropic diz ter alcançado em uma investigação interna e das etapas de divulgação e correção que atribui aos fornecedores. É um sinal relevante sobre a evolução da pesquisa assistida por modelos, mas seu alcance deve permanecer delimitado: resultados de uma empresa, em sistemas específicos e com um modelo não lançado, sem replicação independente documentada nas fontes disponíveis.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.