noticias

Chrome corrige 42 falhas de segurança três são críticas e permitem escapar da proteção do navegador

**Categoria editorial:** Segurança Digital / Software

**Linha fina:** Atualização do Chrome 153 fecha vulnerabilidades em WebGL, memória, extensões, V8 e outros componentes. Não há evidência de exploração ativa, mas atualizar o navegador deve ser tratado como prioridade.

**Meta description:** Google corrige 42 vulnerabilidades no Chrome, incluindo três falhas críticas capazes de permitir ataques por páginas maliciosas. Veja como atualizar.

**Slug:** `chrome-42-vulnerabilidades-tres-falhas-criticas-atualizacao`

**Palavra-chave principal:** vulnerabilidades do Google Chrome

Matéria completa

Se você utiliza o Google Chrome e pertence ao grupo de pessoas que mantém cinquenta abas abertas durante semanas e considera reiniciar o navegador uma agressão pessoal, talvez seja uma boa hora para abrir uma exceção.

O Google liberou uma das atualizações de segurança mais volumosas recentes do Chrome, corrigindo **42 vulnerabilidades** no navegador.

Três delas receberam classificação **crítica**, o nível mais elevado utilizado pelo projeto Chromium para falhas capazes de produzir consequências severas.

A atualização está sendo distribuída gradualmente para Windows, macOS, Linux e Android. No desktop, a versão corrigida é a **153.0.8010.47/.48 no Windows e macOS e 153.0.8010.47 no Linux**. O Android recebeu a compilação 153.0.8010.47 com as mesmas correções de segurança correspondentes.

A boa notícia é importante: até agora, não existem evidências públicas consolidadas de que essas três vulnerabilidades críticas estejam sendo exploradas em ataques reais.

A má notícia é igualmente importante.

Agora que as correções foram publicadas, começa uma corrida bastante conhecida da segurança digital.

Quando uma correção também revela onde estava o problema

Atualizações de segurança possuem uma característica curiosa.

Elas fecham vulnerabilidades, mas também informam ao mundo que aquelas vulnerabilidades existiam.

Pesquisadores, empresas de segurança e criminosos podem comparar versões anteriores e posteriores do software tentando descobrir exatamente aquilo que foi modificado.

É o chamado *patch diffing*.

O atacante não precisa necessariamente descobrir uma vulnerabilidade do zero.

Pode estudar a correção publicada e trabalhar de trás para frente até compreender o problema que ela resolve.

Por essa razão, o Google restringe temporariamente alguns detalhes técnicos das vulnerabilidades até que uma parcela significativa dos usuários tenha recebido a atualização.

Existe uma janela delicada entre a publicação do patch e sua instalação.

Quanto mais gente permanece na versão antiga, maior o número de computadores potencialmente expostos.

Três falhas merecem atenção especial

As vulnerabilidades críticas são identificadas como **CVE-2026-91726, CVE-2026-91721 e CVE-2026-91749**.

Elas atingem áreas diferentes do Chrome.

A CVE-2026-91726 envolve uma leitura fora dos limites de memória no **WebGL**, tecnologia utilizada pelos navegadores para renderizar gráficos acelerados por hardware diretamente nas páginas.

A CVE-2026-91721 é uma vulnerabilidade do tipo **use-after-free** em componentes internos do navegador.

Já a CVE-2026-91749 também envolve *use-after-free*, desta vez associado aos **Workers**, mecanismo que permite executar tarefas JavaScript paralelamente ao fluxo principal de uma página.

Os nomes parecem pertencer exclusivamente ao universo dos desenvolvedores.

As consequências não.

O que é um use-after-free?

Programas reservam e liberam áreas da memória constantemente.

Imagine que determinado componente cria um objeto, utiliza aquela região de memória e depois informa ao sistema que ela pode ser liberada.

A partir daquele momento, o software não deveria continuar utilizando aquele endereço.

Uma vulnerabilidade *use-after-free* acontece quando alguma parte do programa mantém uma referência para essa memória e tenta utilizá-la novamente depois de sua liberação.

Um atacante pode tentar manipular aquilo que passa a ocupar aquele espaço.

Dependendo das circunstâncias e das proteções existentes, o resultado pode variar de um simples travamento até corrupção de memória e execução de código controlado pelo invasor.

É justamente por esse potencial que falhas desse tipo aparecem regularmente entre as vulnerabilidades mais preocupantes de navegadores.

E por que WebGL também chama atenção?

WebGL permite que sites utilizem recursos gráficos avançados do computador através do navegador.

Jogos, visualizações tridimensionais, aplicações de engenharia, mapas e inúmeras experiências gráficas dependem dessa tecnologia.

Para entregar esse desempenho, existe interação entre navegador, processamento gráfico, memória e drivers.

É uma área complexa.

E complexidade é terreno fértil para erros de segurança.

A vulnerabilidade crítica localizada nesse componente permite leitura de memória fora dos limites esperados.

Na prática, o programa tenta acessar informação além da região que deveria estar disponível para determinada operação.

Esse comportamento pode permitir exposição de dados que deveriam estar isolados e, combinado com outras vulnerabilidades, contribuir para ataques mais sofisticados.

A sandbox existe justamente para tornar esses ataques mais difíceis

O Chrome utiliza há anos uma arquitetura de isolamento conhecida como **sandbox**.

A ideia é relativamente simples.

Uma página da internet não deveria receber liberdade para interagir diretamente com todo o sistema operacional.

Ela funciona dentro de um ambiente fortemente limitado.

Se algo der errado dentro de uma aba, o estrago deveria permanecer confinado.

Pense em uma sala blindada.

Um código malicioso pode estar dentro dela, mas existem paredes impedindo que alcance o restante da máquina.

O problema aparece quando uma vulnerabilidade possibilita atravessar essas paredes.

Algumas das falhas corrigidas nesta atualização podem, em determinadas condições, permitir execução de código além das barreiras originalmente previstas pelo navegador.

É por isso que elas receberam atenção especial.

Uma página pode realmente atacar o navegador?

Sim.

Essa é uma das razões pelas quais vulnerabilidades de navegadores recebem tanta atenção de pesquisadores de segurança.

O navegador precisa interpretar permanentemente conteúdo produzido por terceiros.

HTML.

JavaScript.

Imagens.

Vídeos.

Fontes.

WebGL.

Arquivos.

Extensões.

Protocolos de rede.

Cada site visitado entrega dados que precisam ser processados pelo software.

Um atacante pode construir deliberadamente uma página destinada não a mostrar conteúdo, mas a provocar uma condição inesperada no navegador.

Se existir uma falha adequada, simplesmente carregar determinado conteúdo pode ser suficiente para iniciar a exploração.

Isso não significa que qualquer site possa assumir instantaneamente o computador.

Navegadores modernos possuem várias camadas de defesa.

Mas explica por que manter versões antigas é particularmente arriscado.

O navegador é provavelmente um dos softwares mais expostos de qualquer computador.

O número 42 assusta, mas precisa ser colocado em contexto

Encontrar dezenas de vulnerabilidades não significa necessariamente que o Chrome tenha se tornado repentinamente inseguro.

Existe um paradoxo importante na segurança de software.

Um projeto no qual muitas vulnerabilidades são encontradas pode simplesmente estar sendo investigado com muita intensidade.

O Chrome possui uma enorme equipe interna de segurança, ferramentas automatizadas, programas de recompensas e pesquisadores independentes procurando falhas continuamente.

Das 42 correções desta atualização, **26 vulnerabilidades foram identificadas internamente**, enquanto outras **16 foram relatadas por pesquisadores externos**.

Isso importa.

Encontrar uma falha antes de criminosos conseguirem utilizá-la é exatamente o funcionamento desejado de um programa de segurança.

A questão relevante não é simplesmente quantas vulnerabilidades foram encontradas.

É **quanto tempo existe entre descobrir, corrigir e distribuir a correção aos usuários**.

E o Google está tentando diminuir justamente esse intervalo

Desde o Chrome 153, o Google passou a acelerar o ciclo de versões estáveis do navegador.

Em vez de uma nova versão principal aproximadamente a cada quatro semanas, o Chrome começa a trabalhar em ciclos de **duas semanas**.

Segurança está entre as principais razões dessa mudança.

Existe um conceito conhecido como **N-day vulnerability**.

É a vulnerabilidade que já possui uma correção conhecida, mas continua presente em sistemas ainda não atualizados.

Ela deixa de ser necessariamente um segredo.

O problema foi identificado.

O código foi modificado.

A atualização existe.

Mas milhões de computadores podem continuar executando a versão vulnerável.

Quanto menor o intervalo de distribuição, menor a janela disponível para que atacantes transformem essas informações em ataques funcionais.

Atualização automática ajuda — mas existe um detalhe

Chrome normalmente baixa suas atualizações automaticamente em segundo plano.

Esse comportamento criou uma excelente camada de proteção para usuários que sequer sabem qual versão do navegador utilizam.

Só existe um detalhe.

**A atualização frequentemente precisa que o navegador seja reiniciado para entrar efetivamente em funcionamento.**

E é aqui que aparece a velha coleção de abas abertas.

O Chrome pode já ter baixado a correção e permanecer esperando que você feche e abra o navegador.

Portanto, quem mantém o programa aberto por muitos dias pode permanecer durante algum tempo utilizando uma versão anterior apesar de a atualização já estar disponível.

Como conferir agora

No computador, o procedimento é simples.

Abra o menu de três pontos no canto superior direito.

Entre em **Ajuda** e depois em **Sobre o Google Chrome**.

O navegador verificará automaticamente se existe uma versão mais recente disponível.

Depois da instalação, poderá aparecer a opção para reiniciar o Chrome.

No Windows e macOS, usuários do canal estável afetado por esta atualização devem receber as versões 153.0.8010.47 ou 153.0.8010.48.

No Linux, a compilação correspondente é 153.0.8010.47, embora o gerenciamento da atualização também possa depender do sistema de pacotes utilizado pela distribuição.

No Android, a versão 153.0.8010.47 incorpora as correções correspondentes e está sendo distribuída pela Google Play.

O fundamental não é decorar o número.

É verificar se existe atualização pendente.

Empresas precisam prestar ainda mais atenção

Em computadores pessoais, alguns dias de atraso já representam exposição desnecessária.

Em redes corporativas, o problema aumenta.

Uma organização pode administrar centenas ou milhares de máquinas.

Algumas dependem de políticas próprias de atualização, compatibilidade com sistemas legados e ciclos internos de homologação.

Existe uma razão para isso.

Atualizar milhares de navegadores sem testes também pode criar problemas operacionais.

Mas segurança sempre envolve um equilíbrio entre estabilidade e exposição.

Quando existem vulnerabilidades classificadas como críticas em um software permanentemente conectado à internet, esse intervalo precisa ser tratado com bastante cuidado.

Administradores devem verificar versões implantadas, políticas de atualização e máquinas que eventualmente ficaram fora do ciclo automático.

E usuários de Chromium?

Chrome utiliza o projeto Chromium como base.

Edge, Brave, Opera, Vivaldi e diversos outros navegadores compartilham partes importantes dessa arquitetura.

Isso significa que vulnerabilidades encontradas em componentes do Chromium podem atingir outros navegadores derivados dependendo exatamente de qual código está envolvido.

Mas existe uma diferença fundamental.

A correção publicada pelo Google não significa automaticamente que todos os navegadores baseados em Chromium estejam atualizados naquele mesmo instante.

Cada fornecedor possui seu próprio ciclo de distribuição.

Quem utiliza outro navegador baseado em Chromium também deve acompanhar suas atualizações de segurança.

Ser “baseado no Chrome” não significa receber cada correção simultaneamente ao Chrome.

O fato de não haver ataque conhecido não é motivo para esperar

Essa é talvez a parte mais importante da notícia.

Até o momento, não existe indicação pública consolidada de exploração ativa das três vulnerabilidades críticas.

Excelente.

É exatamente nesse momento que queremos atualizar.

Esperar aparecer a notícia de que criminosos começaram a explorar uma vulnerabilidade para então instalar a correção inverte completamente a lógica da segurança.

Atualizações existem para fechar a porta **antes** de alguém tentar entrar.

Depois que uma falha começa a aparecer em campanhas reais, a situação muda de vulnerabilidade potencial para ameaça operacional.

E navegadores possuem um ingrediente adicional: bilhões de instalações tornam qualquer falha relevante extremamente interessante para atacantes.

Análise da equipe

É fácil olhar para a notícia de que o Chrome corrigiu 42 vulnerabilidades e concluir que existe algo terrivelmente errado com o navegador.

A leitura tecnicamente mais interessante é outra.

Softwares modernos são absurdamente complexos.

O Chromium possui dezenas de milhões de linhas de código, interage com sistema operacional, GPU, rede, memória, extensões, codecs e uma quantidade enorme de padrões da web.

Esperar que um projeto dessa escala jamais contenha vulnerabilidades seria pouco realista.

A segurança moderna funciona por camadas.

Primeiro, tenta-se escrever código seguro.

Depois entram revisões.

Testes automatizados.

Fuzzing.

Sandbox.

Isolamento de processos.

Pesquisadores internos.

Programas de recompensa.

Pesquisadores externos.

Atualizações automáticas.

Cada camada existe porque a anterior pode falhar.

O dado que merece acompanhamento é justamente a velocidade dessa cadeia.

As três vulnerabilidades críticas foram reportadas no início de setembro e receberam correções distribuídas ainda no mesmo mês.

Ao mesmo tempo, o Google está reduzindo seu ciclo de versões para diminuir o intervalo entre uma correção entrar no código e chegar efetivamente aos computadores dos usuários.

É uma mudança pouco visível.

Talvez menos interessante comercialmente do que anunciar uma nova inteligência artificial dentro do navegador.

Mas, para a segurança de quem passa boa parte do dia conectado ao mundo através dele, pode ser muito mais importante.

A recomendação da PixBugTech, portanto, é excepcionalmente simples.

Abra o Chrome.

Entre em **Ajuda → Sobre o Google Chrome**.

Deixe atualizar.

E, desta vez, talvez seja uma boa ideia permitir que aquelas 47 abas finalmente sobrevivam a uma reinicialização.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis