Conta anônima no GitHub despeja em massa 0-days não divulgados

Escopo e qualidade dos exploits

• Muitos leitores inspecionam PoCs específicos (Ghidra, Docker, VLC, c-ares, libssh2, FFmpeg, PHP, nmap, Gitea) e encontram uma grande mistura:
  • Alguns parecem genuinamente sérios (por exemplo, UAF no c-ares, libssh2, RCE no FFmpeg, alguns problemas de parsing no nmap, certos bugs de Rustdesk/lógica).
  • Outros são triviais, mal classificados ou exigem condições já perigosas (sobrescrever binários em disco, já ter execução de código em PHP, código apenas de teste, casos que só causam crash).
• Vários observam que “RCE” às vezes é usado de forma vaga (por exemplo, sessão SSH como root, ou “execução de código leva a execução de código”), e que muitos itens parecem mais bugs genéricos do que vulnerabilidades de alto impacto.

O que conta como um “0-day”

• Há desacordo sobre a definição:
  • Um lado: “0-day” significa “explorado em ambiente real antes de o fornecedor ou o público saber”.
  • Outro: “exploit de 0-day” se refere a um exploit disponível enquanto o fornecedor teve zero dias para corrigir; então “vulnerabilidade 0-day” seria qualquer vulnerabilidade afetada por tal exploit.
• Alguns argumentam que o termo está sendo inflado e usado em excesso para significar “qualquer bug não publicado”.

LLMs, fuzzing e automação

• Forte suspeita de que um LLM ou um harness automatizado gerou muitas das descobertas, dado o volume, o estilo e a mistura de bons e maus resultados.
• Alguns afirmam que os modelos fortes atuais já conseguem encontrar grandes quantidades de bugs reais; outros reclamam que relatórios gerados por IA frequentemente exageram a severidade ou sinalizam não-problemas.
• O README atualizado do repositório (segundo a discussão) afirma um fluxo de fuzzing personalizado automatizado por um modelo de IA sob um harness rígido.

Código aberto vs segurança por obscuridade

• Um lado teme que código aberto somado a LLMs torne a descoberta massiva de exploits fácil demais e reviva o interesse em “segurança por obscuridade”.
• Outros contrapõem:
  • Atacantes podem fazer engenharia reversa de binários de qualquer forma.
  • Código aberto se beneficia de muitos olhos e de auditoria assistida por IA.
  • Só uma parte precisa de um modelo forte para reforçar OSS, enquanto código proprietário coloca as ferramentas de um único fornecedor contra as ferramentas de todos os atacantes.

Ética da divulgação e carga para defensores

• Alguns veem a divulgação pública em massa de PoCs sem aviso ao fornecedor como irresponsável, argumentando que os usuários — não os mantenedores — assumem o risco.
• Outros dizem:
  • A divulgação responsável é lenta demais, muitas vezes não é recompensada e às vezes é recebida com ameaças legais.
  • Despejos públicos evitam uso exclusivo por governos ou no mercado negro e podem forçar práticas melhores (por exemplo, red-teaming com IA antes do lançamento).
• Engenheiros de segurança reclamam do “ruído” de relatórios de baixa severidade ou fabricados por IA, mas reconhecem que pequenos bugs às vezes podem se encadear em caminhos de exploração sérios.

Contexto de segurança mais amplo

• Discussões paralelas cobrem:
  • Fragilidade da identidade baseada em SSN/número bancário nos EUA e fraudes via ACH.
  • Risco de sequestro/físico em torno de holdings de cripto.
  • A necessidade de fazer sandbox de parsers de alto risco (players de mídia, motores de AV, analisadores de rede, runners de CI) e de assumir que ferramentas como nmap, VLC e Wireshark são alvos de alto valor.