Toda correção é uma confissão.
No momento em que um fornecedor publica uma correção de segurança, o diff (comparação de diferenças) entre o código antigo e o novo revela a quem estiver observando exatamente o que estava quebrado e onde. Transforme esse diff de volta em um exploit (código que se aproveita de uma falha) funcional e você poderá atingir todos os sistemas que ainda não foram atualizados. Essa é a exploração de vulnerabilidades N-day (já divulgadas, mas ainda não corrigidas em muitos ambientes) — e sempre foi uma corrida: o fornecedor corrige, o relógio começa a contar e os defensores tentam aplicar a correção antes que um atacante termine de fazer a engenharia reversa do conserto.
Nos últimos trinta e poucos anos, os defensores geralmente venceram essa corrida.
Fazer a engenharia reversa de uma correção até transformá-la em um exploit confiável era um trabalho lento e especializado, que normalmente exigia semanas de esforço de alto nível. Historicamente, o intervalo entre uma correção e um exploit público funcional se media em semanas, muitas vezes em meses.
O manual tradicional partia do pressuposto de que você tinha pelo menos algumas semanas. Você não tem mais. Nem de perto.
Fazer engenharia reversa de uma correção levava semanas. O Mythos faz em uma hora.
O red team (equipe de testes de ataque) da Anthropic mediu exatamente isso.
Recebendo apenas o diff público e dois builds, o Claude Mythos Preview transformou, sozinho, 18 correções do Firefox em 8 exploits funcionais de execução de código. Seu primeiro exploit surgiu em menos de uma hora depois que a Mozilla publicou a correção. O lançamento do Firefox que continha aquele conserto ainda estava a 18 dias de distância.
Os resultados no Windows são ainda mais duros: sem código-fonte, apenas binários stripped (sem símbolos de depuração) e saída de decompilador. Mesmo assim, de 21 falhas de kernel, ele gerou provas de conceito de crash para 18 (a mais rápida em 31 minutos) e encadeou 8 delas até chegar ao SYSTEM (nível máximo de privilégio no Windows), a um custo de cerca de 2 mil dólares cada.
Fica pior: uma dessas cadeias até o SYSTEM se referia a uma falha que a Microsoft havia classificado como "Exploitation Unlikely" (exploração improvável) — avaliações calibradas para pesquisadores humanos. Claramente, essa calibração não se sustenta mais.
Os modelos públicos do Claude, com suas salvaguardas ativadas, também geraram exploits — só que em menor quantidade. Portanto, não se trata de uma capacidade isolada, trancada em um único modelo com acesso restrito.
Os defensores podem se consolar um pouco com o fato de que transformar um exploit em uma invasão completa ainda exige mais trabalho: entrega, direcionamento, evasão. Mas a etapa que costumava garantir semanas de vantagem aos defensores — transformar uma correção em um exploit funcional — é exatamente aquela cujo prazo acabou de colapsar.
Como a própria equipe da Anthropic resumiu: "N-hour é mais próximo da realidade em que agora operamos."
Desculpe, não dá para sair disso só aplicando mais patches
Esta é a assimetria que quebra o manual antigo: a correção criada para te proteger é o mesmo artefato que arma o atacante. Pois é.
Publique a correção e você entrega aos atacantes um mapa da falha; todos os que ainda não atualizaram viram alvo. Pesquisadores já batizaram esse ponto de virada de "Vulnpocalypse": o momento em que um modelo consegue transformar uma divulgação em arma mais rápido do que os defensores conseguem aplicar a correção.
É por isso que um exploit de 1 dia (imediatamente após a divulgação) nada tem a ver com o que era há dois anos.
A resposta instintiva de corrigir mais rápido é uma proposta perdedora. Os números confirmam:
- O DBIR 2026 da Verizon (Relatório de Investigações de Violações de Dados) aponta a mediana de tempo para corrigir uma falha explorada conhecida
