Zero-day do Chrome: como garantir que toda a equipe atualize

O zero-day do Chrome mais recente, o CVE-2026-125350, já estava sendo explorado quando o Google publicou a correção em 9 de novembro de 2026. No dia seguinte a CISA, agência de cibersegurança dos EUA, colocou a falha no catálogo de vulnerabilidades exploradas. Só que o patch não protege ninguém enquanto o navegador não reinicia. Este guia mostra como garantir que todos os Chrome, Edge, Brave e Opera da sua equipe atualizem de verdade.

TL;DR

• O CVE-2026-125350 é uma falha do tipo use-after-free no componente XML do Chromium, com exploração ativa confirmada pelo Google. É o oitavo zero-day do Chrome corrigido em 2026.
• Versões corrigidas: Chrome 157.0.8103.50/.51, Edge 157.0.4341.46, Brave 1.99.56 e Opera 140. A CISA deu prazo até 24/11/2026 para os órgãos federais americanos.
• O navegador baixa a atualização sozinho, mas só aplica depois de reiniciar. Aba aberta há uma semana é aba vulnerável.
• A saída é política, não pedido educado: RelaunchNotification, RelaunchNotificationPeriod e RelaunchWindow forçam o reinício num horário que não atrapalha o trabalho.
• Fique de olho no SignDrop, uma prova de conceito de elevação de privilégio no Windows que ainda não tem CVE nem correção. Não há registro de ataque real, mas é o tipo de peça que completa um ataque iniciado no navegador.

O que é o CVE-2026-125350, o zero-day do Chrome de novembro

Zero-day é a falha que os atacantes conhecem e exploram antes de existir correção, ou logo depois dela, quando quase ninguém aplicou ainda. O caso de novembro se encaixa na segunda situação.

Segundo o catálogo Known Exploited Vulnerabilities (KEV) da CISA, o CVE-2026-125350 é um use-after-free no componente XML do Chromium. Na prática, o navegador continua usando um pedaço de memória que já foi liberado, e um atacante consegue colocar ali o que quiser. O texto oficial diz que a falha permite a um atacante remoto executar código arbitrário dentro do sandbox por meio de uma página web preparada.

Os fatos verificáveis até 15/11/2026:

• Correção do Google: 9 de novembro, no Chrome 157.0.8103.50 (Linux) e 157.0.8103.50/.51 (Windows e macOS). O Chrome para Android recebeu a mesma versão no mesmo dia.
• Gravidade: alta. A falha foi relatada por um pesquisador anônimo em 6 de novembro, três dias antes do patch.
• Exploração: o Google confirma que existe exploit em uso real, mas não divulgou quem ataca nem como.
• KEV: a CISA incluiu a falha em 10 de novembro, com prazo de correção até 24 de novembro para as agências federais americanas.
• Contagem do ano: é o oitavo zero-day do Chrome de 2026, segundo a Qualys.

Uma ressalva honesta: análises de pesquisadores apontam que o código afetado fica no libxslt, a biblioteca que transforma documentos XML com folhas de estilo XSLT. O Google não confirmou esse detalhe publicamente, então trate como hipótese técnica, não como fato.

Por que o zero-day do Chrome vira problema da empresa inteira

O navegador é a porta de entrada mais usada da empresa. É nele que a equipe abre o e-mail, o ERP, o painel do banco, o Gerenciador de Negócios da Meta, o administrador do Moodle e o painel da hospedagem. Um zero-day do Chrome com execução de código encosta em tudo isso.

E tem um detalhe que muda a conta: o CVE-2026-125350 não é só do Chrome. A própria CISA escreve que a falha afeta "múltiplos navegadores que usam o Chromium". Isso inclui Microsoft Edge, Brave, Opera e Vivaldi. A empresa que padronizou o Edge e acha que o assunto não é com ela está tão exposta quanto quem usa Chrome.

Dentro do sandbox não quer dizer inofensivo

O sandbox é a caixa de isolamento onde o Chromium roda o conteúdo das páginas. Um código executado ali dentro, sozinho, não lê seus arquivos nem instala programas. Por isso ataques sérios costumam encadear duas falhas: uma para entrar no navegador e outra para sair do sandbox ou ganhar privilégio de administrador no sistema operacional.

Esse é o motivo de eu tratar todo zero-day do Chrome com urgência mesmo quando o texto oficial diz "dentro do sandbox". Você não sabe qual é a segunda peça que o atacante tem na mão. E, como mostro mais abaixo, a segunda peça às vezes aparece publicamente na mesma semana.

O patch só vale depois de reiniciar o navegador

Aqui está o ponto que quase todo mundo ignora. O Chrome baixa a atualização em segundo plano, mas a versão nova só entra em vigor quando o navegador fecha e abre de novo. Até lá, quem está rodando é a versão velha, com a falha.

Nos ambientes que atendo, o padrão se repete: o colaborador nunca fecha o navegador. Deixa 40 abas abertas, hiberna o notebook na sexta e volta na segunda com tudo do jeito que estava. O botão "Atualizar" fica amarelo, depois vermelho, e continua lá por dias. Quando um zero-day do Chrome sai num domingo, essa pessoa pode passar a semana inteira vulnerável com a atualização já baixada.

Como ver se uma máquina está esperando reinício

Três sinais rápidos:

1. Página "Sobre": abra chrome://settings/help (ou edge://settings/help, brave://settings/help). Se aparecer "Reiniciar para concluir a atualização", a correção ainda não está valendo.
2. Botão no canto superior direito: o aviso "Atualizar" colorido indica atualização pendente.
3. No Windows, arquivo new_chrome.exe: se ele existir na pasta de instalação do Chrome, há uma versão nova baixada esperando o próximo reinício.

Pedir no grupo da equipe "pessoal, reiniciem o navegador" funciona para metade das pessoas. A outra metade é a que você precisa alcançar, e para isso existe política.

Versões que corrigem o zero-day do Chrome no Edge, Brave e Opera

Cada navegador baseado em Chromium recebe a correção no próprio ritmo. A tabela abaixo reúne as versões confirmadas até 15/11/2026.

Navegador	Versão mínima com a correção	Data	Onde conferir
Google Chrome (Windows/macOS)	157.0.8103.50 ou .51	09/11/2026	chrome://settings/help
Google Chrome (Linux)	157.0.8103.50	09/11/2026	chrome://settings/help
Microsoft Edge (desktop)	157.0.4341.46	09/11/2026	edge://settings/help
Microsoft Edge (Android)	157.0.4341.53	11/11/2026	Play Store
Brave (desktop)	1.99.56	11/11/2026	brave://settings/help
Opera	140 (140.0.6074.17)	novembro/2026	opera://about

O Edge é o único com confirmação na fonte primária: as notas de segurança do Microsoft Edge dizem que a versão 157.0.4341.46 "contém uma correção" para o CVE-2026-125350. Para Brave e Opera, as versões vêm das notas de versão repercutidas pela imprensa especializada. O Opera 139, baseado no Chromium 155, continua vulnerável.

Se a sua empresa usa o canal Extended Stable do Chrome, que recebe novas funções a cada oito semanas, confirme no blog oficial de versões do Chrome que a correção chegou ao seu ramo antes de dar o assunto por encerrado.

Políticas de atualização forçada: como obrigar o reinício

Para cada novo zero-day do Chrome a boa notícia é a mesma: o Chrome e o Edge têm políticas corporativas feitas exatamente para isso. Elas são aplicadas por GPO (política de grupo do Windows), Intune, perfil de configuração no macOS ou arquivo JSON no Linux. Os nomes abaixo estão na lista oficial de políticas do Chrome Enterprise e o Edge tem RelaunchNotification, RelaunchNotificationPeriod e RelaunchWindow com os mesmos nomes.

Política	Valor que eu uso	O que faz
RelaunchNotification	2 (Obrigatório)	Mostra aviso recorrente e reinicia o navegador sozinho no fim do prazo. Com 1, só recomenda e o usuário pode adiar.
RelaunchNotificationPeriod	86400000 (24 h)	Prazo, em milissegundos, entre a atualização pendente e o reinício forçado. O padrão é 7 dias e o mínimo é 1 hora.
RelaunchWindow	início 12h00, duração 60 min	Empurra o reinício forçado para uma janela do dia, como o horário de almoço.
RelaunchFastIfOutdated	7 (dias)	Se a versão em uso estiver desatualizada há mais dias que o valor, o prazo cai para 2 horas. Existe desde o Chrome 137.

Dois detalhes que a documentação deixa claros e que tranquilizam a equipe: as abas são restauradas depois do reinício, e o aviso aparece de forma progressiva, mudando de cor ao passar um terço e dois terços do prazo.

Exemplo prático no Windows

Para quem administra poucas máquinas sem domínio, um arquivo .reg resolve o Chrome:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"RelaunchNotification"=dword:00000002
"RelaunchNotificationPeriod"=dword:05265c00

O valor 05265c00 em hexadecimal é 86.400.000, ou seja, 24 horas. Para o Edge, a chave é HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge. O Brave lê políticas do Chromium em HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave. Depois de aplicar, confira em chrome://policy se a política aparece como ativa.

E o Opera?

O Opera não oferece o mesmo nível de gestão corporativa que Chrome, Edge e Brave. Na minha leitura, a resposta mais segura é não permitir o Opera em máquinas que acessam sistemas da empresa. Navegador que você não consegue gerenciar é navegador que você não consegue garantir que reiniciou.

Inventário de versões: você sabe quais navegadores a equipe usa?

Quando sai um zero-day do Chrome, não dá para corrigir o que você não enxerga. Antes de qualquer política, faça o inventário. Em auditoria, é comum aparecer pelo menos um navegador que ninguém sabia que estava instalado, geralmente um Opera ou um Chrome antigo instalado no perfil do usuário, fora da pasta padrão.

Opções de inventário, da mais simples à mais completa

1. Planilha e verificação manual: serve até umas 10 máquinas. Cada pessoa abre a página "Sobre" e manda um print. Funciona uma vez, não escala.
2. PowerShell ou winget no Windows: winget list mostra Chrome, Edge, Brave e Opera instalados. Para a versão do Chrome: (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion.
3. macOS: defaults read "/Applications/Google Chrome.app/Contents/Info.plist" CFBundleShortVersionString.
4. Linux: apt policy google-chrome-stable ou o gerenciador de pacotes da distribuição.
5. Chrome Enterprise Core: o console gratuito do Google para gerenciar o Chrome. Mostra a versão de cada navegador inscrito, aplica políticas na nuvem e dispensa domínio Active Directory.
6. Intune ou ferramenta de RMM: para quem já tem Microsoft 365 com gestão de dispositivos ou um sistema de monitoramento remoto, o inventário de software sai de lá.

A armadilha do instalador por usuário

O Chrome pode ser instalado em AppData, dentro do perfil do usuário, sem pedir senha de administrador. Essa cópia escapa de parte das políticas de máquina e de inventários que olham só para Program Files. Se o seu inventário encontrar instalações por usuário, padronize a instalação corporativa (MSI) e remova as cópias soltas.

Quando não forçar o reinício (e as armadilhas mais comuns)

Atualização forçada mal configurada derruba trabalho, e trabalho derrubado vira pedido para desligar a política. Os erros que mais vejo:

• Prazo curto demais sem janela. Forçar reinício em 1 hora no meio de uma aula ao vivo no Moodle ou de uma chamada com cliente gera revolta. Use RelaunchWindow para empurrar o reinício para o almoço ou o fim do dia.
• Travar a versão com TargetVersionPrefix. Fixar a versão do Chrome para "não quebrar o sistema" deixa a empresa parada numa versão vulnerável. Se um sistema interno só funciona numa versão específica, o problema é o sistema, não o navegador.
• Desligar a atualização automática. Alguns técnicos desativam o serviço de atualização do Google para economizar banda. Num ano com oito zero-days no Chrome, isso é apostar contra a estatística.
• Esquecer o celular. O Chrome e o Edge para Android também receberam a correção. Quem acessa o painel administrativo pelo celular precisa atualizar pela loja de apps.
• Desativar XSLT às cegas. Como a falha está no componente XML, existe a tentação de desligar o XSLT pela política XSLTEnabled. O Google já tem cronograma para remover o XSLT do Chrome Stable a partir da versão 158. Mas alguns sistemas legados usam XSLT para exibir XML no navegador, como visualizadores de documento fiscal. Teste antes num grupo pequeno.

A regra que eu sigo: prazo de 24 horas para corrigir um zero-day do Chrome e 7 dias para atualização comum, sempre com janela de reinício definida.

SignDrop: a próxima ameaça a vigiar no Windows

Na mesma semana do patch do Chrome, um pesquisador publicou no GitHub o SignDrop, uma prova de conceito (PoC) de elevação local de privilégio no Windows. Elevação local de privilégio é quando um usuário comum, ou um programa rodando como ele, consegue virar SYSTEM, o nível mais alto do sistema.

O que se sabe, segundo a cobertura do The Hacker News e de outros veículos especializados:

• A técnica abusa do CLFS, o subsistema de log do Windows, combinado com a interface de atualização de assinaturas do Microsoft Defender.
• Os relatos citam Windows 11 25H2 e versões posteriores e o Windows Server 2025, em configurações específicas do modo de autenticação do CLFS.
• Não tem CVE nem correção da Microsoft até a data deste post.
• Não há registro de exploração em ataques reais.

Não vou exagerar: é uma PoC, não uma campanha. O motivo de vigiar é a lógica que expliquei antes. Um zero-day do Chrome dá execução de código dentro do sandbox. Uma elevação local de privilégio é o tipo de peça que transforma isso em controle total da máquina. Não há indício de que as duas tenham sido usadas juntas, mas código público costuma ser aproveitado rápido.

O que fazer agora, sem pânico:

1. Não desative o Defender para "fugir" da falha. Você troca um risco teórico por um risco real.
2. Revise quem é administrador local. Usuário comum sem privilégio de administrador limita o estrago de qualquer ataque.
3. Acompanhe o Patch Tuesday de 8 de dezembro de 2026 e o guia de atualizações de segurança da Microsoft para ver se aparece um CVE do CLFS.

Um processo de resposta para o próximo zero-day do Chrome

Não haverá só um. Com oito em 2026, a média passa de um a cada seis semanas. Vale ter um processo curto e repetível, em vez de improvisar a cada notícia. Para decidir o que corrigir primeiro quando tudo chega junto, eu explico o método em como priorizar vulnerabilidades.

Checklist de 48 horas

1. Hora 0 a 2: confirmar o zero-day do Chrome numa fonte primária (blog de versões do Chrome, notas do Edge, catálogo KEV).
2. Hora 2 a 4: rodar o inventário e listar as máquinas abaixo da versão corrigida, por navegador.
3. Hora 4: reduzir temporariamente RelaunchNotificationPeriod para 24 horas ou menos nas máquinas que acessam sistemas críticos.
4. Hora 24: conferir de novo o inventário e tratar quem ficou para trás um a um.
5. Hora 48: registrar o que travou (máquina desligada, usuário sem política, navegador fora do padrão) e corrigir a causa.

Esse ritmo vai ficar mais apertado. Ferramentas de IA estão acelerando a descoberta de falhas dos dois lados, como contei em vulnerabilidades descobertas por IA. E reiniciar o navegador não substitui as outras camadas: autenticação em dois fatores continua sendo o que segura uma sessão roubada.

Como a Agathas Web resolve isso

Eu opero servidores Linux, ambientes Moodle, hospedagem gerenciada e integrações com a API oficial do WhatsApp desde 2008. Boa parte dos incidentes que já investiguei não começou no servidor. Começou numa estação de trabalho, num navegador desatualizado de quem tinha acesso administrativo. Por isso a gestão de navegadores entra no diagnóstico da nossa consultoria em tecnologia.

Na prática, o que está incluso:

• Inventário completo dos navegadores e versões em uso, incluindo instalações por usuário e navegadores fora do padrão.
• Política de atualização por perfil de risco: prazo de reinício, janela de horário e regras diferentes para quem acessa painéis administrativos, financeiro e dados de alunos.
• Aplicação das políticas por GPO, Intune ou Chrome Enterprise Core, conforme a estrutura que a empresa já tem.
• Revisão de privilégios: quem é administrador local, quem acessa o quê e onde a autenticação em dois fatores está faltando.
• Processo de resposta a zero-day documentado, para a equipe interna executar sem depender de mim na próxima vez.

Como funciona: começa com uma conversa gratuita de 30 a 60 minutos para entender o cenário. Depois vem o mergulho técnico com acesso só de leitura, sem parar a operação, e a entrega do diagnóstico com prioridades e ganhos rápidos. Quem conduz é sênior, não um estagiário. Para começar, é só agendar o diagnóstico de consultoria e contar quantas máquinas e sistemas críticos a empresa tem.

Conclusão: atualizar é fácil, garantir que atualizou é o trabalho

O zero-day do Chrome de novembro já tem correção, e o Edge, o Brave e o Opera também já corrigiram. O risco que sobra não é técnico, é operacional: navegadores que baixaram o patch e não reiniciaram, cópias esquecidas no perfil do usuário e celulares que ninguém conferiu.

Os três passos que resolvem a maior parte do problema cabem numa tarde. Faça o inventário, aplique RelaunchNotification com um prazo curto e uma janela de horário, e padronize os navegadores permitidos. Enquanto isso, acompanhe o SignDrop até a Microsoft se posicionar.

Se a sua empresa não tem quem faça isso internamente, ou se você quer uma segunda opinião sobre o que já está configurado, a consultoria da Agathas Web entrega o diagnóstico e o plano. O próximo zero-day do Chrome vai chegar. A diferença é se ele encontra a sua equipe com o navegador já reiniciado.