Você não resolve no dinheiro um problema com trinta e cinco milhões de linhas de código. O navegador não é seguro porque foi escrito com cuidado; ele é o maior parser de conteúdo não confiável rodando no seu computador. Projetar em torno dessa premissa é a única coisa que escala.

Um navegador, em repouso, parece um milagre de engenharia muito bem financiado. Google e Apple empregam, cada uma, centenas de pessoas cujo trabalho em tempo integral é tornar o Chrome e o Safari menos exploráveis. Ambas as empresas publicam patches em pipelines de integração contínua medidos em minutos. Ambas mantêm programas de bug bounty com pagamentos de seis e sete dígitos. Ambas publicam post-mortems. Ambas têm infraestrutura de fuzzing de classe mundial. E, mesmo assim, com regularidade perfeita, todo ano, os usuários do software de consumo mais corrigido, mais blindado e mais auditado do planeta descobrem que uma página que abriram há três dias tomou conta da máquina deles em silêncio.

Este post é sobre o porquê. E também sobre por que essa conta está prestes a ficar muito pior, e sobre o que realmente achamos ser a única saída.

O dinheiro das bounties é real. Os bugs também são.

Apple e Google pagam hoje valores recordes por bugs de navegador.

O Vulnerability Reward Program da Google em 2024 pagou $12 milhões em todos os seus produtos, sendo que só o Chrome levou $3,4 milhões para 137 pesquisadores. 2025 pulverizou esse número: o VRP pagou $17,1 milhões para 747 pesquisadores — um salto de 45% ano a ano e o maior ano de bounties da história da Google. Um único escape de sandbox do Chrome (um bug de Mojo) pagou $250.000 a um só pesquisador.

A Apple está na mesma faixa. A página de security-bounty da empresa agora lista um pagamento máximo de $2 milhões para as cadeias de maior severidade (antes era $1 milhão), com multiplicadores adicionais que podem chegar a $5 milhões; o total pago em bounties desde que o programa abriu ao público já ultrapassou $35 milhões.

Esses são números grandes. São os números corretos; ambas as empresas foram transparentes sobre eles. Mas há algo desconfortável em gastar $17 milhões para encontrar bugs: o que você está realmente fazendo é comprando a prova de que existem mais bugs.

Os números, ano a ano.

Contagem média mensal de CVEs do Chrome, de 2023 até meados de abril de 2026. Cada número neste gráfico é um CVE do Chrome reportado pelos próprios engenheiros da Google, por pesquisadores da bounty ou por terceiros, e para o qual a Google publicou um patch. Os zero-days explorados na natureza — aqueles que já estavam sendo usados antes de a Google saber que existiam — aparecem rotulados acima de cada ano.

Várias coisas acontecem ao mesmo tempo neste gráfico, e cada uma delas é pior que a anterior.

A linha de 2023 a 2025 parece progresso. Menos CVEs do Chrome por mês, ano após ano, no mesmo período em que os gastos da Google com bounties cresceram pela metade. Os zero-days explorados na natureza, a única categoria que realmente importa para o usuário, se mantiveram aproximadamente estáveis em cerca de oito por ano só no Chrome — além de alguns poucos todo ano para Safari e WebKit, incluindo CVE-2023-42916 / 42917 (ambos marcados como "ativamente explorados" pela Apple no final de 2023), CVE-2024-23222 (o primeiro zero-day da Apple em 2024) e CVE-2025-24201 (explorado em "ataques extremamente sofisticados").

A interpretação era tentadora: estava funcionando, só que devagar.

E aí veio 2026. Só os três primeiros meses deste ano produziram aproximadamente 200 CVEs do Chrome — um ritmo que, se continuar, vai pulverizar todos os anos anteriores do histórico. O número de zero-days na natureza já chegou a quatro, com mais de oito meses pela frente. Algo mudou.

O que mudou tem nome.

Em 7 de abril de 2026, a Anthropic anunciou um preview de um modelo de fronteira, internamente chamado de "Copybara" e comercializado como Claude Mythos, otimizado para uma única tarefa: encontrar e explorar vulnerabilidades de segurança de forma autônoma. O relatório público do red team descreve um modelo que:

Gerou um exploit de zero-day funcional em 72,4% das vezes em benchmarks internos, contra menos de 1% da geração anterior, o Opus 4.6.
Encadeou quatro vulnerabilidades separadas em um único JIT heap spray que escapou tanto do renderizador quanto do sandbox do sistema operacional em um navegador de peso.
Encontrou "milhares" de zero-days de severidade alta e crítica em todos os principais sistemas operacionais e em todos os principais navegadores web, ao longo de uma avaliação.

Para o crédito da Anthropic, o Mythos não está sendo liberado ao público. Em vez disso, a capacidade está sendo distribuída por meio de um programa controlado chamado Project Glasswing, que inclui Apple, Google, Microsoft, AWS, Cisco, CrowdStrike, NVIDIA, Palo Alto Networks, JPMorgan Chase, Broadcom e a Linux Foundation. Essas organizações agora têm um duto direto para um modelo que acha zero-days num ritmo medido não em meses, mas em horas.

Essa é, relativamente falando, a boa notícia. A má notícia é que o Mythos é um anúncio, não uma invenção. Se um laboratório de fronteira chegou a essa capacidade dentro de um piloto restrito, outra pessoa — um governo hostil, um fornecedor comercial de spyware, um grupo criminoso bem financiado — terá algo equivalente em poucos trimestres. É o fenômeno mais amplo que a cobertura inicial da imprensa já começou a chamar de Vulnpocalypse.

A Vulnpocalypse não é retórica. É uma mudança mensurável na janela.

O termo foi usado, de forma mais visível, na reportagem de 9 de abril da NBC News sobre o Mythos e no artigo "Mythos and the Vulnpocalypse" da Cloud Security Alliance. Não é um exercício de branding. Ele descreve uma mudança específica e quantificável: o tempo médio entre a divulgação pública de uma vulnerabilidade e a sua exploração ativa caiu de cerca de 2,3 anos em 2019 para menos de 24 horas em 2026. Quando a AISLE, uma empresa de pesquisa de vulnerabilidades com IA, recebeu o aviso do OpenSSL de janeiro de 2026 no dia da publicação, redescobriu de forma independente todos os doze zero-days corrigidos em poucas horas.

A janela cada vez menor entre 'um bug é divulgado' e 'o bug está na natureza.' O ciclo de patch que era medido em anos em 2019 agora é medido em horas. Se o seu plano de segurança depende de ser mais rápido que o atacante, o atacante virou, silenciosamente, um fuzzer sobre-humano.

Isto não é hipotético. O NVD, a base canônica de vulnerabilidades do governo dos EUA, vem admitindo discretamente há mais de um ano que não consegue acompanhar: no início de 2026, o backlog de CVEs sem enriquecimento com provas de conceito funcionais é a história dominante da sua operação. As novas submissões de CVE subiram mais de 260% desde 2020, enquanto o número de analistas segue estável, e a comunicação pública do NIST passou de "vamos colocar em dia" para "vamos priorizar os de maior risco".

Se você está esperando o fornecedor publicar o patch, o patch chegar, o seu dispositivo baixar a atualização e você reiniciar o navegador — esse é um plano de segurança que, em 2026, tem uma janela de 24 horas para ser executado. Em média.

Por que esse problema é arquitetural, não orçamentário.

A razão pela qual Google e Apple não conseguem resolver isso com mais dinheiro é simples, e vale dizer com todas as letras: o navegador é o maior parser de conteúdo não confiável rodando no seu computador, e não existe parser seguro para essa quantidade de dados controlados pelo atacante.

O que se pede, de fato, que o navegador analise, com segurança, a cada carregamento de página. Cada uma das caixas abaixo é, ela mesma, um projeto de várias centenas de milhares de linhas, todas empacotadas dentro do navegador, todas uma superfície de ataque do ponto de vista de uma página hostil.

O Chromium tem aproximadamente 35 milhões de linhas de C++, mais um enorme diretório //third_party que embute mais de 200 bibliotecas externas — o decodificador WebP (CVE-2023-4863, famosamente encadeado ao Pegasus da NSO no incidente BLASTPASS), o decodificador VP8/VP9, libxml2, ICU, Skia, ANGLE, Dawn, BoringSSL. Cada uma dessas bibliotecas é um parser, lidando com dados controlados por quem for dono da página que você abriu. Qualquer bug em qualquer uma delas é um bug no navegador.

Safari e WebKit são menores — o núcleo tem cerca de 2,5 milhões de linhas de C++, segundo auditoria da Igalia —, mas o formato da superfície de ataque é idêntico: uma pilha monumental de parsers em C e C++ processando entrada adversária, com cada byte decodificado rodando dentro do mesmo espaço de endereços do perfil do seu navegador.

Você não consegue escrever tanta linha de C++ lidando com tanta entrada não confiável sem bugs. Você não consegue comprar sua saída dos bugs quando o lado atacante do mercado agora tem acesso a um fuzzer que gera exploits em horas. O ritmo com que o defensor consegue encontrar e publicar correções e o ritmo com que o atacante consegue encontrar e transformar em arma novos bugs estão, em abril de 2026, matematicamente divergindo.

O que os zero-days recentes realmente fizeram.

Mesmo antes do anúncio do Mythos, os zero-days de navegador mais significativos dos últimos três anos já eram alarmantes. Uma lista curta:

BLASTPASS / libwebp, 2023

CVE-2023-4863 era um heap overflow no decodificador de imagens WebP usado tanto pelo Chrome quanto pelo Safari. O exploit, empregado pelo spyware Pegasus do NSO Group, não exigia interação: visitar a imagem errada era o bastante. Segue como uma das demonstrações mais claras, no mundo real, de um parser de terceiros comprometendo o navegador inteiro.

Operation ForumTroll, 2025

CVE-2025-2783, descoberto pela Kaspersky GReAT, era um escape de sandbox de Mojo no Chrome. Foi encadeado com um comprometimento do renderizador para entregar o spyware comercial da Memento Labs a alvos na Rússia e na Bielorrússia. A Google corrigiu o bug em poucos dias após a divulgação. Os atacantes vinham usando ele há pelo menos meses.

Exploração do V8 pela Coreia do Norte, 2024

CVE-2024-7971 era uma confusão de tipos no V8 usada por atores ligados à Coreia do Norte para implantar um kit de roubo de criptomoedas. O mesmo ano viu vários outros bugs de V8 associados a fornecedores comerciais de spyware. O ponto em comum: todos eles precisaram só de uma página web.

Safari, final de 2025

CVE-2025-24201 foi explorada no que a Apple descreveu como "ataques extremamente sofisticados" dirigidos a indivíduos específicos. Outro par em dezembro (CVE-2025-43529, CVE-2025-14174) explorou WebKit e ANGLE e foi marcado como ativamente explorado em ataques dirigidos. O WebKit compartilha genealogia de código com o ANGLE do Chromium; um bug em um às vezes é corrigido em ambos.

Esses bugs não foram encontrados porque os engenheiros foram desleixados. Foram encontrados porque os adversários modernos são pagos para encontrá-los, e porque sempre há mais. O que o Mythos faz é mudar a proporção entre "pesquisadores que conseguem achar um bug" e "pessoas que podem pagar um pesquisador que consegue achar um bug". A Anthropic restringiu a ferramenta por ora. Virão outras.

O argumento arquitetural.

Tudo acima deveria apontar para uma conclusão: a premissa de projeto correta é que o seu navegador tem um zero-day dentro dele agora, que você não conhece, que vai ser usado contra alguém neste ano, e que pode ser usado contra você.

Assumindo isso, a única pergunta que importa é: o que acontece depois que o bug dispara?

Num navegador tradicional, a resposta é brutal. O navegador roda dentro da sua conta de usuário. O renderizador dele tem acesso aos seus arquivos, ao seu chaveiro, aos seus cookies, à sua webcam, ao seu microfone e à sua rede local — porque são coisas às quais a sua conta de usuário tem acesso, e o navegador é um programa que roda como esse usuário. Um comprometimento do renderizador que burle o sandbox do navegador — exatamente o que o Mythos demonstrou em um navegador de peso durante a avaliação — é um comprometimento do seu computador. Ponto final.

Esse é o desfecho que o resto da indústria aceita implicitamente e sobre o qual planeja em silêncio — com camadas de EDR, detecção de endpoint, MDM, telemetria, resposta a incidentes e, para os azarados, advogados de negociação de ransomware de plantão.

O Bromure faz algo diferente.

O Bromure não tenta correr mais rápido que o Mythos. Essa corrida não dá para vencer. O que o Bromure faz é mudar até onde um zero-day de fato chega.

Um zero-day de navegador em um navegador tradicional roda dentro da sua conta de usuário. O mesmo zero-day no Bromure roda dentro de uma máquina virtual descartável que não contém seus arquivos, seu chaveiro nem qualquer outra coisa com a qual você se importa. O pior desfecho é a perda da sessão de navegador que você já fechou.

No Bromure, o navegador roda dentro de uma VM convidada lacrada. Quando um comprometimento do renderizador dispara — o mesmo escape de sandbox de Mojo que rodou na Operation ForumTroll, a mesma confusão de tipos encadeada no V8 que o Mythos gerou em testes internos —, o atacante agora tem execução de código dentro de uma máquina virtual Linux descartável. Essa VM não contém seus arquivos. Não contém seu chaveiro. Não contém sua webcam, nem seu microfone, nem sua rede local. Ela contém um navegador, um perfil e qualquer estado que esse perfil tenha acumulado.

Quando a sessão termina e você fecha a janela, a VM é destruída. O exploit é destruído junto. Persistência — o movimento mais valioso que um atacante faz depois do acesso inicial — não pode ser estabelecida em algo que está prestes a deixar de existir.

O que não estamos afirmando.

A arquitetura do Bromure não é uma bala de prata. Dois limites que vale declarar:

O exploit ainda compromete a sessão do navegador

Senhas digitadas naquela sessão, cookies guardados naquele perfil, dados preenchidos em formulários durante a janela do exploit — tudo isso vive dentro da VM e pode ser alcançado por um comprometimento dessa VM. O isolamento mantém o dano escopado à sessão; não protege retroativamente entradas que já foram entregues à sessão. A separação por perfil e as sessões descartáveis reduzem o valor desse raio de explosão; não o zeram.

Um escape da VM ainda está em jogo

Uma cadeia suficientemente severa poderia, em princípio, escapar da própria VM. Isso é um problema muito mais difícil do que escapar de um sandbox de navegador — várias ordens de grandeza menos bugs, e a superfície de ataque do hypervisor é, por projeto, mais estreita do que a de um navegador —, mas não é zero. O Bromure reduz a probabilidade de um zero-day de navegador virar um comprometimento do host; não elimina essa probabilidade.

O número útil não é "risco zero". O número útil é "quantos zero-days por ano acabam comprometendo, de fato, o seu computador de fato". Num navegador tradicional, esse número vinha subindo e está prestes a subir mais rápido. No Bromure, ele é barrado por uma classe separada de bug que custa cerca de cem vezes mais para ser encontrada.

Planeje para o mundo em que você está prestes a viver.

Zero-days de navegador não são um bug no ecossistema. São uma característica estrutural de rodar dezenas de milhões de linhas de C++ no caminho de bytes adversários, para a qual não existe correção de engenharia crível, e para a qual o dissuasor econômico (você é caro demais para ser atacado) está prestes a ser automatizado para fora da equação. Apple e Google não estão sendo relapsos. O problema é genuinamente mais difícil do que os orçamentos delas.

O que podemos fazer, e o que o Bromure faz, é mover o raio de explosão. Isolar o navegador. Tornar cada sessão descartável. Colocar o sistema operacional do host uma parede a mais de distância de cada página. Esse é um formato de produto diferente, e é o único que encontramos que ainda faz sentido quando o adversário é uma fábrica de exploits com IA sempre ligada, com uma conta de API de três dígitos.

Instale o Bromure. Torne-o seu padrão para tudo em que você não confia plenamente. E quando a próxima manchete disser "Zero-day ativamente explorado no Chrome corrigido em release de emergência" — e ela vai, dentro de semanas —, continue lendo, porque o desfecho não precisa ser o seu.