A política de divulgação de 90 dias morreu

• A divulgação responsável em 90 dias perdeu seu efeito protetivo porque os LLMs aumentaram o número de descobridores e a velocidade dos exploits
• Em 6 semanas, 11 pessoas relataram o mesmo bug crítico de validação de pagamento, revelando redescoberta simultânea
• Um diff de patch do React foi transformado em um exploit funcional em apenas 30 minutos com ajuda de IA
• Copy Fail e Dirty Frag levaram de PoCs públicas a exploração real, derrubando o embargo
• Problemas críticos devem ser tratados imediatamente como P0, e os LLMs precisam entrar no pipeline de segurança

---

O que levou à quebra do modelo de divulgação responsável em 90 dias

• O prazo de 90 dias para divulgação responsável foi criado com base em um cenário em que descobridores de bugs eram raros e o desenvolvimento de exploits era lento
• Nos últimos 12 meses, as ferramentas usadas por defensores, atacantes e pesquisadores ficaram mais inteligentes em ritmo parecido, e a avaliação é que os LLMs reduziram quase a zero o tempo necessário para encontrar vulnerabilidades e desenvolver exploits
• No modelo de 2019, no estilo do Google Project Zero, dava-se 90 dias ao fornecedor, partindo das seguintes premissas
  • quase ninguém mais encontraria o mesmo bug
  • mesmo que outra pessoa encontrasse, isso levaria tempo
  • o fornecedor teria vantagem suficiente para preparar o patch
  • depois da publicação do patch, atacantes levariam dias ou semanas para fazer engenharia reversa e criar um exploit funcional
• Todas essas premissas estavam erradas, e a janela de 90 dias passou a funcionar menos como proteção ao usuário e mais como uma estrutura que dá 90 dias de vantagem a quem já tem o bug

Caso 1: 11 pessoas relataram o mesmo bug crítico em 6 semanas

• No fim de abril, foi reportado um bug grave a uma empresa, mas a equipe de triagem respondeu que ele já havia sido reportado pela primeira vez em março e que o autor era o 11º relator
• O bug funcionava assim: depois de comprar algo em um site, um atacante podia devolver ao servidor uma resposta manipulada manualmente e, como não havia verificação de assinatura dessa resposta, o servidor a aceitava como válida
  • Por exemplo, era possível comprar um item de 5 mil dólares por 0 dólar ou concluir uma compra sem pagamento real
• O fato de 11 pessoas diferentes terem encontrado o mesmo bug crítico em cerca de 6 semanas mostra um padrão em que caçadores assistidos por LLM convergem quase ao mesmo tempo para a mesma vulnerabilidade
• Um conhecido da BlueWater CTF já vinha apontando, havia meses, o fenômeno de repórteres sem relação entre si e workflows distintos convergirem para os mesmos bugs com ajuda de LLM
• O mesmo fenômeno também foi observado na triagem
  • @d0rsky escreveu que, quando uma nova vulnerabilidade é encontrada por meio de prompts, habilidade e automação com LLM, em poucos dias chegam vários relatórios duplicados da mesma causa raiz
  • Se pesquisadores conseguem reproduzir isso tão rápido, cresce a preocupação de que black hats possam fazer o mesmo antes do patch
• Se 10 pessoas reportaram, pode haver outras que não reportaram, e o mesmo LLM está disponível não só para pesquisadores bem-intencionados, mas para qualquer um
• Como o crédito do CVE e o bug bounty só podem ir para uma pessoa, as outras 9 — ou quem nem reportou — não ficam presas ao relógio dos 90 dias
• Nessa situação, a janela de divulgação de 90 dias não protege os usuários; ela só compra tempo para quem já possui o bug

Caso 2: do patch do React a um exploit funcional em 30 minutos

• O React corrigiu vários problemas de segurança e publicou um post no blog
  • CVE-2026-23870
  • CVE-2026-44575
  • CVE-2026-44579
  • CVE-2026-44574
  • CVE-2026-44578
• Levaram-se 30 minutos para ler o patch e criar um exploit funcional contra um app local de teste
• O problema divulgado era uma negação de serviço (DoS), e a IA cuidou da maior parte da compreensão do diff, da identificação do caminho de código vulnerável e da escrita do PoC
• Antes, transformar um patch público em um exploit n-day funcional exigia de um engenheiro reverso experiente de dias a semanas, e essa diferença de tempo era a margem de segurança para os administradores atualizarem
• Agora, bugs simples podem virar exploit em minutos, e bugs complexos em horas, sem que um especialista em engenharia reversa seja indispensável
• É preciso assumir que, no momento em que o patch sai, o exploit também já existe, e adiar a implantação até a próxima janela de manutenção deixou de fazer sentido

Caso 3: Copy Fail e Dirty Frag, em sequência, no kernel Linux

• Nas últimas 2 semanas, surgiram em sequência duas vulnerabilidades críticas no kernel Linux, ambas com exploit público e impacto sobre grandes distribuições

• Copy Fail

  • Em 29 de abril, a Xint Code divulgou o Copy Fail
  • A Xint Code é a equipe por trás da Theori, apresentada como um time com 9 vitórias na DEF CON CTF
  • Copy Fail é a CVE-2026-31431, descrita como uma falha lógica direta no subsistema crypto do kernel
  • Diz-se que é 100% confiável sem condição de corrida e que um script Python de 732 bytes consegue obter privilégio de root em todas as distribuições Linux lançadas desde 2017
  • Ubuntu, RHEL, Amazon Linux, SUSE e outras grandes distribuições são afetadas
  • A falha teria sido encontrada com IA, após cerca de 1 hora de varredura automática do subsistema crypto/ do kernel, e estaria exposta havia 9 anos
  • A análise técnica está neste texto da Xint
  • O patch saiu no commit mainline a664bf3d603d, e também havia a mitigação de desativar o módulo algif_aead
  • Depois disso, teriam sido observados indícios de um atacante iraniano usando a vulnerabilidade para comprometer servidores Ubuntu e reaproveitá-los como nós de uma campanha de DDoS
  • Foram necessários apenas alguns dias para uma vulnerabilidade de escalonamento de privilégio no kernel descoberta com IA passar de PoC pública para arma de um ator estatal

• Dirty Frag

  • Cerca de 1 semana depois, em 7 de maio, Hyunwoo Kim(@v4bel) divulgou o Dirty Frag
  • Dirty Frag encadeia a CVE-2026-43284 com a CVE-2026-43500
  • Ele encadeia duas vulnerabilidades nos módulos de rede IPSec ESP (esp4/esp6) e RxRPC do kernel
  • É da mesma família de bugs do Copy Fail e do Dirty Pipe, usando a mesma técnica de corrupção de page cache, mas por um caminho de ataque diferente
  • Dirty Frag continua funcionando mesmo com a mitigação do Copy Fail aplicada
    • Colocar algif_aead em blacklist não impede o Dirty Frag, porque ele não usa esse módulo
  • Segundo a divulgação, ele permite elevar privilégios de usuário sem permissão para root de forma determinística e funciona em Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 e outras distribuições importantes
  • Compilar e executar pode ser feito com um comando de uma linha

• O processo de divulgação do Dirty Frag e o colapso do embargo

  • Hyunwoo Kim reportou para [email protected] em 29 e 30 de abril e enviou publicamente os patches propostos
  • Em 7 de maio, ele coordenou com a lista linux-distros, e foi acordado um embargo de 5 dias
  • No mesmo dia, poucas horas depois, um terceiro sem relação divulgou detalhes de exploit da vulnerabilidade de ESP, quebrando o embargo
  • Após conversar com os mantenedores das distribuições, Hyunwoo publicou a análise completa do Dirty Frag, o código de exploit e um PoC funcional
  • Naquele momento, nenhuma distribuição Linux ainda oferecia patch
  • Até o momento, a CVE-2026-43284, isto é, a parte do ESP, tem correção no mainline, enquanto a CVE-2026-43500, isto é, o componente RxRPC, ainda não teria patch upstream
  • Ubuntu, Red Hat e Tenable, entre outros, publicaram seus próprios alertas

• Exploração real do Dirty Frag

  • A equipe do Microsoft Defender confirmou exploração limitada no mundo real em até 24 horas após a divulgação
  • Segundo o relato, os atacantes obtiveram acesso via SSH, implantaram binários ELF, usaram su para obter root, alteraram configurações de autenticação, apagaram arquivos de sessão e realizaram movimento lateral
  • A CTS(@gf_256) resumiu a situação dizendo: “responsible disclosure is dead🤦”

O que de fato morreu

• A janela de divulgação de 90 dias não é algo que precise ser consertado; é um modelo encerrado
• Esse modelo fazia sentido em um mundo em que descobridores eram raros e o desenvolvimento de exploits era lento, mas os LLMs aumentam o número de descobridores e aceleram o desenvolvimento de exploits
• Se 10 pessoas sem relação encontram o mesmo bug em 6 semanas e a IA consegue transformar um patch diff em exploit funcional em 30 minutos, a janela de 90 dias não protege ninguém
• O Copy Fail saiu de uma varredura com IA para PoC pública e arma de ator estatal em poucos dias
• O Dirty Frag teve o embargo quebrado em poucas horas por causa de um terceiro que encontrou de forma independente a mesma família de bug
• Em um ambiente em que a mesma vulnerabilidade é redescoberta simultaneamente por vários pesquisadores e ferramentas de IA, torna-se difícil manter a coordenação da divulgação
• O ciclo mensal de patches também acabou
  • A janela de 30 dias entre vulnerabilidade e correção presume que o atacante seja mais lento que o trem de releases
  • Quando a Microsoft vê exploração real do Dirty Frag em 24 horas, a janela mensal de manutenção deixa de ser margem de segurança e vira janela de ataque
• O modelo de esperar pelo advisory também acabou
  • Enquanto o defensor lê a descrição do CVE, o atacante está lendo git log --diff-filter=M
  • O advisory é um produto downstream; o sinal real é o patch diff

Como a indústria precisa mudar sua resposta

• A conclusão é que todo problema crítico de segurança deve ser tratado como P0 e corrigido imediatamente
• Não “em até 24 horas”, “na próxima sprint” ou “depois de avaliar o impacto”, mas com nível de prioridade para parar o que estiver sendo feito e corrigir na hora
• Há motivos reais para que deploys em produção sejam complexos e dependam de controle de mudanças, mas o cenário de ameaça não espera pelo processo de change management

• Fornecedores

  • O tempo começa a correr no instante em que chega um relatório de bug crítico
  • O marco não é o fim da triagem nem o momento em que a engenharia assume, mas a chegada do reporte
  • Se alguém reportou, é preciso assumir que outras 10 pessoas já têm o bug e que pelo menos 1 delas não é amigável

• Pesquisadores

  • Não devem reter bugs críticos por longos períodos e precisam pressionar pela janela de divulgação mais curta possível
  • Se o fornecedor não consegue corrigir em 1 semana, isso é problema do fornecedor, não um problema de divulgação
  • A antiga cortesia de “dar tempo” fazia sentido quando você era o único descobridor, mas agora é provável que você não seja

• Gestão de vulnerabilidades

  • A gestão de vulnerabilidades precisa ser em tempo real
  • “Varredura semanal, triagem na sprint, patch no ciclo” é uma linha do tempo em que o atacante já foi embora
  • O novo tempo máximo de resposta para problemas críticos não é de dias, mas de horas — e talvez até isso já seja lento demais

Por que o blue team precisa colocar LLMs no pipeline de defesa

• Os atacantes já integraram LLMs ao pipeline de exploit, e a defesa precisa se mover na mesma velocidade
• É preciso integrar LLMs no momento do push de código
  • Em todo pull request, merge e deploy, deve rodar uma revisão de segurança assistida por IA como parte do pipeline de CI
  • Isso deve rodar no momento do push, como linter e teste unitário, e não em auditorias trimestrais ou checagens posteriores
  • Se há vulnerabilidade, ela precisa ser barrada antes de chegar à produção, e o custo de corrigir em review de PR é muito menor do que corrigir após a publicação de um CVE
• Também é preciso integrar LLMs à análise de patches
  • Quando uma dependência upstream publica um patch de segurança, o pipeline deve buscar automaticamente o diff, analisar a mudança, avaliar se a base de código própria é afetada e levantar alerta
  • Isso deve acontecer automaticamente em minutos, assim que o patch aparecer em um repositório público, sem depender de alguém lendo mailing lists e abrindo ticket no Jira
  • Se a Xint Code encontrou o Copy Fail com 1 hora de varredura automática, também é preciso escanear as próprias dependências dessa forma
• LLMs também devem ser usados no scanning de dependências
  • A cadeia de suprimentos é tão forte quanto sua dependência transitiva mais fraca
  • Um scanner de dependências com IA pode rastrear o impacto de vulnerabilidades na árvore de dependências, marcar versões afetadas e até sugerir caminhos de upgrade
  • Isso deve rodar continuamente, não semanalmente
• Antes de lançar um patch, ele deve ser testado com IA
  • Se, como no caso do React, um LLM consegue transformar um patch em exploit em 30 minutos, o defensor deve validar esse patch com as mesmas ferramentas antes da publicação
  • É preciso confirmar se o patch realmente corrige o problema e se não introduz novos problemas
  • A IA deve ser usada para gerar testes de regressão e verificar se o mesmo padrão existe em outros pontos da base de código
• A janela entre “a vulnerabilidade existe” e “a vulnerabilidade está sendo explorada” está se aproximando de zero, e a defesa também precisa automatizar na mesma velocidade do ataque
• Haverá mais zero-days sendo explorados no ambiente real, mais rápido, por causa das mesmas ferramentas, da barreira de entrada reduzida, do maior número de descobridores e das linhas do tempo mais curtas
• As equipes que sobreviverem a essa transição serão aquelas que transformarem a IA em componente de primeira classe do pipeline de segurança antes de serem empurradas à força para isso

Conclusão

• O novo normal é o administrador de sistemas lendo o advisory do Dirty Frag, sem patch disponível, com exploit já público, a Microsoft relatando exploração real e a mitigação resumida a desativar módulos IPSec, enquanto precisa lidar com 400 servidores
• A política de divulgação de 90 dias, o ciclo mensal de patches e a premissa de que existe tempo entre divulgação e exploração morreram
• O que ainda resta é a capacidade de agir rápido, automatizar agressivamente e tratar bugs críticos como emergências reais
• A onda de IA que quebrou o modelo antigo também torna possível o novo modelo, com patching rápido, varredura automática, inteligência de ameaças em tempo real e revisão de código assistida por IA
• As ferramentas já existem; a questão é se os defensores vão usá-las antes dos atacantes, e neste momento os atacantes estão na frente

[GN⁺]

Opiniões no Lobste.rs

• Concordo meio a contragosto. Na nossa empresa também investigamos esse tema, e o tempo entre patch e exploit é praticamente imediato

• A política de divulgação responsável sempre foi uma ficção em que as pessoas fingiam confiar umas nas outras por educação. Desde o início era algo seguido por convenção, e as ferramentas de descoberta de vulnerabilidades baseadas em LLM só expuseram isso

• É bem irônico que este próprio texto também tenha cara de ter sido escrito por um LLM

  • Faz sentido. Se você tem uma ideia original, precisa publicar antes que outra pessoa faça isso. Pensamento crítico e autorreflexão morreram, e se você não postar no blog 39 minutos depois de ter a ideia, alguém vai fazer isso antes :P
  • Para mim não parece isso. Esse estilo de escrita existe há muito tempo em textos técnicos de antes dos LLMs, e os principais LLMs normalmente escrevem de um jeito um pouco diferente deste texto
  • Parece uma propaganda que apela para o medo
  • Para o bem ou para o mal, agora parece que as coisas simplesmente seguem assim

• Talvez o que morreu tenha sido a era dos programas C artesanais, de boutique, usados em situações de missão crítica