O Próximo Zero-Day do Chrome Segue para Bruxelas

Seis Zero-Days em Oito Meses, Uma Recompensa de Mil Dólares

A equipa do Chrome da Google lançou as versões 152.0.7977.82 e .83 para Windows e macOS, e 152.0.7977.82 para Linux, a 3 e 4 de setembro de 2026, corrigindo o CVE-2026-85046, uma falha de confusão de tipos no motor V8 de JavaScript e WebAssembly que a Google confirmou já estar a ser explorada em ambiente real. A falha permite que uma página web preparada engane o compilador do V8 e conceda a um atacante acesso arbitrário de leitura e escrita à heap do navegador, abrindo um caminho para a execução remota de código dentro da sandbox do Chrome. O investigador Salvatore Gulizia reportou a falha a 4 de agosto de 2026 e recebeu uma recompensa de 1.000 dólares; a Google reteve os detalhes técnicos até a correção chegar à maioria dos utilizadores, prática habitual perante uma falha explorada ativamente. Este é o sexto zero-day do Chrome explorado ativamente corrigido em 2026, e todos eles obtiveram uma pontuação CVSS de 8.8 e exigiram uma correção de emergência fora do ciclo normal, em vez de aguardar pelo calendário habitual de lançamentos do Chrome.

Oito Dias Antes de o Relógio Começar a Contar

A própria cronologia da Google mostra a diferença que importa: divulgou e corrigiu o CVE-2026-85046 a 3 e 4 de setembro, oito dias antes da data de entrada em vigor do artigo do Cyber Resilience Act da UE que teria exigido uma notificação formal exatamente deste tipo de evento. A partir de 11 de setembro de 2026, o artigo 14 trata software como o Chrome como um produto com elementos digitais, e assim que um fornecedor toma conhecimento de que uma vulnerabilidade está a ser explorada ativamente, tem de enviar um alerta rápido a um ponto de contacto nacional e à ENISA, a agência de cibersegurança da UE, no prazo de 24 horas, uma notificação mais completa no prazo de 72 horas, e um relatório final no prazo de 14 dias após a correção ficar disponível. Se a Google tivesse descoberto e divulgado a mesma falha a 12 de setembro em vez de a 3 de setembro, a sequência idêntica - um investigador a reportar uma falha no V8, a Google a confirmar exploração em ambiente real, e a Google a lançar uma correção de emergência - teria passado a ser o primeiro teste real do Cyber Resilience Act, em vez de um aviso de rotina. Seis zero-days do Chrome explorados ao longo de oito meses em 2026 tornam um sétimo, que chegue depois de o diploma já ter poder efetivo, uma questão de quando e não de se.

A Regra de Decisão para Quem Gere a Política de Correções

A lição prática para qualquer empresa na UE não é esperar por uma notificação regulatória para tomar conhecimento do próximo zero-day do Chrome, porque as próprias notas de lançamento da Google referiram que as versões corrigidas continuariam a ser distribuídas nos dias e semanas seguintes mesmo depois de a correção já existir, o que significa que é a velocidade da atualização automática, e não a da divulgação, que decide durante quanto tempo uma frota de computadores portáteis permanece exposta. Quem gere a política de endpoints deve tratar o sexto zero-day deste ano como uma taxa de base, não como uma anomalia: com seis incidentes a surgir aproximadamente a cada seis a sete semanas ao longo de 2026, a postura correta é um processo permanente que compara semanalmente as versões do Chrome instaladas com a versão estável mais recente, em vez de confiar que cada máquina se atualiza sozinha conforme previsto. Assim que o relógio do Cyber Resilience Act começar a contar, uma equipa de TI sediada na UE ganha também um novo sinal a acompanhar: o histórico de notificações de um fornecedor à ENISA torna-se um indicador aproximado da frequência com que os seus produtos são efetivamente atacados, mais concreto do que uma afirmação de marketing sobre segurança de nível empresarial, e vale a pena verificá-lo antes de uma renovação, não depois de um incidente.

Leia a seguir: SonicWall SMA1000: falhas já exploradas ativamente  |  Equipas De Segurança Da UE Sem Voz Sobre A Astra