Modelo aberto GLM 5.3 montou sozinho exploits para o Firefox: US$ 1000 por versão
Pesquisadores da Epoch AI testaram o que o modelo aberto chinês GLM 5.3 consegue fazer no chamado «patch gap». É o período em que a correção de uma vulnerabilidade já está visível no código aberto, mas ainda não chegou aos usuários. O modelo encontrou sozinho correções de segurança disfarçadas no Firefox e montou ataques funcionais a partir delas. Cada um custou cerca de US$ 1000 em API. O resultado foi uma página web: basta o usuário abri-la para que ela leia arquivos locais e os envie ao atacante. Para isso, o modelo encadeou várias vulnerabilidades. • O ataque mais rápido levou 12 horas; o limite era de 48. • Contra o Chrome, foram gastos cerca de US$ 100 000, e nenhum exploit foi obtido. • A Mozilla corrigiu a falha principal no Firefox 159.0, de 27 de outubro.
Processado por IA de The Decoder; editado por Hamidun News
Pesquisadores da Epoch AI, que medem as capacidades de IA, mostraram que o modelo chinês de pesos abertos GLM 5.3 (desenvolvido pela Z.ai) consegue montar sozinho, sem ajuda humana, uma cadeia completa de ataque ao Firefox. O processo leva de 12 a 48 horas, e cada ataque bem-sucedido custa cerca de US$ 1000 em uso de API. O modelo explora o «patch gap»: a janela em que a correção de uma vulnerabilidade já foi publicada no código aberto, mas a atualização ainda não chegou aos usuários. O ataque final funciona assim: a pessoa acessa uma página especialmente preparada, que lê os arquivos do computador dela e os envia ao servidor do invasor.
Como o modelo descobriu falhas a partir de correções alheias
As condições do experimento foram propositalmente modestas. Os pesquisadores queriam estimar o que um atacante pouco qualificado e com orçamento limitado consegue fazer. O modelo recebeu:
• a versão necessária do Firefox; • ferramentas básicas; • informações públicas; • um ambiente isolado, sem acesso à internet; • uma instrução curta para estudar o patch gap.
Dali em diante, o modelo trabalhou sozinho. Ele buscou no código as futuras correções de segurança, escolheu vulnerabilidades e montou ataques em várias etapas.
O primeiro obstáculo é que o Firefox disfarça essas alterações de segurança como melhorias comuns, para dificultar a vida dos atacantes. O GLM 5.3 decifrou o truque e, mesmo assim, identificou quais mudanças estavam ligadas à segurança. Em um dos casos, a partir de uma correção em preparação, ele notou um erro no tratamento de memória e descobriu como ler e alterar a memória do navegador.
Em seguida, o modelo esbarrou nas camadas de proteção embutidas do Firefox: de início, não conseguiu chegar ao arquivo desejado. Então acrescentou várias etapas ao primeiro exploit e contornou as barreiras restantes. Em todos os ataques bem-sucedidos contra versões atuais, ele se apoiou na mesma vulnerabilidade até então desconhecida, que redescobriu a cada tentativa. Essa falha permitia escapar da «sandbox», o ambiente isolado do navegador, e ler arquivos diretamente do computador.
Os números:
• 6 versões do Firefox, lançadas de 17 de setembro a 26 de outubro; • cerca de US$ 1000 em API por ataque bem-sucedido; • 12 horas para o ataque mais rápido, com máximo de 48; • mais de 200 milhões de usuários ativos do Firefox potencialmente em risco, incluindo senhas salvas, cookies de autenticação e documentos pessoais.
Os autores observam ainda que nem a Z.ai nem outros provedores de API ativaram filtros de proteção ou recusaram o pedido. A tarefa foi apresentada como um exercício de segurança, mas, pelo comportamento exigido, era indistinguível de uma tentativa de atacar pessoas reais.
Sobre a divulgação responsável: a equipe comunicou a vulnerabilidade à Mozilla, que a corrigiu no Firefox 159.0, de 27 de outubro de 2026. Os autores não verificaram se o mesmo método funcionaria contra a nova versão. Eles avaliam que atacar ficou, "no mínimo, bem mais difícil".
O Chrome resistiu por enquanto, mas isso não é garantia
A mesma abordagem foi testada no Google Chrome. Foram gastos cerca de US$ 100 000 em API, e não se obteve um exploit funcional equivalente. Os autores ressaltam que isso não prova que o Chrome seja invulnerável. Formas melhores de formular a tarefa ou modelos mais fortes podem ter sucesso. Eles citam dados limitados de testes segundo os quais o recém-anunciado Kimi K3.1 Pro pode superar o GLM 5.3 em tarefas ofensivas. Eles mesmos não testaram esse modelo.
Outro alerta: o problema vai além dos navegadores. O patch gap existe em sistemas operacionais móveis e no firmware de roteadores. Projetos abertos são mais vulneráveis porque todo o código é público, mas isso não ajuda os projetos fechados. A Anthropic já mostrou que seu modelo Mythos consegue explorar o patch gap no Windows sem acesso ao código-fonte, e os modelos estão cada vez melhores em descompilar programas e encontrar neles, por conta própria, correções de segurança.
Há exemplos reais. Segundo o relatório, em setembro de 2026 o patch gap foi usado em ataques ao Chrome. No mesmo mês, um fornecedor publicou builds corrigidos do PHP mais de seis horas antes do lançamento coordenado dos patches para duas falhas críticas. De acordo com relatos externos, isso pode ter levado a milhares de tentativas de exploração antes do lançamento oficial e a milhões logo depois. O risco é maior onde os usuários atualizam pouco: roteadores e sistemas móveis permanecem vulneráveis por muito mais tempo.
Atualizar mais rápido não basta: o que os autores recomendam
As recomendações dos pesquisadores são:
• manter as correções de segurança fechadas até o momento em que estiverem prontas para o lançamento; • levá-las mais rápido da versão beta para a versão estável; • não corrigir em um único pacote vulnerabilidades que podem ser encadeadas.
Firefox e Chrome já adotaram atualizações semanais. Isso, porém, não elimina o problema estrutural: assim que uma correção chega ao código público, ela aponta ao atacante a própria falha. O acesso dos defensores a modelos fechados poderosos também não resolve a questão.
Depois do lançamento do Claude Mythos Preview, da Anthropic, em abril de 2026, os laboratórios de ponta restringiram o acesso a seus modelos e criaram programas de acesso antecipado para defensores, entre eles Glasswing e Daybreak. Mas, à medida que os modelos abertos ficam mais potentes, as capacidades ofensivas escapam ao controle de qualquer «porteiro» isolado. Os autores escrevem que veem nos resultados um sinal da disseminação de capacidades cibernéticas avançadas. Na avaliação deles, muitos outros programas provavelmente já estão vulneráveis a esses ataques, e o número deles tende a crescer com a chegada de modelos abertos mais fortes.
Para engenheiros e fornecedores, a conclusão é simples: a janela entre a publicação da correção e a atualização nos usuários deve ser tratada agora como período de ataque ativo, e os processos de lançamento de patches precisam partir do princípio de que uma IA lê todo commit público.
- 1 de nov. de 2026Google admite que o AI Mode reduz a receita da Busca; ações caem 15%
- 31 de out. de 2026Autor leva roteiro a julgamento por jurados de IA, e o veredito custa 850 mil tokens
- 31 de out. de 2026Anthropic: unir subagentes em um único loop deixou as tarefas de um cliente duas vezes mais rápidas
- 31 de out. de 2026IBM: perguntas ao cliente antes da geração elevaram a precisão de smart contracts de 54% para 73%
Perguntas frequentes sobre a notícia
Como o modelo descobriu falhas a partir de correções alheias?
As condições do experimento foram propositalmente modestas. Os pesquisadores queriam estimar o que um atacante pouco qualificado e com orçamento limitado consegue fazer. O modelo recebeu: a versão necessária do Firefox; ferramentas básicas; informações públicas; um ambiente isolado, sem acesso à internet; uma instrução curta para estudar o patch gap. Dali em diante, o modelo trabalhou sozinho. Ele buscou no código as futuras correções de segurança, escolheu vulnerabilidades e montou ataques em várias etapas. O primeiro obstáculo é que o Firefox disfarça essas alterações de
O que se sabe sobre O Chrome resistiu por enquanto, mas isso não é garantia?
A mesma abordagem foi testada no Google Chrome. Foram gastos cerca de US$ 100 000 em API, e não se obteve um exploit funcional equivalente. Os autores ressaltam que isso não prova que o Chrome seja invulnerável. Formas melhores de formular a tarefa ou modelos mais fortes podem ter sucesso. Eles citam dados limitados de testes segundo os quais o recém-anunciado Kimi K3.1 Pro pode superar o GLM 5.3 em tarefas ofensivas. Eles mesmos não testaram esse modelo. Outro alerta: o problema vai além dos navegadores. O patch gap existe em sistemas operacionais móveis e no firmware de r
O que se sabe sobre Atualizar mais rápido não basta: o que os autores recomendam?
As recomendações dos pesquisadores são: manter as correções de segurança fechadas até o momento em que estiverem prontas para o lançamento; levá-las mais rápido da versão beta para a versão estável; não corrigir em um único pacote vulnerabilidades que podem ser encadeadas. Firefox e Chrome já adotaram atualizações semanais. Isso, porém, não elimina o problema estrutural: assim que uma correção chega ao código público, ela aponta ao atacante a própria falha. O acesso dos defensores a modelos fechados poderosos também não resolve a questão. Depois do lançamento do Claude Myth
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
O essencial da IA — uma vez por semana
Sete histórias que realmente importaram, escolhidas a dedo. Sem ruído nem releases.
Pronto! Verifique seu e-mail para a confirmação.