Cuenta anónima de GitHub publica masivamente 0-days no divulgados

Alcance y calidad de los exploits

• Muchos lectores inspeccionan PoCs específicos (Ghidra, Docker, VLC, c-ares, libssh2, FFmpeg, PHP, nmap, Gitea) y encuentran una amplia mezcla:
  • Algunos parecen genuinamente serios (p. ej., UAF en c-ares, libssh2, RCE en FFmpeg, algunos problemas de parseo de nmap, ciertos errores de Rustdesk/lógica).
  • Otros son triviales, están mal clasificados o requieren condiciones ya de por sí peligrosas (sobrescribir binarios en disco, ya tener ejecución de código en PHP, código solo de prueba, casos solo de crash).
• Varios señalan que “RCE” a veces se usa de forma laxa (p. ej., sesión SSH root, o “la ejecución de código lleva a ejecución de código”), y que muchos elementos parecen más bien bugs genéricos que vulnerabilidades de alto impacto.

Qué cuenta como un “0‑day”

• Discrepancia sobre la definición:
  • Un grupo: “0‑day” significa “explotado en la naturaleza antes de que el proveedor o el público lo supiera”.
  • Otro: “exploit de 0‑day” se refiere a un exploit disponible mientras el proveedor ha tenido cero días para parchear; una “vulnerabilidad 0‑day” sería entonces cualquier vulnerabilidad afectada por ese exploit.
• Algunos sostienen que el término se está inflando y usando en exceso para significar “cualquier bug no publicado”.

LLMs, fuzzing y automatización

• Fuerte sospecha de que un LLM o un arnés automatizado generó muchos de los hallazgos, dada la cantidad, el estilo y la mezcla de resultados buenos y malos.
• Algunos afirman que los modelos potentes actuales ya pueden encontrar grandes cantidades de bugs reales; otros se quejan de que los informes impulsados por IA suelen exagerar la gravedad o señalar no-incidencias.
• El README actualizado del repo (según la discusión) afirma un flujo de fuzzing personalizado automatizado por un modelo de IA bajo un arnés estricto.

Open source vs seguridad por oscuridad

• Un bando teme que el código abierto más los LLM hagan demasiado fácil el descubrimiento masivo de exploits y reaviven el interés por la “seguridad por oscuridad”.
• Otros replican:
  • Los atacantes pueden hacer ingeniería inversa de binarios de todos modos.
  • El open source se beneficia de muchos ojos y de auditoría asistida por IA.
  • Solo una parte necesita un modelo potente para endurecer OSS, mientras que el código propietario enfrenta las herramientas de un único proveedor contra las herramientas de todos los atacantes.

Ética de la divulgación y carga para los defensores

• Algunos ven irresponsable publicar masivamente PoCs sin aviso al proveedor, argumentando que los usuarios —no los mantenedores— asumen el riesgo.
• Otros dicen:
  • La divulgación responsable es demasiado lenta, a menudo no se recompensa y a veces se responde con amenazas legales.
  • Los volcados públicos evitan el uso exclusivo por parte de gobiernos o del mercado negro y pueden forzar mejores prácticas (p. ej., red-teaming con IA antes del lanzamiento).
• Los ingenieros de seguridad se quejan del “ruido” de informes de baja severidad o fabricados por IA, pero reconocen que pequeños bugs a veces pueden encadenarse en rutas de explotación serias.

Contexto más amplio de seguridad

• Las conversaciones laterales cubren:
  • La fragilidad de la identidad basada en SSN/número bancario en EE. UU. y el fraude vía ACH.
  • Riesgos de secuestro/físicos en torno a tenencias de criptomonedas.
  • La necesidad de aislar en sandbox parsers de alto riesgo (reproductores multimedia, motores AV, analizadores de red, runners de CI) y de asumir que herramientas como nmap, VLC y Wireshark son objetivos de alto valor.