Os bastidores do fortalecimento do Firefox com Claude Mythos Preview

• A Mozilla construiu um pipeline para encontrar bugs de segurança reais em larga escala no Firefox, aumentando o sinal e reduzindo o ruído dos relatórios de segurança gerados por IA com melhorias no desempenho dos modelos e no harness
• No Firefox 150 release, foram corrigidos 271 bugs identificados pelo Claude Mythos Preview, e 149.0.2, 150.0.1 e 150.0.2 também incluíram correções relacionadas
• Entre os principais bugs divulgados estão um primitive de objeto falso causado pela remoção da inicialização de structs WebAssembly GC no JIT, um UAF no processo pai via condição de corrida em IPC, um problema de desserialização de NaN, um bug de rehash de 20 anos no XSLT e um overflow de bitfield de layout de 16 bits usando rowspan=0
• Uma parte significativa dos bugs divulgados envolve escape de sandbox, assumindo um processo de conteúdo já comprometido que eleva privilégios para o processo pai com privilégios, cobrindo com análise por IA uma superfície de ataque difícil de encontrar apenas com fuzzing
• A Mozilla colocou um harness agêntico sobre sua infraestrutura de fuzzing existente para descartar suposições que não se reproduziam e validar hipóteses com casos de teste, e planeja integrar isso à integração contínua para escanear patches quando entrarem na tree

---

A mudança nos bugs de segurança do Firefox revelada por modelos de IA

• Até alguns meses atrás, relatórios de bugs de segurança gerados por IA enviados para projetos open source muitas vezes pareciam plausíveis, mas estavam errados, criando um custo assimétrico para os mantenedores
• No Firefox, a situação mudou drasticamente em pouco tempo, e a principal razão foi a melhora no desempenho dos modelos e nas técnicas de controlar, estender e combinar modelos com um harness para aumentar o sinal e filtrar o ruído
• A Mozilla normalmente mantém relatórios detalhados de bugs em sigilo por alguns meses mesmo após publicar avisos de segurança e distribuir correções, mas desta vez decidiu divulgar alguns relatórios considerando a urgência e o interesse em todo o ecossistema
• Os relatórios divulgados foram escolhidos entre vários subsistemas do navegador e, embora a seleção seja até certo ponto arbitrária, a profundidade e a diversidade dos relatórios mostram por que defensores precisam aplicar essa técnica

Principais bugs divulgados

• 2024918
  • Por causa de uma verificação de equivalência incorreta, o JIT removeu por otimização a inicialização de uma struct WebAssembly GC viva, o que poderia criar um primitive de objeto falso ligado a leitura e escrita arbitrárias potenciais em código que já havia passado por amplo fuzzing interno e externo
• 2024437
  • Um bug de 15 anos no elemento <legend>, acionado por uma combinação sofisticada de casos de borda em áreas separadas do navegador, como limite de profundidade da pilha recursiva, propriedades expando e cycle collection
• 2021894
  • Explorando de forma confiável uma condição de corrida em IPC, um processo de conteúdo comprometido podia manipular a contagem de referências do IndexedDB no processo pai, causando UAF e potencial escape de sandbox
• 2022034
  • Um NaN bruto podia parecer um ponteiro de objeto JS com tag ao atravessar um limite de IPC, permitindo que a desserialização de double levasse a um primitive de objeto falso no processo pai e a escape de sandbox
• 2024653
  • Um caso de teste complexo combinando loops de evento aninhados, listener de pagehide e coleta de lixo causava UAF no setter de atributo do elemento <object>
• 2022733
  • Ao empurrar milhares de hashes de certificado para o WebTransport, era possível ampliar uma condição de corrida em um loop de cópia com alta contagem de referências e provocar UAF no processo pai via IPC a partir de um processo de conteúdo comprometido
• 2023958
  • Interceptando chamadas de função DNS da glibc para simular um servidor DNS malicioso e reproduzir um caso de borda no fallback de UDP para TCP, foi possível causar leitura além do buffer e vazamento de memória da pilha do processo pai durante o parsing de HTTPS RR e ECH
• 2025977
  • Um bug de 20 anos no XSLT em que uma chamada reentrante de key() causava rehash da tabela hash, liberava o backing store, mas o ponteiro bruto da entrada continuava sendo usado; era um entre vários problemas sec-high de XSLT corrigidos
• 2027298
  • Após modificar o color picker para simular uma seleção do usuário difícil de automatizar, um loop de evento aninhado era executado com eventos de entrada síncronos, reentrando no teardown do actor e fazendo com que ele fosse liberado durante o unwind do callback, causando UAF no processo de conteúdo
• 2023817
  • Um processo de conteúdo comprometido podia enviar uma imagem de papel de parede arbitrária para ser decodificada no processo pai, o que, combinado com uma vulnerabilidade hipotética no decodificador de imagem, poderia levar a escape de sandbox
  • Isso exigia um raciocínio difícil de automatizar no processo pai para determinar o nível de confiança da entrada
• 2029813
  • No RLBox, tecnologia de sandboxing granular do Firefox 95, foi possível contornar o sandbox explorando uma brecha na lógica de validação que copia valores do lado não confiável para o lado confiável
• 2026305
  • Um caso de teste muito pequeno que explora a semântica especial de rowspan=0 em tabelas HTML adicionou mais de 65535 linhas para contornar o clamping e causar overflow em um bitfield de layout de 16 bits, passando anos sem ser pego por fuzzers

Escape de sandbox e camadas de defesa

• Uma parte considerável dos bugs divulgados envolve escape de sandbox, e para resultar em comprometimento completo da cadeia do Firefox eles precisariam ser combinados com outros exploits
• Esses relatórios assumem uma situação em que o processo em sandbox que renderiza conteúdo de sites já foi comprometido por outro bug, e código de máquina controlado pelo atacante tenta elevar privilégios para o processo pai com privilégios
• Ao criar escapes de sandbox, o modelo pode fazer patch no código-fonte do Firefox desde que o código modificado seja executado apenas dentro do processo em sandbox
• Esse tipo de bug é difícil de encontrar com fuzzing, e a Mozilla vem desenvolvendo técnicas como fuzzing de IPC com snapshots, mas a análise por IA conseguiu cobrir essa superfície importante de forma muito mais abrangente
• O que o modelo não encontrou também foi importante
  • Nos últimos anos, pesquisadores de segurança enviaram vários relatórios sobre escapes de sandbox por meio de prototype pollution no processo pai com privilégios
  • Em vez de corrigir os problemas um a um, a Mozilla aplicou uma mudança de arquitetura que congela prototypes por padrão
  • Nos logs do harness havia muitos sinais de tentativas dessa rota de escape bloqueadas pelo design, confirmando o efeito direto do trabalho anterior de fortalecimento

Construindo um pipeline de fortalecimento de segurança com harness

• Nos últimos anos, a Mozilla conduziu internamente experimentos de auditoria de código com LLMs para analisar estaticamente código de alto risco com modelos como GPT 4 e Sonnet 3.5
• Os experimentos iniciais mostraram potencial, mas a taxa de falsos positivos era alta demais para escalar
• A situação mudou com o surgimento de harnesses agênticos capazes de detectar problemas de segurança de forma confiável
  • Eles conseguem encontrar bugs reais
  • Conseguem descartar suposições que não se reproduzem
  • Com a interface e as instruções certas, conseguem criar e executar casos de teste reproduzíveis para validar dinamicamente hipóteses de bugs no código
• Depois de corrigir os problemas iniciais enviados pela Anthropic em fevereiro, a Mozilla construiu seu próprio harness sobre a infraestrutura de fuzzing existente
• No início, foram feitos experimentos em pequena escala com Claude Opus 4.6 para procurar escapes de sandbox
  • Só esse modelo já identificou um número considerável de vulnerabilidades antes desconhecidas que exigiam raciocínio complexo sobre código de um engine de navegador multiprocesso
  • No começo, o processo era acompanhado diretamente no terminal, com ajuste em tempo real de prompts e lógica
  • Depois que o funcionamento se estabilizou, o trabalho foi paralelizado em várias VMs efêmeras, cada uma procurando bugs em arquivos-alvo específicos e registrando os resultados em buckets
• O subsistema de descoberta por si só não era suficiente
  • Era necessário integrar todo o ciclo de vida do bug de segurança, incluindo o que procurar, onde olhar e como tratar os resultados
  • Isso incluía deduplicação com problemas existentes, rastreamento de bugs, triage e distribuição de correções
  • O modelo é o primitive central que move o harness, mas para ser útil em escala é preciso o pipeline inteiro
• O harness pode ser reutilizável entre projetos, mas o pipeline varia de projeto para projeto conforme o significado da codebase, as ferramentas e os processos
• Foi necessário bastante trabalho iterativo com um loop de feedback estreito junto ao processo pelo qual os engenheiros do Firefox tratam os bugs recebidos

Claude Mythos Preview e o efeito da troca de modelo

• Quando o pipeline end-to-end está pronto, trocar para outro modelo quando um novo aparece se torna simples
• A Mozilla já havia encontrado vários bugs graves com modelos abertos, e graças a esse pipeline pôde aproveitar imediatamente a chance de avaliar o Claude Mythos Preview
• O upgrade do modelo aumentou a eficácia de todo o pipeline
  • Encontra melhor bugs potenciais
  • Cria melhor casos de teste de prova de conceito para demonstrar o bug
  • Organiza melhor a patologia e o impacto
• Além de corrigir 271 bugs identificados pelo Claude Mythos Preview no Firefox 150 release, correções relacionadas também foram incluídas em 149.0.2, 150.0.1 e 150.0.2
• Internamente, bugs continuam sendo encontrados também por outros métodos, e, como em outros projetos, os relatórios externos também aumentaram bastante nos últimos meses
• Todos os bugs exigiram atenção cuidadosa para serem corrigidos adequadamente, e os últimos meses envolveram muito trabalho e longas jornadas para acompanhar uma escala sem precedentes
• Mais de 100 pessoas participaram com contribuições de código para entregar o Firefox mais seguro possível, incluindo não só escrita e revisão de patches, mas também construção e expansão do pipeline, triage, testes das correções e gestão do processo de release de cada bug

Principais lições

• Qualquer pessoa que desenvolva software hoje pode usar modelos modernos e harnesses para encontrar bugs e fortalecer código
• É possível começar com prompts simples, observar e iterar
  • O prompt inicial não era muito diferente do método mostrado neste vídeo
  • Ao longo das iterações, foram adicionadas muitas ferramentas e orquestração para otimizar e expandir o pipeline, mas o núcleo do loop interno era: “há um bug nesta parte do código; encontre-o e crie um caso de teste”
• O Firefox ainda não esgotou todos os bugs potenciais, mas a Mozilla está satisfeita com a trajetória atual
• Atualmente, o escaneamento se concentra em áreas específicas de código, como arquivos e funções, escolhidas em geral por uma mistura de julgamento humano e sinais automáticos
• Num futuro próximo, o plano é integrar essa análise ao sistema de integração contínua para escanear patches quando entrarem na tree
• Os modelos se adaptam com flexibilidade ao formato de contexto fornecido, e espera-se que o escaneamento baseado em patches funcione tão bem quanto ou melhor do que o escaneamento baseado em arquivos
• O momento atual é arriscado, mas também cheio de oportunidades, e é preciso agir em conjunto para tornar a internet mais segura

Perguntas frequentes

• Por que “271 bugs” é diferente do número nos avisos de segurança

  • Na página de avisos de segurança, bugs reportados internamente são agrupados em CVEs “rollup”, sob os quais vários bugs ficam reunidos
  • A página é gerada a partir do yaml no repositório foundation-security-advisories, que é o local oficial de atribuição de CVEs
  • Alguns navegadores não criam identificadores CVE para problemas encontrados internamente, mas a Mozilla os divulga para fornecer informação da forma mais transparente possível
  • O Firefox 150 tinha 3 rollups internos
    • CVE-2026-6784: 154 bugs
    • CVE-2026-6785: 55 bugs
    • CVE-2026-6786: 107 bugs
  • A soma dos três rollups internos é 316, maior do que os 271 bugs anunciados como encontrados com Claude Mythos Preview
  • A razão é que a equipe de segurança da Mozilla ataca o Firefox todos os dias e encontra novos bugs com uma combinação de sistema de fuzzing, inspeção manual e novo pipeline agêntico usando vários modelos
  • Na release de abril, foram corrigidos 423 bugs de segurança no total
    • Os 271 bugs anunciados duas semanas antes
    • 41 bugs reportados externamente
    • Os 111 restantes foram encontrados internamente e se dividem aproximadamente em três categorias
      • Bugs encontrados por esse pipeline usando Claude Mythos Preview, mas corrigidos em outras releases e não no Firefox 150
      • Bugs encontrados por esse pipeline usando outros modelos
      • Bugs encontrados por outras técnicas, como fuzzing
  • A Anthropic recebeu crédito direto por 3 CVEs, separados deste trabalho mais recente
    • CVE-2026-6746
    • CVE-2026-6757
    • CVE-2026-6758
  • Eles correspondem a correções de bugs que a Anthropic Frontier Red Team enviou para a Mozilla alguns meses antes, e cada um recebeu um CVE próprio segundo o procedimento normal

• O significado das classificações de gravidade de segurança

  • A Mozilla aplica security severity ratings, de critical a low, para indicar a urgência dos bugs
  • sec-critical e sec-high são atribuídos a vulnerabilidades que podem ser acionadas por comportamentos comuns do usuário, como visitar uma página web
  • Não há diferença técnica entre sec-critical e sec-high, mas sec-critical é usado apenas para problemas já divulgados publicamente ou conhecidos por terem sido explorados em ataques reais
  • sec-moderate é atribuído a vulnerabilidades que normalmente seriam avaliadas como sec-high, mas exigem etapas anormais e complexas por parte da vítima
  • sec-low é atribuído a bugs incômodos mais distantes de causar dano ao usuário, como um crash seguro
  • As classificações dos 271 bugs anunciados no Firefox 150 foram as seguintes
    • 180 sec-high
    • 80 sec-moderate
    • 11 sec-low
  • A Mozilla considera bugs critical/high os mais importantes, mas também costuma priorizar bugs de segurança moderate e low para corrigir problemas de correção e aprofundar a defesa

• A diferença entre sec-high ou sec-critical e um exploit real

  • Um bug sec-high ou sec-critical não significa automaticamente um exploit prático
  • Na maioria dos casos, um único bug critical/high não é suficiente para comprometer o Firefox
  • O Firefox tem uma arquitetura de defesa em profundidade; por exemplo, mesmo explorando um bug no JIT, o resultado seria execução remota de código em um processo em sandbox e isolado por site
  • Na prática, atacantes geralmente precisam encadear vários exploits para atravessar uma ou mais camadas de sandboxing e mitigações no nível do sistema operacional, como ASLR, até elevar privilégios
  • A Mozilla normalmente não desenvolve exploits para verificar se um bug pode de fato ser usado por atacantes reais
  • A classificação sec-high se baseia em sintomas previsíveis de crash, como use-after-free ou problemas de memória out-of-bounds relatados pelo AddressSanitizer
  • O modelo de ameaça assume que, com esforço suficiente, esses bugs podem ser exploráveis
  • Essa abordagem reduz o risco de falsos negativos na análise de explorabilidade e permite concentrar recursos em encontrar e corrigir mais vulnerabilidades

[GN⁺]

Opiniões no Lobste.rs

• Seria bom se também publicassem os prompts e outros recursos usados nesse trabalho
  Seria útil incluir os prompts nos relatórios de bugs ou nos registros de correção para que isso possa ser reproduzido
  Como também mencionaram modelos não-Mythos, parece que parte desse trabalho poderia ser imediatamente útil para outras pessoas

  • Na maioria dos projetos, a barreira de entrada é realmente baixa
    Basicamente, basta dizer “revise este projeto sob a perspectiva de problemas de segurança, começando por (arquivo), e liste todos os caminhos possíveis”, e depois continuar com “verifique este relatório e crie uma prova de conceito” para cada item
    Hoje em dia, usando o Opus, está mais difícil não encontrar algo desse jeito
  • Você acha que o prompt era algo além de “encontre vulnerabilidades de segurança nesta base de código”?

• Independentemente de como se diga, isso é realmente impressionante
  Encontraram 271 problemas de segurança com o Mythos e 423 no total
  Desses, 180 eram de alta gravidade, e alguns dos problemas de segurança tinham 20 anos

  • Não está totalmente claro quão justa foi a comparação Opus 4.6 / Mythos
    Fica implícito algo como o resultado de que o Mythos encontrou “271 bugs” em código que já havia sido escaneado da mesma forma antes com o 4.6, mas o texto não diz exatamente isso
    Fico me perguntando se também houve mudanças simultâneas no harness de pesquisa

• A parte “um dos vários problemas sec-high que corrigimos estava relacionado a XSLT” parece ter sido incluída por causa da polêmica sobre a remoção do XSLT

• O que mais me deixa curioso aqui é quantos falsos positivos também foram reportados
  Fico pensando se o modelo reportou algo como o dobro de vulnerabilidades potenciais, e se o que aparece aqui são apenas as confirmadas
  Também não sei se o modelo chega a reproduzir os problemas antes de reportá-los
  Pelos problemas tornados públicos, dá para ver comentários que parecem tentar reproduzi-los, mas também pode ser algo feito por um bot que já existia
  Não conheço bem como o Firefox costumava lidar com esse tipo de trabalho nem como está fazendo isso agora com IA, então uma explicação mais detalhada seria muito interessante