Quatro bugs, uma página, alguns segundos. Cadeias de exploits como esta exigiam uma equipe de especialistas, e agora um modelo consegue montar uma. O navegador que o seu agente de código controla fica exposto a elas em cada página que abre.

Em 27 de outubro, o Frontier Red Team da Anthropic publicou um relatório sobre cinco cadeias de exploits que um modelo interno de pesquisa, ainda não lançado, encontrou e montou “depois de um prompt inicial”. Uma cadeia de exploits liga vários bugs de modo que cada um leve o ataque além de uma defesa que o anterior não conseguia passar. Os alvos foram Chrome, Safari, Android, Windows e Linux. A Anthropic reportou as cinco aos fornecedores em divulgação coordenada, e o The Hacker News, que cobriu o relatório ontem, observa que nenhuma foi vista num ataque real.

A conclusão da Anthropic cabe numa linha: “Modelos de fronteira têm a capacidade de descobrir e combinar múltiplas vulnerabilidades num exploit funcional.”

Uma página, quatro bugs

A cadeia do Chrome é a que merece leitura atenta. A prova de conceito abriu a Calculadora a partir de um Chrome com configuração padrão no macOS “segundos depois de a página carregar”. A Calculadora é a prova tradicional: se um exploit consegue abrir um app no seu Mac, consegue abrir qualquer outra coisa.

Foram precisos quatro bugs:

Uma falha no V8, o motor JavaScript do Chrome, permitia que a página corrompesse a memória do motor.
Uma segunda falha no V8 escapava do sandbox de memória do próprio V8 e dava ao atacante o controle do renderer, o processo que desenha a página.
Uma race condition no CacheStorage permitia que esse renderer lesse memória fora do sandbox e mapeasse o processo do navegador, mais privilegiado.
Um use-after-free no FedCM, o recurso de login federado do Chrome, executava o código do atacante totalmente fora do sandbox.

O sandbox do Chrome parte do princípio de que o renderer vai cair em algum momento e mantém o estrago dentro dele. Os passos três e quatro desfazem isso. A Anthropic diz ter reportado 62 falhas do Chrome que receberam CVEs e estavam corrigidas no Chrome 156, todas classificadas como críticas ou altas, incluindo 13 fugas do sandbox e 21 bugs de comprometimento do renderer.

A cadeia do Safari nunca executa código. Ela ganha acesso de leitura e escrita à memória do navegador e muda um único valor para desligar a same-origin policy, a regra que impede um site de ler outro. Com a regra desligada, qualquer página podia ler o histórico, os cookies e os dados de sessão do Safari e enviar requisições autenticadas a outros sites. A Apple corrigiu a falha no iOS e iPadOS 26.5.2.

A cadeia do Linux chegou a um shell root pela rede, sem login, em qualquer máquina com um listener multipath TCP. Vazar um endereço do kernel levou cerca de 48 minutos, e o shell mais cinco. O bug, CVE-2026-98432, foi corrigido upstream em 15 de outubro.

A cadeia do Chrome no relatório da Anthropic. Uma página maliciosa corrompe a memória do V8, uma segunda falha no V8 toma o controle do renderer, uma race condition no CacheStorage vaza o layout de memória do processo do navegador, e um use-after-free no FedCM executa código fora do sandbox do Chrome. A prova de conceito abriu a Calculadora num Mac padrão segundos depois de a página carregar.

Seu agente abre mais páginas do que você

São bugs de navegador, e um agente de código é hoje um dos usuários de navegador mais ativos na máquina de um desenvolvedor. Ele lê documentação, segue um link de uma issue, abre a página de um pacote, confere um resultado de busca, carrega o app que acabou de construir para tirar uma captura de tela. Servidores MCP de navegador e extensões de navegador tornaram isso rotina: o agente controla um Chromium de verdade, muitas vezes o mesmo perfil do Chrome em que o desenvolvedor entra toda manhã.

A maioria dessas páginas o desenvolvedor nunca escolheu. Um link numa issue do GitHub, uma URL num README, o terceiro resultado de busca para uma mensagem de erro: qualquer uma delas pode servir uma cadeia como a da Anthropic, e com a cadeia do Chrome o agente não precisa clicar em nada. O carregamento da página executa os quatro passos.

Num notebook, o fim dessa cadeia é a conta do desenvolvedor no Mac. A mesma conta guarda ~/.ssh, ~/.aws/credentials, o login do gh, as chaves de API do próprio agente e todos os repositórios clonados. Troque a Calculadora por um script e ele copia tudo isso. Com a cadeia do Safari, o prêmio é o conteúdo do próprio navegador: os cookies e sessões de todos os sites em que o desenvolvedor está logado, ao alcance de uma única página.

A mesma página no Bromure Agentic Coding

O Bromure Agentic Coding roda Claude Code, Codex, Grok, Kimi e omp em VMs Ubuntu no seu Mac. Cada máquina também ganha o próprio navegador: um Chromium completo que abre num painel ao lado do chat, que você e o agente compartilham. O agente o controla por um servidor MCP browser integrado, com 23 ferramentas para navegar, clicar, ler o DOM, tirar capturas de tela e ler o console e o log de rede. Você não configura nada.

O navegador tem uma VM só para ele

Esse Chromium não roda no seu Mac, nem na VM do agente. Ele roda numa VM auxiliar separada. A VM do agente e a VM do navegador compartilham uma rede privada para que o navegador possa carregar o servidor de desenvolvimento que o agente iniciou, e é só isso que elas compartilham. Um arquivo que o agente grava não está no disco do navegador. Até localhost, no navegador, aponta para a própria VM do navegador.

Rode a cadeia do Chrome da Anthropic contra esse navegador. Os passos um a quatro funcionam como planejado: o renderer cai, o sandbox cai, e o código do atacante roda como o navegador. Esse código agora está dentro de uma VM que contém um Chromium e mais nada. Não há ~/.ssh para copiar nem ~/.aws para ler. O repositório, a configuração do agente e os tokens dele estão todos em outra VM, e o seu Mac fica atrás de uma fronteira de hypervisor. As ferramentas de navegador do agente também não compartilham processo com o Chromium: chegam a ele por um pequeno shim que fala com o host via vsock. Nas palavras do manual, “uma página hostil nunca consegue tocar nos arquivos do agente nem no seu Mac”.

O navegador esquece

Por padrão, o navegador é descartável. O disco dele é um clone copy-on-write de uma imagem compartilhada, apagado quando o navegador é desmontado. Um navegador oculto é suspenso depois de uns dez segundos e desmontado depois de cinco minutos, e o próximo começa de uma imagem limpa. Um payload que chega à VM do navegador vai embora junto com a VM.

Isso também cobre o tipo de cadeia do Safari, a que lê cookies e sessões em vez de executar código. Um navegador descartável não tem sessões de ontem. Ele guarda o que o agente acessou durante esta tarefa, e nada da sua navegação do dia a dia, porque o seu navegador de todo dia é outro programa, em outra máquina.

Quando um projeto precisa de um login que dure, Stay signed in to websites, nas configurações Browser da máquina, mantém um perfil num disco criptografado, só para aquela máquina. Ative para o site de staging que o agente testa, e deixe desligado em qualquer máquina apontada para código não confiável.

A mesma cadeia num notebook e numa máquina Bromure. No notebook, o agente controla um navegador que roda como você no Mac, então um código que escapa do sandbox do Chrome pode ler suas chaves, tokens e repositórios. No Bromure, o navegador do agente roda na própria VM auxiliar descartável; uma fuga cai numa VM que só contém o Chromium, separada da VM do agente e do Mac, e a VM é jogada fora.

A VM do próprio agente só tem substitutos

Suponha que um atacante vá mais longe e alcance a VM do agente por outro caminho, por exemplo um pacote malicioso que o agente instala seguindo as instruções da página. As chaves ali são substitutas. O token do GitHub na configuração do gh e em ~/.git-credentials é falso, e o proxy no seu Mac o troca pelo verdadeiro só no caminho para github.com. Um substituto enviado para qualquer outro host é bloqueado antes de sair do Mac, e a VM pausa com um alerta que mostra a credencial e para onde ela ia.

Analise cada pull request, no seu Mac

A Anthropic diz aos defensores que “analisar o próprio código é mais importante do que nunca”. O relatório acrescenta que a análise deve acontecer no momento do pull request, porque limpar o acúmulo “só resolve metade do problema” enquanto código novo continua chegando.

O Bromure Agentic Coding já vem com isso. Uma automação de code review vigia um repositório do GitHub com um agente numa das suas máquinas e registra o que encontra como findings, sem duplicatas entre uma análise e outra. Uma vigilância pode rodar três tipos de análise:

Cada novo pull request, revisando o que o pull request muda.
Cada novo commit no branch vigiado.
Uma revisão agendada, semanal, dos commits novos desde a última ou do repositório inteiro. A linha de base completa avança diretório por diretório em ordem de risco, começando pelos handlers de requisição, autenticação e parsing de entrada.

Qualquer um dos cinco agentes pode rodá-la. Cada revisão fica atrelada ao commit que cobriu, e o agente encerra a execução com findings_done e um resumo. A análise roda no seu Mac, com as credenciais da máquina, dentro da VM dela. O GitHub é consultado a partir do Mac a cada três minutos com o token da máquina, e esse token nunca entra na VM. Não há webhooks nem portas abertas.

Um analisador de pull requests lê texto não confiável escrito por quem abriu o pull request, e um revisor autônomo roda com as solicitações de aprovação desativadas. O Bromure passa o título, o corpo, o autor e os comentários de cada pull request por uma triagem obrigatória contra prompt injection antes que o agente os veja. Se o modelo PromptGuard não estiver instalado, as execuções disparadas por eventos são bloqueadas em vez de liberadas. A revisão em si roda numa VM cheia de substitutos. Defina a política de escrita do GitHub da máquina como Read-only em Guardrails e o revisor pode ler tudo o que o token permite, enquanto qualquer push ou escrita REST é recusado no Mac. Os findings vão para o Bromure, não para o repositório.

O navegador é uma VM à parte

O Chromium do agente roda numa VM auxiliar. Uma fuga do sandbox cai ao lado do Chromium, longe do código, das chaves e do seu Mac.

Descartável por padrão

O disco do navegador é um clone apagado ao desmontar. Payloads e cookies não sobrevivem à tarefa.

Substitutos por trás

A VM do agente guarda tokens falsos. Os verdadeiros ficam no Mac e só são adicionados para o host a que pertencem.

Revisão em cada PR

Automações de revisão de código analisam cada pull request e commit, fazem triagem de injection no texto do PR e podem rodar em modo só leitura.

Corrija, analise e dê ao navegador a própria máquina

Todos os bugs do relatório estão corrigidos, e o primeiro passo é o de sempre: atualize o Chrome para a versão 156 ou posterior, atualize os dispositivos Apple e corrija os kernels que rodam listeners multipath TCP. A Anthropic tem razão: os defensores precisam dos mesmos modelos que os atacantes logo terão, apontados primeiro para o próprio código.

O ponto mais amplo do relatório é sobre a próxima leva de bugs. Se os modelos conseguem transformar um punhado de falhas numa cadeia funcional com essa rapidez, algumas dessas cadeias estarão ativas antes de o patch sair. Um agente de código que navega o dia inteiro vai acabar carregando uma dessas páginas. No Bromure Agentic Coding, essa página carrega numa VM feita para ser perdida, e o seu código, as suas chaves e o seu Mac estão em outro lugar.

Para ver como o navegador Bromure lida com zero-days de navegador fora do coding agêntico, leia Por que os zero-days de navegador não vão embora. Para uma instrução maliciosa que chegou a um agente por um arquivo baixado, leia O download dava as ordens.