Una cuenta anónima de GitHub publica en masa 0-days no revelados

 (github.com/bikini)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Exploitarium es un repositorio de GitHub que reúne proof-of-concept públicos y textos de investigación sobre vulnerabilidades en un solo lugar, y los nuevos elementos de investigación se agregan como carpetas autocontenidas
  • El repositorio incluye carpetas PoC relacionadas con múltiples proyectos como 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk y VLC
  • Los elementos trasladados desde repositorios PoC individuales conservaron su README original y los archivos rastreados; con base en un fresh GitHub clone del 23 de junio de 2026, se verificaron 12 repositorios y 96 elementos rastreados sin discrepancias
  • La verificación no se hizo con un diff laxo del sistema de archivos, sino comparando datos de Git tree; debían coincidir la ruta relativa, el tipo de objeto Git, el tree mode, el bit de ejecución y el Git blob ID
  • El material del repositorio se describe como investigación pública de vulnerabilidades con fines legítimos, y exige no usarlo con fines maliciosos bajo ninguna circunstancia

Propósito del repositorio Exploitarium

  • Exploitarium es un archivo unificado de proof-of-concept públicos y writeups de investigación sobre vulnerabilidades
  • La mayoría de las carpetas contienen PoC que antes existían como repositorios separados, conservando el README original y los archivos rastreados
  • Los nuevos elementos de investigación se agregan directamente dentro de este repositorio como carpetas autocontenidas
  • La presentación del repositorio incluye la frase “New drops today ;) Biggest thing yet” y el contacto de Discord @ashdfrkl

PoC y elementos de investigación incluidos

  • La tabla Contents del repositorio enumera un total de 23 carpetas
  • Los elementos traídos desde repositorios individuales existentes muestran un commit hash como Source
    • 7zip-rar5-motw-chain-poc
    • anydesk-printer-com-impersonation-poc
    • docker-cp-copyout-destination-escape
    • flowise-mcp-env-case-bypass-poc
    • ghidra-12.1.2-rce-ace-calc-poc
    • gitea-act-runner-container-options-poc
    • imagemagick-gs-delegate-hijack-poc
    • lunar-modrinth-chain-poc
    • mybb-limited-acp-to-admin
    • objdump-dlx-calc-poc
    • openvpn-connect-echo-script-ace-poc
    • vlc-vp9-reschange-crash-poc
  • Los elementos agregados directamente se muestran junto con su fecha
    • c-ares-tcp-uaf-calc-poc: 24 de junio de 2026
    • firefox-smartwindow-private-url-exfil-poc: 24 de junio de 2026
    • floci-apigateway-vtl-rce-poc: 23 de junio de 2026
    • ffmpeg-rasc-dlta-calc-poc: 26 de junio de 2026
    • libssh2-cve-2026-55200-poc: 23 de junio de 2026
    • libssh2-publickey-list-calc-poc: 25 de junio de 2026
    • nghttp2-nghttpx-upgrade-queue-poison-poc: 26 de junio de 2026
    • nmap-ipv6-extlen-wrap-poc: 23 de junio de 2026
    • php857-streambucket-soap-rce-rpoc: 26 de junio de 2026
    • rustdesk-session-permission-pocs: 25 de junio de 2026
    • systeminformer-phsvc-trusted-host-lpe-poc: 24 de junio de 2026

Método de verificación de consolidación

  • Consolidation Check se aplica a los elementos de repositorios individuales existentes listados con commit hash
  • La verificación se realizó sobre un fresh GitHub clone del 23 de junio de 2026, antes de eliminar los repositorios individuales existentes
  • El método de comparación consistió en contrastar el tree de HEAD de cada repositorio individual con la carpeta correspondiente dentro de Exploitarium usando datos de Git tree
  • Cada elemento rastreado debía cumplir las siguientes condiciones
    • misma ruta relativa
    • mismo tipo de objeto Git
    • mismo tree mode, incluido el bit de ejecución
    • mismo Git blob ID
  • Tener el mismo Git blob ID significa que los bytes del archivo rastreado son idénticos

Resultados de la verificación y alcance de la preservación

  • La verificación se realizó sobre 12 repositorios y 96 elementos rastreados, y hubo 0 discrepancias
  • El repositorio preserva el contenido de esos PoC
  • Los metadatos de los repositorios separados permanecen en el historial del repositorio original
    • stars
    • issues
    • pull requests
    • releases
    • separate Git history
  • Los elementos agregados directamente se rastrean mediante el commit history de este repositorio

Restricciones de uso

  • El repositorio indica explícitamente que el material no debe usarse con fines maliciosos en ninguna situación
  • Señala que el propósito del material es la investigación pública de vulnerabilidades con fines legítimos y atraer a más personas a esa área de la ciberseguridad
  • La frase “Cybercrime is cringe” refuerza la prohibición de uso indebido

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News

  • Revisé personalmente lo de Ghidra y no me impresionó mucho: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
    El primero requiere poder sobrescribir un binario en el directorio de herramientas de Swift. Si sobrescribes un binario que ejecuta Ghidra, es obvio que obtendrás ejecución de código.
    Sobre el segundo, no conozco bien TraceRMI, así que es difícil juzgarlo, pero vale la pena señalar que “RMI” significa invocación remota de métodos (Remote Method Invocation).
    El tercero difícilmente puede considerarse una vulnerabilidad; solo muestra que se puede llegar al código nativo del parser de 7zip. Puede haber bugs en el parser de 7zip, pero si no los hay, no significa nada.

    • Le di una mirada a lo de nmap y potencialmente parece poder ser de alta severidad. En la práctica quizá no sea gran cosa, pero como está cerca del código del parser, hay bastantes posibilidades de construir un flujo de saltos.
      Sería irónico poder obtener una shell inversa de alguien que está haciendo un escaneo con nmap. Si tuviera tokens infinitos, le pediría a Claude que escribiera un exploit y luego investigaría el historial para ver quién lo hizo posible.
      Suponiendo, a grandes rasgos, que sea posible la ejecución arbitraria de código (ACE), se acercaría más a un bug que le encantaría a una agencia de inteligencia: por ejemplo, si un observador usa nmap, con algunos paquetes IPv6 podrías alterar el rastro que está observando o acceder a la PC de un investigador que usa nmap.
    • Sería bastante gracioso si todo esto fueran CVE ya conocidos, pero con el próximo Shai-Hulud escondido adentro, esperando a que aficionados de la seguridad lo descarguen apurados y se infecten.
    • Lo de Ghidra es bastante débil, pero revisé lo que me interesaba de c-ares, libssh2 y ffmpeg, y parece que todos funcionan incluso contra los commits upstream más recientes, lo cual es raro.
    • Comentarios como “si sobrescribes un binario que ejecuta Ghidra, obtienes ejecución de código” o “RMI es invocación remota de métodos” me recuerdan a aquella vez que alguien presentó un reporte de vulnerabilidad claramente hecho con vibe coding, afirmando que había encontrado una forma de ejecutar SQL arbitrario.
      El proyecto objetivo era un servidor SQL: https://github.com/tursodatabase/turso/pull/4322
    • Lo de Gitea es algo interesante, pero parece difícil de explotar en la práctica. Tendría sentido si Gitea u otro sistema no aíslan correctamente los trabajos en una VM dedicada.
      GitHub Actions probablemente se comporte de forma similar, y parece que no se considera explotable porque se asume que el usuario ya tiene permisos root locales no aislados por namespaces.

  • Revisé varios con bastante detalle y no fueron tan interesantes. Lo de Docker es simplemente un bug raro, no una vulnerabilidad, y en particular tampoco es algo que amerite llamarse “0-day”.
    Lo de nghttpx en nghttp2 es más interesante y podría usarse para phishing, pero como la cola de solicitudes no es determinista, acertarle a una víctima específica es prácticamente imposible.
    Lo de VLC es simplemente un crash/bug evidente. VLC ya suele crashear con códecs raros, así que no es nada nuevo.
    No sé si me estoy perdiendo algo.

    • Si VLC crasheara en mi computadora, y si tuviera que agradecerle a Dios todos los días por no usar VLC, desenchufaría la máquina de inmediato y pensaría seriamente bajo qué condiciones sería seguro volver a encenderla.

  • Parece que hace falta una nueva categoría tipo 0-days-vibes-vulns. En este valiente nuevo mundo de vulnerabilidades, estaría bueno tener una etiqueta que detecte y gestione los em dash, para que fósiles viejos como yo podamos seguir prestando atención solo a vulnerabilidades artesanales, hechas cuidadosamente a mano.
    Algo como una etiqueta de huevos de gallinas camperas.

    • Es lo que más me molesta del mundo actual. Ahora todos los em dash se tratan como una señal de IA. Antes eran un gran signo de respeto entre nuestra gente.
    • Eso ni siquiera era un em dash, y aun así generó un hilo enorme.
    • “Y por favor no uses M dash al escribir”… el prompt continúa durante una hora divagando sobre resultados de mala calidad.

  • La IA siempre tiende a reportarlo todo como un issue. Porque la “cantidad” de hallazgos se percibe como una medida de inteligencia.
    En revisiones de código pasa lo mismo: reporta muchos no-issues. La salida de Mythos también puede haberse inflado de la misma manera, y quizá lo que sorprendió a la gente fue la cantidad de issues reportados, no su severidad.

    • Soy desarrollador open source y en las últimas dos semanas recibí tres avisos de “CWE”. Todos eran correctos, pero eran cosas muy menores, como “si este archivo de log de debug es un enlace simbólico, se puede sobrescribir un archivo” o “si un usuario puede meter códigos de pantalla OSC en la salida de Git, puede escribir datos arbitrarios en la pantalla”.
      Estos modelos de IA están haciendo que todo suene como un exploit. No sé si eso es bueno para el ecosistema.
      Ahora miro todo lo que llega con más sospecha: ¿es un exploit real, o están acumulando méritos para decir “la semana pasada abrimos 39 CWE; contrata a nuestra empresa de ‘seguridad’ para auditar tu código”?
    • Eso no coincide con lo que escuché de personas que trabajaron directamente con Mythos. Me dijeron que las vulnerabilidades generadas en general eran reales y significativas.

  • ¿Todo esto son 0-day reales? Muchos parecen venir de CVE ya publicados o de código ya corregido upstream.
    Hoy en día el término “0-day” ha perdido casi todo su significado, y parece que mucha gente lo usa para referirse a cualquier exploit.

    • El repositorio afirma esto:
      “Es un archivo único de PoC de exploits públicos y artículos de investigación de vulnerabilidades. Al momento en que los subo, nada ha sido reportado. Puedes reportarlos tú y llevarte el crédito cuando salga el CVE, lulz. No los abuses. Hago esto para atraer a más gente al campo, y siempre he considerado que este método es el más eficiente”.
      En términos generales, eso se acerca bastante a la definición de zero-day. Que el contenido del repositorio coincida con esa afirmación es un asunto completamente distinto.
    • En este tipo de situaciones, incluso RCE perdió significado. Si la parte de “remoto” realmente significa algo, normalmente implica algo como una sesión SSH como root.

  • A medida que la IA se vuelva lo suficientemente sofisticada como para encontrar este tipo de cosas, vamos a ver una avalancha de material así por un tiempo. Creo que disminuirá de forma natural cuando se corrijan las vulnerabilidades reales.
    Claro, siempre quedará algo, pero espero que el nivel baje y que los exploits que se encuentren sean cada vez más complejos. Ahora estamos en una etapa de transición.

    • Creo que la expresión “la IA se vuelve lo suficientemente inteligente como para encontrarlas” lleva a malentendidos. No es que se esté “volviendo más inteligente”, sino que se está ajustando mejor a usos específicos, con datasets mejor curados, mejores harnesses, mejores prompts, mejor etiquetado de resultados y más documentación de fracasos y éxitos.
      Espero que los resultados mejoren en general, pero este tipo de expresiones antropomórficas hacen que parezca que la IA misma cambia o evoluciona de alguna manera.
      En realidad, quienes la están mejorando activamente son la academia que hace investigación básica, la industria que la comercializa y los investigadores de seguridad que empaquetan herramientas y procesos como servicios. No existe un “eso” independiente.
    • Parece que ya estamos en medio de esa etapa, pero más que disminuir, los “reportes” se han vuelto más ruidosos y ambiguos, lo que hace más difícil evaluar el nivel real de amenaza o los vectores de ataque.
    • Toda actualización de software crea o reintroduce vulnerabilidades de ese tipo.
    • Sinceramente, la complejidad de ejecución también se está volviendo una barrera cada vez más baja con el tiempo.

  • Parece que alguien está corriendo un modelo de lenguaje grande y publicando los resultados. Da esa impresión porque hay una mezcla amplia, desde cosas ridículas como “¡si cambias el binario del sistema, ejecución arbitraria de código!” hasta otras que podrían ser reales.
    Es el tipo de resultado que suele salir si le das a un LLM un prompt como “encuentra exploits y escribe PoC”.
    Si lo entrenaran con los reportes de Metasploit de los últimos 15 años, creo que podría encontrar los mismos bugs que la gente volvió a escribir en código nuevo.
    [1] https://en.wikipedia.org/wiki/Metasploit

  • Hay una frase que dice que bajo ninguna circunstancia se debe usar maliciosamente el material de este repositorio. Dice que es investigación de vulnerabilidades publicada con buenas intenciones y que busca que más personas se interesen por explorar este campo de la ciberseguridad.
    Me recuerda a un mensaje antes de alguna receta de The Anarchist Cookbook, algo como “esto es realmente peligroso, nunca lo hagas. Así es como se hace”.

    • ¿No era que en el libro viejo no aparecía lo de “…maliciosamente”?

  • Como vulnerabilidades de seguridad, no son muy impresionantes. Diría que la mayoría son simplemente bugs.

    • No estoy de acuerdo. La ejecución de código en FFmpeg es realmente terrible.
    • Toda vulnerabilidad, al final, no es más que un bug.

  • Parece una mezcla de copias reescritas de CVE existentes y cosas nuevas de baja severidad. Digo baja severidad porque parece que el usuario ya tendría que hacer algo inherentemente riesgoso.
    Es mi opinión rápida de 2 centavos tras echarles un vistazo.
    Aun así, sí son hallazgos interesantes. Creo que algunos podrían volverse más graves si se encadenan.
    Por ejemplo, con lo de ovpn quizá se podría combinar el registro de una app de VPN como aplicación predeterminada para abrir archivos en Windows, o como manejador de protocolo para ubicaciones URL tipo openvpn://, con un iframe y algo de ingeniería social ingeniosa. Es solo una idea que se me ocurrió.

    • Ese es el punto confuso. Algunos parecen ruido de bajo nivel, pero otros son realmente críticos.
      Los casos de Floci, libssh2, c-ares, FFmpeg y PHP parecen todos reales.
      En cambio, el de Ghidra no tanto. Me pregunto si esto no era una carpeta de investigación a medio hacer que simplemente publicaron tal cual.