3 pontos por GN⁺ 2026-02-20 | 2 comentários | Compartilhar no WhatsApp
  • O Google lançou uma atualização do canal estável da versão desktop do Chrome, incluindo uma vulnerabilidade zero-day relacionada a CSS identificada como CVE-2026-2441
  • O Google confirmou que essa vulnerabilidade está sendo explorada em ataques reais (in the wild), e os usuários devem atualizar imediatamente para a versão mais recente para minimizar os riscos de segurança
  • A atualização está sendo distribuída gradualmente para o Chrome no Windows, macOS e Linux

Visão geral da atualização do canal estável do Chrome

  • O Google anunciou uma atualização do canal estável (Stable Channel) do Chrome para desktop
    • Windows/macOS: 145.0.7632.75/76, Linux: 144.0.7559.75
    • A atualização está sendo distribuída para as plataformas Windows, macOS e Linux
    • A aplicação ocorrerá gradualmente por meio de atualização automática

Vulnerabilidade de segurança CVE-2026-2441

  • Esta versão inclui a vulnerabilidade de segurança designada como CVE-2026-2441
    • Confirmada como uma vulnerabilidade zero-day que ocorre durante o processamento de CSS
    • O Google declarou que essa vulnerabilidade está sendo explorada em ataques reais

Ações recomendadas para usuários

  • O Google recomenda que todos os usuários atualizem imediatamente o Chrome para a versão mais recente
    • Se a atualização automática ainda não tiver sido concluída, é possível atualizar manualmente
    • Ao aplicar a versão mais recente, é possível ficar protegido contra essa vulnerabilidade

Distribuição e suporte

  • A atualização está sendo distribuída gradualmente por meio do canal estável
    • Para alguns usuários, pode levar algum tempo até que a atualização seja aplicada
  • A equipe do Chrome continua trabalhando em melhorias adicionais de segurança e estabilidade

2 comentários

 
xguru 2026-02-20

Atualizei, mas no Mac a versão já subiu até a 145.0.7632.110.

É uma vulnerabilidade em que ocorre um Use-After-Free ao processar fontes dentro do CSS, continuando a usar um endereço invalidado, o que pode até permitir o comprometimento do sistema, então basta apenas abrir um site para que isso seja possível. Disseram até que já havia quem estivesse explorando essa vulnerabilidade.

 
GN⁺ 2026-02-20
Comentários do Hacker News
  • Foi descoberta uma vulnerabilidade use-after-free em CSS no Google Chromium
    É um problema em que um invasor remoto pode causar corrupção de heap por meio de uma página HTML maliciosa, podendo afetar não só o Chrome, mas também navegadores baseados em Chromium como Edge e Opera
    Parece ser um problema bem sério, e fiquei curioso sobre o valor do bug bounty que o pesquisador recebeu

    • Provavelmente não passou de 20 mil dólares
      Considerando o esforço necessário para encontrar uma vulnerabilidade grave e criar um exploit reproduzível, a recompensa parece baixa demais
    • Parece que o Firefox não foi afetado
    • Aplicativos Electron também podem ser afetados
      porque a maioria fixa a versão do Chrome (pinning)
    • Para virar um ataque realmente significativo, seria necessário um sandbox escape
      Mas o fato de ter sido “detectado em atividade real” pode significar que já existe uma cadeia de ataque incluindo também o sandbox escape
    • Acho problemático que ainda se trate use-after-free como algo menor
      É vergonhoso não conseguir eliminar esse tipo de bug em linguagens de sistema no século 21
  • Parece provável que ainda existam bugs assim escondidos nos cantos obscuros do codebase do Chromium/Blink
    Em um projeto tão central, deveria haver uma equipe dedicada validando continuamente todo o código
    Acho que reforçar a segurança assim é um investimento muito mais valioso do que recursos como integração com geladeira inteligente

    • O Chromium já faz fuzzing agressivo
      Com um fuzzer forte o bastante, imagino que quase não haja áreas inacessíveis
  • A expressão “Use after free in CSS” é meio engraçada

    • Provavelmente se refere ao parser de CSS ou ao CSSOM
    • Fiquei curioso sobre por que usaram essa expressão
  • Não está muito claro para mim qual é o impacto real dessa vulnerabilidade
    Sem escape do sandbox ou XSS, ela parece quase inofensiva, mas olhando o código PoC,
    dizem que são possíveis vários ataques dentro do processo do renderizador, como execução arbitrária de código, vazamento de informações, roubo de cookies e sessão, manipulação do DOM e keylogging

    • Ataques a navegadores normalmente acontecem em duas etapas
      Primeiro, um bug no renderizador dá execução arbitrária de código dentro do sandbox; depois, um sandbox escape concede acesso total ao sistema
      Esta vulnerabilidade corresponde à primeira etapa, e se já foi usada em ataques reais, é bem provável que a segunda etapa também exista
  • Ainda é surpreendente que vulnerabilidades de memória como essa continuem aparecendo
    Fico pensando se não existem ferramentas para gerar binários verificados, como nas linguagens memory-safe
    O CSS também ficou mais complexo, com variáveis, escopo e recursos de pré-processador, então talvez até fosse preciso uma extensão tipo “no-style”, como existe “no-script”
    Fico curioso se este relatório trata de um erro simples ou de uma cadeia de ataque em várias etapas

    • Essas ferramentas até existem, mas o Chromium já usa todos os sanitizers e fuzzing possíveis
      O problema é a cobertura de testes. O codebase é enorme demais para garantir cobertura completa, e é nessas lacunas que surgem vulnerabilidades assim
    • “no-style” é inviável na prática
      CSS é central para a web, e removê-lo quebraria quase todos os sites
      Em vez disso, a alternativa pode ser a execução isolada (isolation)
      Se a sessão do navegador for transmitida de um servidor remoto, mesmo que um zero-day seja explorado, apenas a instância remota será afetada, e não a máquina local
      Não é perfeito, mas é uma estratégia de defesa em profundidade para reduzir a superfície de ataque
  • Na lista de ferramentas de segurança usadas pela equipe do Chromium, foram citados AddressSanitizer, MemorySanitizer, libFuzzer etc., e é interessante que o OSS-Fuzz não tenha aparecido

    • OSS-Fuzz não é um fuzzer em si, mas uma plataforma que integra e usa os sanitizers e engines de fuzzing mencionados acima
  • Quero ver o código PoC depois que o patch for distribuído

  • Surgiu a piada de que o Chromium deveria ser reescrito em Rust

    • Na prática, partes do motor Blink já foram reescritas em C++ com GC para buscar um efeito parecido
    • Também houve quem dissesse que seria melhor investir no motor Servo da Mozilla
  • Ao procurar o CVE, vi que existe uma página do issue, mas
    ela aparece como “Access is denied”
    Parece estar em estado privado, acessível apenas com login