CVE-2019-5825
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Falha de escrita fora dos limites de memória (out-of-bounds write) no motor JavaScript V8 do Google Chrome, explorável por uma página HTML maliciosa sem necessidade de autenticação, apenas induzindo a vítima a visitá-la. Está no catálogo KEV da CISA com exploração confirmada em campo, mas o CVSS de 6,5 reflete uma pontuação conservadora (só impacto em disponibilidade) — na prática, corrupção de heap em motor JS costuma ser primitivo de RCE quando encadeada com outras falhas (sandbox escape).
Detalhamento técnico
A falha (CWE-787) está no V8, o motor JavaScript do Chromium, e foi catalogada internamente como bug 941743. O PoC público referenciado (PacketStorm) aponta para corrupção envolvendo Array.prototype.map em builds do Chrome 72/73, um padrão clássico de bug em V8: o motor otimiza chamadas de métodos de array assumindo que tamanho, layout de elementos (elements kind) e ponteiro do backing store permanecem estáveis durante a execução do callback, mas o próprio callback JavaScript pode alterar o array (redimensionar, trocar para outro elements kind, ou desalocar) enquanto o motor ainda opera com os valores antigos cacheados.
O atacante controla o conteúdo do array, a lógica do callback passado ao método e o timing das mutações feitas dentro dele. Isso é suficiente para fazer o V8 escrever dados em um offset que já não corresponde mais ao buffer real alocado, corrompendo heap adjacente — memória gerenciada pelo próprio V8, não da aplicação hospedeira.
A equipe do Chrome creditou a descoberta a pesquisadores do Tencent Keen Security Lab (Gengming Liu, Jianyu Chen, Zhen Feng, Jessica Liu), reportado em 13/03/2019 junto com outro bug relacionado (CVE-2019-5826, use-after-free em IndexedDB) — os dois foram corrigidos na mesma leva e pagos com bounty combinado de US$ 25.633,70. Isso sugere que fazem parte da mesma cadeia de exploração demonstrada pelos pesquisadores, embora o advisory do Google não detalhe a mecânica exata do exploit.
Como é explorada
Vetor é web: a vítima precisa visitar (ou ser redirecionada a) uma página HTML controlada pelo atacante que contenha JavaScript malicioso — user interaction é exigida (UI:R no vetor CVSS), mas não é preciso login, permissão elevada ou configuração não padrão do navegador. Isso torna o alcance amplo: qualquer usuário do Chrome desktop na faixa de versões vulneráveis é alvo potencial.
Sozinha, a falha corrompe heap do processo de renderização e o CVSS reportado (impacto só em disponibilidade) é compatível com um resultado de crash/DoS controlado. Para virar execução de código teria de ser encadeada com uma segunda falha de sandbox escape do renderer para o processo browser — algo comum em campanhas reais contra Chrome dessa época, mas não confirmado neste registro específico. Existe módulo Metasploit e PoC pública (o writeup do PacketStorm sobre corrupção via Array.map em Chrome 72/73), o que reduz a barreira de reprodução para quem já tem o binário vulnerável em mãos.
A CISA incluiu a CVE no catálogo KEV (adicionada em 08/06/2022, com prazo de correção em 22/06/2022), confirmando exploração ativa observada — mas não fornece detalhes de campanha, alvo ou ator. O ecossistema afetado não se limita ao Chrome: qualquer navegador baseado em Chromium com V8 na mesma linha de código (Microsoft Edge, Opera, etc., conforme nota da própria CISA) herda o mesmo bug enquanto não atualizado.
Versões
Como se proteger
Atualizar o Chrome para a versão corrigida é a única mitigação real. O advisory oficial do Google (descrição da CVE) indica correção nas versões a partir de 73.0.3683.86; o changelog do canal estável cita a correção como retroativa, mencionada apenas na atualização de 30/04/2019 (74.0.3729.131) por ter sido "mistakenly omitted" das notas de lançamento anteriores — ou seja, o fix já estava presente antes dessa nota, na build 73.0.3683.86 conforme a descrição oficial da CVE.
Não há paliativo funcional: desabilitar JavaScript quebra a usabilidade da maioria dos sites e não é uma mitigação suportada nem recomendada como controle formal; extensões de bloqueio de script reduzem superfície mas não eliminam o risco em sites permitidos. Não existe flag de linha de comando ou política de enterprise documentada que neutralize especificamente esta falha no V8 — a correção está no binário do motor.
Como a CVE está em KEV, organizações sob diretivas de vulnerability management (BOD 22-01 e equivalentes) devem tratá-la como prioridade de patch imediato, independentemente do CVSS moderado. Verificar se há navegadores baseados em Chromium desatualizados (Edge legado, Opera, Brave, etc.) que compartilhem a mesma linha vulnerável do V8, já que a correção precisa se propagar para cada fork separadamente.
Como detectar
Não há assinatura de rede ou padrão de log confiável e público para detectar tentativas de exploração desta falha especificamente — o vetor é uma página HTML/JS arbitrária servida por HTTP(S) comum, sem payload de rede distintivo documentado nas fontes disponíveis. Em ambientes com telemetria de endpoint, crashes recorrentes do processo de renderização do Chrome (renderer) associados a visitas a sites incomuns, ou crash reports internos do Chrome com stack trace envolvendo V8/Array em builds anteriores a 73.0.3683.86, são o sinal mais próximo disponível — mas não constituem detecção confiável de exploração deliberada versus falha acidental.