Cadeia de zero-days do «patch gap» — vulnerabilidades já corrigidas no Chromium e ainda não corrigidas no Chrome foram usadas em comum por vários grupos de espionagem em 1 semana
Constatou-se, pela observação da Volexity, que a cadeia de ataque BlueMoon, que encadeia a fuga do sandbox V8 do Chrome e o abuso do ALPC do Windows, tinha sido usada em comum por pelo menos vários clusters de origem chinesa. Organiza-se aqui o perigo do «patch gap»: a correção entrou no Chromium, mas ainda não se refletia no Chrome estável.
Este artigo foi traduzido por máquina.
Em 15 de setembro de 2026, a Volexity relatou que um cluster de ameaças descrito como de origem chinesa (UTA0560) usou, num ataque por e-mail direcionado contra várias NGO em 1 de setembro, uma cadeia de ataque que encadeia vulnerabilidades do Google Chrome e do Microsoft Windows (a que chama BlueMoon). O link no e-mail explorou um XSS refletido num site de uma universidade dos Estados Unidos para conduzir à infraestrutura controlada pelo atacante, onde se desenrola um exploit em 3 etapas. Com CVE-2026-85046 obtém leitura e escrita arbitrárias dentro do sandbox V8, com CVE-2026-87491 escapa do sandbox do navegador e, por fim, com CVE-2026-85880 explora o Advanced Local Procedure Call (ALPC) do Windows para injeção de código no processo do Chrome e execução arbitrária de código. A Volexity também apontou que o atacante filtrava de modo a excluir tudo o que não fosse Chrome no Windows (conforme a cobertura da Volexity / The Hacker News).
Análise (separada do relato factual): o que merece nota é o «uso em comum» da mesma cadeia de exploit. Na observação da Volexity, por volta do momento em que UTA0560 implantou o backdoor em JavaScript chamado GRIMWEDGE (um ponto de apoio inicial, de capacidade moderada, que recebe comandos por eval a partir do C2), JungleBamboo (APT31) também implantou o loader SUPERSTOMP com a mesma cadeia e, no fim, introduziu a extensão de Chrome para furto de informação LONGTALE, que se fazia passar por uma extensão legítima do Google Gemini. As manchetes relataram que «4 grupos de espionagem usaram o mesmo kit em 1 semana» (The Hacker News), e indica-se a possibilidade de que quem desenvolveu tenha reconstruído o exploit a partir do diff do código-fonte do Chromium e o tenha fornecido a vários clusters. Uma estrutura em que o exploit circula como um «produto» significa que a generalização da superfície de ataque é rápida.
O aspecto tecnicamente mais interessante é o patch gap. As correções das 2 vulnerabilidades do Chrome (CVE-2026-85046 / CVE-2026-87491) já tinham sido objeto de commit no código aberto do Chromium, mas ainda não estavam incluídas na release estável do Chrome. Em software cujo histórico de commits é público, o risco de reconstruir código de ataque a partir do diff da correção está sempre presente, mas este caso é um exemplo real em que um estado distinto tanto de um N-day habitual como de um zero-day — «corrigido a montante e não corrigido a jusante» — foi usado num ataque real. O ciclo de release major do Chrome ter sido, até há pouco, de 4 semanas (agora é de 2 semanas) também pode considerar-se um fator que facilitou aos atacantes mirar essa janela, mas isso não pode ser afirmado de forma conclusiva. A Volexity aponta que, à medida que os LLM aceleram a pesquisa de vulnerabilidades e o desenvolvimento de exploits, aumenta o perigo do patch gap.
Implicações para a defesa: (1) O primeiro ponto de contato do ataque direcionado foi «XSS refletido num site legítimo». Antes da defesa de perímetro, passa a importar não deixar que o XSS do próprio site sirva de apoio à cadeia. (2) Para uma cadeia que atravessa ao mesmo tempo o navegador e o SO, tanto o isolamento do navegador (site isolation e sandbox obrigatório) como a detecção no endpoint têm sentido. (3) O patch gap não se evita com «a rapidez da aplicação de patches». É um domínio em que, pela primeira vez, pesam um grupo que acompanha os commits a montante e o cuidado, do lado do fornecedor, com o risco de tornar pública a correção antes da release. (4) Contra a falsificação de extensões como LONGTALE, o inventário das extensões instaladas é uma medida prática. Os dados factuais deste texto apoiam-se no relatório da Volexity e na cobertura de The Hacker News e de BleepingComputer; a parte de análise está escrita separada do relato factual.