GLM 5.3 hackeou o Firefox sozinho em 48 horas

O patch gap virou arma automática

GLM 5.3 não precisou de ajuda humana para invadir o Firefox. Pesquisadores da Epoch AI colocaram o modelo aberto em um ambiente isolado, apontaram para a janela entre a correção visível no código e a atualização que chega ao usuário, e deixaram ele trabalhar. Em menos de 48 horas ele entregou uma cadeia completa de exploit, funcional, capaz de ler arquivos locais só com a visita a uma página. O caso mais rápido levou 12 horas. O custo foi de cerca de 1 mil dólares em chamadas de API por versão do Firefox. Se você mantém software, opera segurança ou só depende do navegador para trabalhar, isso muda sua conta de risco.

O fato sem enfeite

O teste cobriu 6 versões do Firefox lançadas entre 17 de setembro e 26 de outubro. Em todas, o GLM 5.3 conseguiu identificar correções de segurança disfarçadas de melhorias rotineiras, selecionar a falha mais promissora e montar um ataque em múltiplos estágios. A Mozilla costuma camuflar patches para ganhar tempo. Não adiantou. O modelo comparou diffs, entendeu o que era correção sensível e focou ali. Nenhum provedor de API bloqueou ou recusou as solicitações durante o desenvolvimento dos exploits, mesmo com o comportamento sendo indistinguível de um ataque real contra usuários.

O exploit final era simples na lógica e brutal no impacto. A vítima abria uma página maliciosa e o código lia arquivos do computador e enviava para um servidor externo. Com mais de 200 milhões de usuários ativos no Firefox, estamos falando de senhas salvas, cookies de autenticação, documentos privados e tokens de sessão expostos sem clique adicional, sem download, sem permissão. A equipe avisou a Mozilla, que corrigiu a falha de sandbox redescoberta pelo modelo no Firefox 159.0, lançado em 27 de outubro de 2026. Os pesquisadores ainda não confirmaram se a nova versão segura contra a mesma técnica, mas dizem que o ataque ficou pelo menos substancialmente mais difícil.

Como funciona na visão de quem opera

Pensa no fluxo como um pipeline autônomo de pesquisa ofensiva. Entrada: versão alvo do Firefox, ferramentas básicas de análise e acesso a informações públicas como repositórios, bugs e diffs de código. O modelo faz o que um analista júnior faria, só que sem dormir. Ele monitora commits, filtra o que parece ser correção de memory safety, reproduz o crash em build vulnerável, desenvolve primitiva de leitura e escrita na memória e depois empilha estágios para escapar das mitigações e do sandbox.

Em um dos casos documentados, ele encontrou um bug de memory safety a partir de um fix futuro, criou uma primitiva para ler e alterar a memória do navegador e, quando as camadas de proteção bloquearam o acesso direto ao arquivo, encadeou outras etapas para contornar as defesas restantes. Em todos os testes bem sucedidos contra versões atuais, ele redescobriu sozinho a mesma vulnerabilidade desconhecida para furar o sandbox. Isso sugere memória de contexto longa, boa capacidade de raciocínio sobre C++ e layout de heap, além de iteração rápida com ferramentas de debug e fuzzing assistido.

Sobre custo e latência, os números são os mais incômodos. Cerca de 1 mil dólares por exploit em Firefox contra cerca de 100 mil dólares gastos sem sucesso equivalente contra o Chrome no mesmo setup. Não é porque o Chrome seja impenetrável. É provável que a superfície, o isolamento de site mais agressivo, o sandbox mais granular e o volume maior de mitigações aumentem o número de passos e tokens necessários. A inferência plausível é que o GLM 5.3 rodou milhões de tokens com janelas longas, muitas tentativas de compilação e teste, e orquestração via API barata de modelo open-weight. Para um atacante, 12 a 48 horas de espera é irrelevante se o retorno é acesso em massa.

O que isso muda na prática

Quem ganha, no curto prazo, é quem já opera com atualização forçada e resposta rápida. Times com MDM configurado, atualização silenciosa do navegador em menos de 24 horas e isolamento por perfil reduzem drasticamente a janela de exposição. Quem perde é todo mundo que trata update de navegador como detalhe. Usuário final que adia restart, empresa que congela versão para não quebrar sistema legado, fornecedor que embarca Firefox ESR sem plano de patch emergencial. O 'patch gap', que antes exigia um especialista lendo diffs na madrugada, agora pode ser varrido por script com modelo aberto.

Tem ação prática para fazer agora. Se você é desenvolvedor ou lidera engenharia, reduza sua dependência de segredos em disco acessíveis ao navegador. Mova sessões críticas para chaves com tempo curto de expiração, ative isolamento total de cookies, force atualizações automáticas e considere rodar navegação de risco em perfil separado ou máquina virtual leve. Se você é time de segurança, precisa ajustar agora o monitoramento de diffs públicos. A mesma telemetria que o modelo usou para achar o fix está aberta para o adversário. Crie regra para acelerar rollout quando houver commit suspeito de memory safety, mesmo sem CVE publicado. Uma lista mínima ajuda:

• Force update do Firefox em até 24 horas em todos os endpoints, sem exceção para diretoria ou dev.
• Remova segredos longos do disco e troque por tokens curtos com rotação automática e verificação de origem.
• Segmente navegação com perfis separados para banco, e-mail crítico e navegação geral.

A tensão que ninguém quer encarar

Aqui fica a dúvida real. Isso escala ou foi um acerto específico contra a arquitetura do Firefox? O fato de o modelo ter redescoberto a mesma falha de sandbox em todas as tentativas sugere que existia um ponto fraco estrutural, não sorte. A Mozilla corrigiu, mas o método continua válido para o próximo bug. E o teste contra o Chrome, que falhou mesmo com 100 mil dólares, não prova imunidade. Só prova que ficou mais caro por enquanto. Com elicitação melhor ou com a próxima geração de modelos abertos, e já se fala de evolução nesse nível, o custo cai de novo.

O outro ponto é custo benefício para defesa. Disfarçar patch como melhoria cosmética funcionava quando o adversário era humano e sem tempo. Contra um modelo que lê milhares de commits sem cansar, a camuflagem vira ruído irrelevante. A alternativa seria entregar correção direto ao usuário sem passar por código público, o que quebra o modelo open source, ou acelerar muito o ciclo de release, o que aumenta risco de regressão. Nenhuma opção é limpa. E tem o dilema do open-weight. O mesmo peso aberto que permite auditoria e deploy barato permite montar esse pipeline por 1 mil dólares, sem guardrail efetivo na API. Bloquear na API não resolve, porque o peso pode rodar local.

Conclusão

O GLM 5.3 transformou o intervalo entre correção e atualização em um processo industrial de exploit. Barato, rápido e sem humano no loop. A correção da Mozilla fecha essa porta específica, mas o método continua aberto. Quanto tempo seu ambiente sobrevive com uma falha crítica de navegador exposta por 48 horas?