O Threat Intelligence Group da Google (GTIG) afirma ter, pela primeira vez, visto um ator malicioso usar um exploit zero-day que acredita ter sido construído com a ajuda de um modelo de IA. O exploit era um script Python que contornava a autenticação de dois fatores numa ferramenta de administração de código aberto. A Google não divulgou nem o ator nem o produto, para proteger a correção.
O título escreve-se sozinho, mas aponta na direção errada. A verdadeira mudança não é phishing mais inteligente ou iscos mais bem escritos. É a compressão do ciclo de exploração: a IA está a reduzir o tempo e a competência necessários para encontrar uma vulnerabilidade e transformá-la num exploit funcional. Para algo tão grande e tão exposto como um navegador web, isso altera as contas.
O que a Google realmente encontrou
O relatório do GTIG, publicado a 2026-05-11, é cuidadoso quanto ao que afirma. Não diz que a IA escreveu o exploit. Diz que a Google tem elevada confiança, com base na estrutura do código, de que o ator usou um modelo de IA para ajudar a descobrir a falha e a transformá-la numa arma. Os sinais estavam no código-fonte: docstrings de manual, uma disposição Pythonic estranhamente parecida com um tutorial e uma pontuação CVSS alucinada que nenhum investigador humano inventaria. A Google também observa que o seu próprio modelo, o Gemini, provavelmente não foi o utilizado.
O mesmo relatório descreve outros três padrões que vale a pena separar do exagero:
- Geração de exploits assistida por IA, em que os modelos aceleram a investigação e a transformação em arma em vez de substituírem o atacante.
- Malware mais autónomo, ainda experimental, em que um payload consulta um modelo em runtime para ler o estado do sistema e escolher a sua próxima ação, em vez de seguir lógica codificada. A Google aponta para famílias em fase de investigação como o PROMPTSPY e o PROMPTFLUX.
- Abuso industrializado do acesso a modelos premium, em que os criminosos usam middleware e pipelines automatizados de registo para contornar os limites de utilização.
Nada disto é "a IA substitui os hackers". É "a IA torna as partes lentas e dispendiosas mais rápidas". Essa é a parte em torno da qual os defensores devem planear.
A verdadeira mudança é a compressão do ciclo de exploração
Encontrar uma vulnerabilidade grave e escrever um exploit fiável sempre foi a parte dispendiosa de um ataque. Exige competência rara, tempo e paciência. O texto de phishing nunca foi o estrangulamento.
A compressão ataca esse estrangulamento. Quando um modelo ajuda um ator de nível intermédio a ler código-fonte desconhecido, a identificar um caminho de código fraco e a montar uma prova de conceito funcional, o intervalo entre "existe um bug" e "um bug está a ser explorado em larga escala" fica mais curto. O caso da Google é um ponto de dados. A tendência é que conta a história: investigação mais rápida, transformação em arma mais rápida, ritmo operacional mais elevado.
Isso importa sobretudo para software que é enorme, em rápida mudança e omnipresente. O navegador é o exemplo mais claro.
Porque é que o navegador é o maior alvo
Os navegadores são sistemas vastos, com múltiplos componentes
Um navegador moderno não é um único programa. O Chromium, o motor por trás do Chrome, Edge, Brave, Opera e muitos outros, tem dezenas de milhões de linhas de código e integra mais de 200 bibliotecas de terceiros. Muitas delas são de código aberto e mantidas por equipas distintas:
- O V8 executa JavaScript e WebAssembly.
- O Blink renderiza a página.
- O Skia desenha gráficos 2D.
- O ANGLE traduz chamadas gráficas para a GPU.
- O libwebp descodifica imagens WebP.
- O WebRTC trata de áudio e vídeo em tempo real.
Cada um deles é superfície de ataque. Um único bug de memória em qualquer um deles pode tornar-se execução remota de código. O código aberto é uma vantagem para a revisão e a rapidez, mas também significa que o código exato que um atacante estuda é o mesmo código distribuído por milhares de milhões de dispositivos.
Lançam-se constantemente novas funcionalidades, e novos zero-days seguem-se
O Chrome lança um novo marco aproximadamente a cada quatro semanas, e a plataforma web continua a crescer: novas APIs, novos codecs, novos caminhos de GPU. Mais funcionalidades significam mais código, e mais código significa mais bugs. O resultado é constante, não ocasional. A Google corrigiu cerca de nove zero-days do Chrome ativamente explorados em 2024 e cerca de oito em 2025, e estes concentram-se nos mesmos componentes complexos:
- Confusão de tipos no V8: CVE-2025-10585 e CVE-2025-13223.
- Validação do ANGLE e da GPU: CVE-2025-6558.
- Skia e V8 novamente em 2026: CVE-2026-3909 e CVE-2026-3910, ambos explorados em ambiente real.
Os zero-days no navegador não são eventos raros para os quais nos preparamos. São uma condição recorrente em torno da qual há que projetar.
Um componente de código aberto, raio de impacto entre ecossistemas
O aviso mais claro veio do libwebp. A CVE-2023-4863 era um heap buffer overflow nessa única biblioteca de descodificação de imagens, explorável com um único ficheiro WebP forjado. Foi inicialmente classificada como 8.8 enquanto bug do Chrome, depois reclassificada para 10.0 assim que o âmbito foi compreendido, porque o libwebp está em todo o lado. (Um segundo identificador, CVE-2023-5129, foi posteriormente incorporado como duplicado.)
O mesmo bug atingiu o Chrome, o Firefox, o Signal, o 1Password, o Telegram e, criticamente, quase todas as aplicações construídas sobre Electron. Uma biblioteca, uma falha, e o raio de impacto cobriu uma grande fatia do software que as pessoas usam todos os dias.
Os zero-days não param no separador do navegador
É aqui que a compressão se torna perigosa. A sandbox do navegador existe por uma razão: um separador deve ser um ambiente hostil, isolado do resto da sua máquina. Mas o mesmo motor que alimenta o seu navegador também é distribuído dentro de apps desktop.
O Electron inclui a sua própria cópia do Chromium para que os programadores web possam criar apps com aspeto nativo. O VS Code, o Slack, o Discord e a app desktop do Claude da Anthropic são todas aplicações Electron. Cada uma carrega a sua própria build do Chromium, e essas builds ficam atrás da versão upstream. Quando a Google corrige um zero-day do V8, todas as apps Electron permanecem vulneráveis até integrarem a correção e lançarem uma atualização, o que pode levar semanas.
Agora combine dois factos. Primeiro, estas apps herdam os zero-days do navegador. Segundo, correm fora da sandbox do navegador, muitas vezes com acesso total ao sistema de ficheiros e, no caso dos agentes de programação de IA, com a capacidade de executar comandos de shell. Um bug do motor do navegador que seria um problema contido e em sandbox num separador torna-se muito mais grave dentro de uma app local que pode ler os seus ficheiros e executar código. O caso do libwebp já provou que as apps Electron herdam estas falhas. À medida que as apps desktop de IA e os agentes de programação se difundem, a população de software de privilégio elevado que integra o Chromium nas máquinas dos programadores continua a crescer, e também cresce o retorno de um único zero-day do motor do navegador.
Dependências envenenadas executam-se no mesmo navegador
A compressão tem uma segunda frente: a cadeia de fornecimento. A mesma IA que acelera a investigação de exploits acelera a deteção e o abuso de dependências fracas, e o código das dependências executa-se exatamente no sítio que não consegue ver a partir do servidor.
O ecossistema npm tornou isto concreto em 2025. A 2025-09-08, os atacantes fizeram phishing a um maintainer e publicaram versões maliciosas de pacotes imensamente populares, incluindo chalk e debug. O payload injetado era um crypto-clipper direcionado ao navegador: enganchava-se em window.ethereum e nas chamadas de rede para trocar silenciosamente os endereços de carteira no navegador da vítima. Dias depois, o worm auto-replicante "Shai-Hulud" comprometeu centenas de pacotes e roubou credenciais de programadores à medida que se propagava.
Este é o padrão Magecart generalizado. O código malicioso de terceiros não precisa de um bug de memória. Só precisa de carregar e, assim que o faz, executa-se no mesmo contexto que a sua página, com acesso a formulários, tokens e a tudo o que o utilizador digita.
Porque é que a análise prévia ao lançamento não chega
A maioria dos orçamentos de segurança continua a situar-se antes da implementação: análise estática, análise de dependências, uma fase de revisão e depois o lançamento. Esses controlos são necessários, mas partilham um ponto cego. Inspecionam um instantâneo de código que já conhece, num momento anterior à sua execução.
Os zero-days são, por definição, os bugs que ninguém catalogou ainda. As dependências comprometidas mudam muitas vezes depois de passarem na revisão, trocando código limpo por código malicioso num carregamento posterior. Os scripts de terceiros atualizam-se a si próprios em produção sem pedir. E a compressão do ciclo de exploração encurta a janela entre uma falha tornar-se conhecida e uma falha ser usada. Analisar um instantâneo prévio ao lançamento não consegue apanhar um payload que só aparece em runtime, no navegador, depois de o seu pipeline estar concluído.
Essa lacuna não é uma falha de ferramentas. É uma falha de visibilidade. Não é possível chegar, por análise, a ver o que se executa na sessão de navegador de outra pessoa.
O que fazer esta semana
- Inventarie todos os scripts de terceiros no seu site, incluindo os que são carregados por outros scripts.
- Monitorize o comportamento dos scripts em runtime, não apenas na implementação: o que carrega, o que mudou, o que cada script lê e para onde envia dados.
- Aperte a cadência de correções para os navegadores e para as apps Electron que a sua equipa usa. Trate um zero-day do Chromium como um prazo para o VS Code, o Slack e ferramentas semelhantes, não apenas para o navegador.
- Imponha uma Content Security Policy que limite de onde os scripts podem carregar e para onde os dados podem ser enviados.
- Alerte sobre anomalias: um script conhecido a contactar de repente um novo domínio, a ler campos de pagamento ou a alterar o seu payload.
Como o cside se encaixa
O cside vigia a camada que o resto da sua stack não consegue: a sessão de navegador ao vivo. Dá-lhe visibilidade em runtime sobre cada script que se executa no seu site, o que carrega, como mudou desde a versão anterior, que dados toca e para onde esses dados vão.
Isso importa num mundo de ciclos de exploração comprimidos porque não depende de conhecer o exploit de antemão. Quando um script de confiança começa a comportar-se de forma diferente, quando uma dependência troca por código novo depois da implementação, ou quando um payload começa a exfiltrar dados de formulários, a mudança é visível em runtime mesmo que a vulnerabilidade subjacente seja totalmente nova. A análise prévia ao lançamento informa-o sobre o código que lançou. O cside informa-o sobre o que está realmente a correr agora mesmo.
Comece com a segurança do lado do cliente para monitorização completa de scripts em runtime, ou com o Privacy Watch para ver exatamente o que os scripts de terceiros recolhem e enviam.
Leitura adicional sobre o cside
- Comprometimento da cadeia de fornecimento do Web SDK da AppsFlyer
- Os maiores ataques Magecart da história (até agora)
- Ataque à cadeia de fornecimento web através de jQuery trojanizado
- Como scripts de terceiros comprometidos podem fazer prompt-injection a agentes de IA
- Boas práticas para proteger scripts de terceiros
Em 2026-06-03. As contagens de zero-days do Chrome e as conclusões do GTIG refletem os relatos disponíveis nessa data.
Sobre o autor
Simon Wijckmans é o fundador e CEO da cside. Escreve sobre segurança do lado do cliente, ameaças na camada do navegador, scripts de terceiros e o trabalho de normalização necessário para tornar a web mais segura.
