O Google lançou, em 3 de setembro, uma atualização emergencial do Chrome para corrigir a CVE-2026-85046, uma falha crítica no V8 — o motor que processa JavaScript e WebAssembly no navegador — que já estava sendo explorada por atacantes antes de a correção ficar disponível. A vulnerabilidade recebeu nota 8.8 de 10 na escala CVSS e permite que um invasor execute código dentro do navegador apenas com a vítima abrindo uma página HTML maliciosa, sem download, clique adicional ou instalação de nada. A CISA, agência de cibersegurança do governo dos Estados Unidos, incluiu a falha em seu catálogo de vulnerabilidades exploradas ativamente em 4 de setembro e deu prazo até 18 de setembro para que órgãos federais americanos apliquem o patch — mas o alerta vale para qualquer usuário do Chrome, incluindo empresas e desenvolvedores no Brasil.
O que é a CVE-2026-85046
A CVE-2026-85046 é uma falha do tipo confusão de tipos (type confusion) no V8, o motor de JavaScript e WebAssembly que roda por baixo do capô em todo navegador baseado em Chromium. Segundo a descrição oficial da vulnerabilidade no National Vulnerability Database (NVD), o problema permite que um atacante remoto execute código arbitrário dentro do sandbox do Chrome a partir de uma página HTML manipulada — ou seja, basta a vítima abrir um link ou visitar um site comprometido para o ataque ser disparado, sem precisar baixar nenhum arquivo ou conceder qualquer permissão.
Em termos técnicos, confusão de tipos acontece quando o motor trata um trecho de memória como se fosse um tipo de objeto diferente do que realmente é. Esse descompasso abre brecha para corromper a memória do processo de forma controlada — e, no caso do V8, essa corrupção pode ser conduzida até a execução de código dentro do processo do navegador.
Exploração ativa antes da correção
O próprio aviso de segurança do Google reconhece que existia um exploit para a CVE-2026-85046 circulando em ataques reais antes de a correção chegar aos usuários, segundo reportagens do The Hacker News e da BleepingComputer. Como é padrão em falhas críticas sob exploração ativa, o Google não divulgou detalhes técnicos do ataque nem atribuiu a campanha a um grupo específico — a ideia é reduzir o risco de outros criminosos reproduzirem a exploração antes que a maioria dos usuários atualize o navegador.
O pesquisador de segurança Salvatore Gulizia, conhecido como Serotav, é creditado por ter reportado a falha ao Google em 4 de agosto de 2026, cerca de um mês antes de a correção ser publicada — prazo compatível com o processo padrão de divulgação coordenada da empresa.
Quais versões corrigem a falha
O Google publicou a correção no Canal Estável do Chrome em 3 de setembro de 2026, de acordo com o blog oficial Chrome Releases. As versões corrigidas são:
- Windows e macOS: Chrome 152.0.7977.82 (ou 152.0.7977.83, conforme a plataforma)
- Linux: Chrome 152.0.7977.82
A atualização é distribuída de forma gradual nos dias seguintes ao lançamento, o que significa que nem todo usuário recebe o patch no mesmo instante — mais um motivo para verificar manualmente. Para conferir a versão instalada e forçar a checagem, abra chrome://settings/help; se houver atualização disponível, o Chrome a baixa automaticamente e pede apenas para reiniciar o navegador.
O patch só entra em vigor depois que o navegador é reiniciado. Deixar dezenas de abas abertas por semanas é um hábito comum — e também o motivo mais frequente de máquinas continuarem vulneráveis mesmo depois de o Chrome já ter baixado a correção.
Por que a CISA colocou prazo até 18 de setembro
A Cybersecurity and Infrastructure Security Agency (CISA) adicionou a CVE-2026-85046 ao seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) em 4 de setembro de 2026, segundo a Security Affairs e a Help Net Security. A entrada no catálogo KEV obriga formalmente apenas as agências do governo federal americano a aplicar a correção até 18 de setembro — mas, na prática, funciona como um sinalizador internacional de gravidade: a CISA só inclui no KEV falhas com evidência confirmada de exploração ativa, não vulnerabilidades teóricas.
Para equipes de segurança e TI fora dos Estados Unidos, incluindo empresas brasileiras, o catálogo costuma servir de referência prática para priorizar patches — mesmo sem obrigação legal de cumprir o prazo da CISA.
Outros navegadores baseados em Chromium também precisam de atenção
O V8 não é exclusivo do Chrome: é o mesmo motor usado por navegadores construídos sobre o projeto de código aberto Chromium, como Microsoft Edge, Brave, Opera e Vivaldi. Na prática, isso significa que esses navegadores tendem a herdar a mesma vulnerabilidade até que cada fabricante publique sua própria atualização baseada no código corrigido pelo Google — processo que segue calendário próprio de cada empresa e pode levar mais tempo do que o Chrome. Até o fechamento deste artigo, não foram localizados nas fontes consultadas anúncios oficiais de correção específicos da Microsoft ou dos demais fabricantes de navegadores Chromium; quem usa esses navegadores deve conferir diretamente o changelog de cada um antes de considerar o problema resolvido.
Um padrão: o sexto zero-day do Chrome só em 2026
Segundo levantamentos de veículos de segurança como a SecurityWeek e a Security Affairs, a CVE-2026-85046 é a sexta falha do Chrome explorada ativamente identificada em 2026 — todas classificadas com CVSS 8.8, sendo três delas, incluindo esta, localizadas especificamente no V8. O número não é uma estatística divulgada oficialmente pelo Google, mas uma contagem feita pela imprensa especializada a partir dos avisos de segurança publicados ao longo do ano; ainda assim, ele mostra que o motor de JavaScript do navegador mais usado do mundo segue sendo um dos alvos mais visados por quem desenvolve exploits — provavelmente pela combinação de superfície de ataque enorme (praticamente todo mundo usa um navegador) com a complexidade inerente ao código que processa JavaScript não confiável o tempo todo.
O que isso significa para empresas e desenvolvedores no Brasil
O Chrome é o navegador mais usado no Brasil, tanto por usuários finais quanto dentro de empresas — inclusive como ferramenta de trabalho para acessar painéis administrativos, ambientes de nuvem e sistemas internos. Uma falha de execução de código no navegador é particularmente sensível nesse cenário: se um funcionário abre uma página maliciosa em uma máquina desatualizada, o invasor ganha um ponto de entrada dentro da rede da empresa. O movimento não é isolado — outras frentes da indústria também têm reforçado controles de segurança em ferramentas do dia a dia do desenvolvedor, como o [GitHub, que passou a restringir quais servidores MCP o Copilot pode acessar](/artigo/github-allowlist-mcp-copilot) justamente para reduzir esse tipo de superfície de ataque.
Para empresas brasileiras, isso também cruza com obrigações da LGPD: manter sistemas atualizados e adotar medidas técnicas de segurança faz parte do dever de cuidado com dados pessoais previsto na lei, e um incidente que envolva exposição de dados por um navegador desatualizado pode acionar a exigência de notificação a titulares e à ANPD. Times que já mantêm um [checklist de LGPD para startups](/artigo/lgpd-checklist-startups-2026) devem tratar a gestão de patches de navegador como parte da rotina de segurança, não como uma ação pontual disparada só quando uma falha vira manchete.
Como se proteger agora
- Abra chrome://settings/help para forçar a checagem de atualização e reinicie o navegador em seguida.
- Em ambientes corporativos, confirme com o time de TI se a atualização já foi distribuída via política gerenciada (Google Admin Console ou GPO) para todas as máquinas.
- Se usa Edge, Brave, Opera, Vivaldi ou outro navegador baseado em Chromium, verifique o changelog do fabricante antes de considerar o problema resolvido.
- Desative extensões desnecessárias — elas aumentam a superfície de ataque mesmo depois do navegador corrigido.
- Trate avisos de atualização pendente do navegador com a mesma prioridade dada a um patch de sistema operacional.
Falhas como a CVE-2026-85046 reforçam um ponto que a atualização automática às vezes esconde: o navegador só está protegido depois que o patch baixado é efetivamente aplicado, o que normalmente exige reiniciar o processo. Vale conferir agora — o custo de checar é de menos de um minuto; o de não checar, potencialmente, é bem maior. Para acompanhar outras coberturas de segurança do Bytezine, veja a [categoria de Segurança](/categoria/seguranca).
Perguntas frequentes
É uma vulnerabilidade crítica (CVSS 8.8) do tipo confusão de tipos no V8, o motor de JavaScript e WebAssembly do Chrome, que permite executar código dentro do navegador a partir de uma página HTML maliciosa, sem exigir download ou instalação.
