Zero-day do Chrome: o caso da CVE-2026-85046

Em 3 de setembro de 2026, o Google publicou uma atualização do canal estável do Chrome para corrigir a CVE-2026-85046, uma falha de confusão de tipos no motor V8 que já vinha sendo explorada por atacantes reais antes de existir correção. É o sexto zero-day do Chrome corrigido em 2026 e o terceiro deles dentro do V8. No dia seguinte, 4 de setembro de 2026, a agência americana CISA incluiu a falha no catálogo de vulnerabilidades exploradas conhecidas (KEV) e fixou 18 de setembro de 2026 como prazo para as agências federais civis dos Estados Unidos aplicarem a correção.

Cadeados sobre teclado de computador, simbolizando segurança digital — Imagem: rawpixel (CC0)

O detalhe que importa para quem não trabalha com segurança é simples: bastava abrir uma página preparada para o ataque, sem anexo para baixar, programa para instalar nem senha para digitar. É por isso que o navegador virou o alvo preferido: ele é o único software da máquina que executa, o dia inteiro, código escrito por estranhos, e ao mesmo tempo guarda sessões de e-mail, banco, nuvem corporativa e carteiras cripto.

O que é um zero-day e por que ele muda o cálculo de risco

Zero-day é a falha que já está sendo usada em ataques quando o fabricante ainda não tem correção disponível. O nome vem da contagem: o defensor teve zero dias de vantagem. Numa vulnerabilidade comum, existe uma janela entre a publicação do patch e a chegada do primeiro exploit, e quem atualiza rápido nunca fica exposto. Num zero-day, a ordem se inverte: o ataque vem primeiro, e a corrida já começa atrasada.

No caso da CVE-2026-85046, o comunicado oficial do Chrome traz a frase padrão do Google para esse cenário. Segundo Srinivas Sista, do time do Google Chrome, que assina o comunicado, “o Google sabe que existe um exploit para a CVE-2026-85046 em circulação”. O Google também informou que o acesso aos detalhes técnicos permanece restrito até que a maioria dos usuários tenha instalado a correção, prática adotada para não facilitar a vida de quem ainda não sabia da falha.

O que é o motor V8 e o que é uma confusão de tipos?

O V8 é o motor de JavaScript e WebAssembly do Chrome e de todos os navegadores baseados em Chromium. Ele pega o código JavaScript de qualquer site aberto e o transforma em instruções que o processador executa de verdade. Para ser rápido, usa compiladores otimizadores que fazem suposições sobre o formato dos dados: assumem, por exemplo, que determinado array só contém números inteiros pequenos e geram código de máquina especializado nessa aposta.

Confusão de tipos (categoria CWE-843 na classificação usada pelo NVD) é o que acontece quando essa aposta deixa de valer e ninguém percebe. O programa trata um pedaço de memória como se fosse de um tipo, quando é de outro, e operações legítimas passam a ler e escrever onde não deveriam. Não é preciso invadir nada: o próprio motor faz o trabalho errado com confiança total.

O que a CVE-2026-85046 permitia (e o que ela não fazia sozinha)

A descrição oficial registrada no NVD é direta: confusão de tipos no V8, em versões do Google Chrome anteriores à 152.0.7977.82, permitia que um atacante remoto executasse código arbitrário dentro do sandbox por meio de uma página HTML manipulada. A nota é 8.8 (alta) no CVSS 3.1, com vetor AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Traduzindo os campos que mais pesam: o ataque vem pela rede, não exige privilégio nenhum e não exige conhecimento prévio da vítima, mas exige uma interação, que no mundo real significa abrir a página errada.

Vale ser preciso sobre o limite da falha, porque é onde muita manchete exagera. A execução acontece dentro do sandbox do processo de renderização, a caixa isolada em que o Chrome roda o conteúdo de cada site. Para virar controle do sistema operacional inteiro, seria preciso encadear essa falha com uma segunda vulnerabilidade de escape do sandbox. O que não torna o problema pequeno: dentro do renderizador já está tudo o que a aba enxerga.

Quem reportou, quando e quais versões corrigiram

A falha foi reportada em 4 de agosto de 2026 pelo pesquisador de segurança Salvatore Gulizia, conhecido como Serotav, que recebeu 1.000 dólares do programa de bug bounty do Chrome. Foram trinta dias entre o reporte e a correção pública. A mesma atualização de 3 de setembro de 2026 fechou doze vulnerabilidades, entre elas uma condição de corrida no V8 (CVE-2026-85045), reportada por Brendan Dolan-Gavitt, da XBOW, em 17 de agosto de 2026.

As versões corrigidas, por plataforma e por navegador, são estas:

Google Chrome no Windows e no macOS: 152.0.7977.82/.83 ou superior.
Google Chrome no Linux: 152.0.7977.82 ou superior.
Microsoft Edge, canal estável: 152.0.4191.62, que incorpora a correção do Chromium.
Brave: a versão 1.94.119, publicada em 2 de setembro de 2026, ainda era baseada no Chromium 152.0.7977.76, anterior à correção. Quem usa Brave precisa confirmar que já recebeu uma build posterior.
Opera, Vivaldi e demais navegadores Chromium: dependem do repasse de cada fabricante, que costuma vir dias depois do Chrome.

O prazo da CISA no catálogo KEV

Em 4 de setembro de 2026, a CISA adicionou a CVE-2026-85046 ao catálogo KEV, a lista das falhas com exploração confirmada no mundo real. A inclusão aciona a diretiva BOD 22-01, que obriga as agências federais civis dos Estados Unidos a remediar a vulnerabilidade dentro do prazo estabelecido. Nesse caso, o prazo é 18 de setembro de 2026, ou seja, quatorze dias.

O prazo não vale juridicamente para empresas brasileiras, mas serve como referência de urgência gratuita e bem calibrada. Se o governo americano considera quatorze dias o limite aceitável para uma falha de navegador já explorada, um parque de máquinas comum não deveria demorar mais do que isso.

Os outros zero-days do Chrome em 2026

A CVE-2026-85046 é a sexta do ano. As cinco anteriores, todas com nota 8.8 no CVSS, foram:

CVE-2026-2441, em fevereiro de 2026: invalidação de iterador em CSSFontFeatureValuesMap, no componente de CSS.
CVE-2026-3909, em março de 2026: escrita fora dos limites na biblioteca gráfica Skia.
CVE-2026-3910, em março de 2026: implementação inadequada no V8.
CVE-2026-5281, em abril de 2026: uso após liberação de memória no Dawn, componente ligado ao WebGPU.
CVE-2026-11645, em junho de 2026: leitura e escrita fora dos limites no V8.

O padrão salta aos olhos: três das seis estão no V8 e as outras três estão em componentes que também processam conteúdo hostil vindo da web (CSS, renderização gráfica e GPU). São justamente as partes que precisam ser rápidas e, por isso, trabalham perto da memória bruta.

Como verificar e forçar a atualização do seu navegador

Navegadores baseados em Chromium baixam atualizações em segundo plano, mas só terminam de aplicá-las quando o programa é reiniciado. Quem deixa o navegador aberto por semanas pode estar com o patch baixado e inativo.

No Chrome, digite chrome://settings/help na barra de endereços e pressione Enter. O mesmo caminho existe pelo menu de três pontos, em Ajuda, depois Sobre o Google Chrome.
A abertura dessa página já dispara a verificação. Aguarde o download terminar.
Clique em Reiniciar (ou Relaunch). Sem esse reinício, a correção não entra em vigor.
Volte à mesma página e confira o número exibido. No Windows e no macOS, ele precisa ser igual ou superior a 152.0.7977.82/.83; no Linux, igual ou superior a 152.0.7977.82.
No Microsoft Edge, o endereço equivalente é edge://settings/help, e a versão precisa ser 152.0.4191.62 ou superior. No Brave, use brave://settings/help. No Vivaldi, vivaldi://settings/help. Na Opera, o caminho é o menu Opera, depois Atualização e recuperação.
No Android e no iOS, a atualização vem pela loja de aplicativos: procure o Chrome na Play Store ou na App Store e verifique se o botão diz Abrir e não Atualizar.
Em ambiente corporativo, confira se a política de gerenciamento não está travando a versão. Cheque também servidores, containers e pipelines que rodam Chromium em modo headless: eles raramente entram na rotina de patch e seguem processando conteúdo externo.

Extensões e carteiras cripto: o que muda

Aqui está a parte subestimada. Uma falha que dá leitura e escrita arbitrárias no processo de renderização não precisa escapar do sandbox para causar prejuízo: naquela caixa já estão os cookies de sessão, os tokens de autenticação e o conteúdo das páginas abertas. Uma sessão de e-mail ou de painel administrativo roubada vale tanto quanto uma senha, e não é barrada pelo segundo fator, porque ele já foi apresentado.

Carteiras cripto em extensão merecem atenção redobrada porque concentram valor irreversível e vivem no mesmo navegador que abre qualquer link. As medidas são de higiene, não de heroísmo: atualize o navegador antes de qualquer operação relevante, use um perfil separado só para carteira e banco, revise as extensões instaladas e remova as que não usa, desconfie das que pedem permissão para ler dados em todos os sites e mantenha as chaves de maior valor em carteira de hardware, fora do navegador. A lição estrutural do ano é a outra ponta: com seis zero-days de Chrome em 2026, tratar atualização de navegador como manutenção de rotina, e não como resposta a incidente, deixou de ser opcional.