Un usuario anónimo de GitHub, bajo el pseudónimo “bikini”, ha publicado una colección denominada “exploitarium” que contiene 204 archivos de prueba de concepto de vulnerabilidades zero-day. Estos afectan a decenas de proyectos de código abierto y fueron expuestos antes de que los proveedores pudieran lanzar los parches correspondientes, alterando así el proceso habitual de divulgación coordinada.

Un usuario anónimo de GitHub ha reunido discretamente una de las colecciones de exploits más disruptivas del año, lanzando 204 archivos de prueba de concepto (PoC) de zero-day para docenas de proyectos de código abierto antes de que los proveedores tuvieran la oportunidad de parchearlos.

El archivo, alojado bajo el nombre “exploitarium” por un investigador que utiliza el alias “bikini”, dio un giro total a la divulgación coordinada al publicar primero el código del exploit y dejar que los proveedores y defensores se pusieran al día en público.

Lo que inicialmente parecía un pico de atención efímero ha evolucionado, en cambio, en un repositorio creciente que continúa añadiendo nuevos proyectos vulnerables semana tras semana.

El archivo exploitarium empezó a tomar forma a finales de junio de 2026, con entradas fechadas desde el 23 de junio y un primer lote público masivo que generó un gran tráfico alrededor del 27 de junio.

A medida que se acumulaban los problemas y las solicitudes de extracción (pull requests), el archivo README del repositorio dejó claro que ninguno de los hallazgos había sido reportado a los proveedores afectados con antelación, y alentó explícitamente a otros a reclamar la autoría divulgándolos de forma independiente.

Analistas de LevelBlue SpiderLabs señalaron que este enfoque puso el código del exploit frente a atacantes y defensores simultáneamente, eliminando la ventana de protección que las divulgaciones coordinadas están diseñadas para proporcionar.

Desde ese estallido inicial de atención, el proyecto ha seguido expandiéndose mientras que la mayoría de la cobertura pública avanzaba hacia otros temas.

LevelBlue dijo en un informe que las nuevas carpetas han llegado a un ritmo constante de aproximadamente dos a tres por semana, incluyendo adiciones recientes contra plataformas ampliamente desplegadas como PostgreSQL, Redis, Nextcloud y Discourse solo en la primera semana de julio.

Detrás de la cifra titular de “130 PoCs” citada en los primeros informes, el recuento de SpiderLabs muestra ahora 35 carpetas de proyectos rastreados con 204 archivos, lo que refleja cuánta investigación se ha incorporado al archivo después de que se publicaran las primeras historias.

La superficie de ataque expuesta por estos PoC abarca mucho más que un solo stack o proveedor. Bases de código nativas de C y C++, controladores de kernel, lógica de aplicaciones web, herramientas de acceso remoto como AnyDesk y RustDesk, e infraestructura básica como Nmap y curl aparecen en el inventario.

Esta amplitud convierte el incidente tanto en un problema de la cadena de suministro como en una historia de vulnerabilidades, ya que muchas organizaciones pueden heredar librerías explotables como dependencias transitivas sin darse cuenta de que están ahí.

Investigador anónimo lanza 204 archivos de exploits 0-Day

El lanzamiento anónimo coincide estrechamente con un patrón que LevelBlue ya había visto este año en la campaña Nightmare-Eclipse, pero con un alcance más amplio y sistemático a través de los ecosistemas de código abierto.

Mientras que Nightmare-Eclipse se centró en un solo proveedor y en los internos de Windows, exploitarium impulsa la divulgación masiva hacia herramientas de desarrollador, servicios preparados para la nube, plataformas de contenedores y foros comunitarios.

Para quienes siguieron la cobertura anterior sobre la explotación de Windows Defender, los artículos sobre el nuevo exploit 0-Day RoguePlanet de Windows Defender y la afirmación de que el parche de RoguePlanet Defender podría filtrar datos muestran qué tan rápido los lanzamientos no coordinados pueden traducirse en un riesgo operativo complejo.

Dentro de exploitarium, no todas las carpetas tienen la misma importancia, y la evaluación de LevelBlue recalca que los defensores deben evitar tratar todo el archivo como uniformemente crítico.

Muchas entradas parecen artefactos de bajo impacto provenientes de ejecuciones de fuzzing automatizadas, mientras que otras documentan fallos de alta severidad y pre-autenticación en componentes ampliamente embebidos.

Un ejemplo destacado es el CVE-2026-55200 en libssh2, una escritura fuera de límites en la función ssh2_transport_read que puede activarse antes de que se complete cualquier autenticación SSH, permitiendo potencialmente la ejecución remota de código contra clientes vulnerables.

Cyber Security News (CSN) cubrió previamente este error en detalle en su pieza sobre la vulnerabilidad crítica de libssh2 y en un seguimiento sobre el PoC del exploit de vulnerabilidad RCE de libssh2, mostrando cómo una sola entrada del archivo puede repercutir rápidamente en escenarios de ataque del mundo real.

El caso de libssh2 también ilustra la confusa superposición entre la divulgación coordinada y la no coordinada.

Aunque exploitarium incluyó un PoC de libssh2 desde el primer día, el crédito oficial del CVE fue para el investigador Tristan Madani a través de los canales normales de reporte de VulnCheck, lo que significa que el mismo defecto subyacente surgió a través de rutas tanto de divulgación responsable como masiva.

Para los defensores, ese matiz importa menos que la conclusión práctica: rastrea la corrección upstream, migra a una versión que incorpore el commit 97acf3d y trata la amplia huella transitiva de la vulnerabilidad como una prioridad, independientemente de si la explotación ha sido confirmada.

De archivo solitario a riesgo compartido

Con el tiempo, exploitarium ha pasado de ser un archivo personal a una oficina de compensación ligeramente moderada que acepta investigaciones externas.

LevelBlue señala contribuciones como el Pull Request 4 del usuario “Unrealisedd”, que introdujo nuevos problemas en el controlador del kernel de Windows en el componente ovpn-dco-win de OpenVPN, junto con sugerencias de remediación.

El mantenedor también acreditó retroactivamente el trabajo externo en objdump, reconociendo que otro investigador había publicado un PoC más completo por separado antes de que el hallazgo se incorporara al archivo.

Para las organizaciones que se preocupan por la procedencia, esta mezcla de verificación cuidadosa del árbol de Git y evaluación informal de colaboradores significa que exploitarium ahora amplifica código no verificado con la credibilidad implícita de su creciente colección.

La guía de LevelBlue para los equipos de seguridad y detección se centra en un triaje pragmático bajo presión. Parchea primero y clasifica los elementos por accesibilidad y radio de impacto, no solo por la atención mediática o la novedad del PoC.

Recomiendan ejecutar análisis de composición de software en los pipelines de construcción, imágenes de contenedores y librerías de proveedores para encontrar dependencias ocultas de libssh2 y otros componentes embebidos afectados por el archivo.

En paralelo, destacan esfuerzos comunitarios como el proyecto Exploitarium-Detections, que publica reglas KQL para Microsoft Sentinel y Defender XDR para detectar actividad asociada a las vulnerabilidades divulgadas.

Para las organizaciones que ya están rastreando incidentes recientes de la cadena de suministro, como el ataque de paquetes npm de Mastra comprometidos, exploitarium debe leerse como parte de la misma tendencia general: repositorios de investigación que pueden convertir instantáneamente zero-days teóricos en kits de ataque accesibles.

El informe de LevelBlue subraya que exploitarium “no es un incidente discreto con una fecha de inicio y fin”, sino una infraestructura continua que probablemente seguirá generando tanto hallazgos genuinos como carga de triaje mientras se mantenga.

El mantenedor ya ha emparejado el archivo con un kit de herramientas de ofuscación de código de propósito general, subrayando que se trata de un flujo de investigación activo y no de una maniobra de divulgación puntual.

Para los equipos ejecutivos, el enfoque recomendado se asemeja más a una exposición de la cadena de suministro a largo plazo que a una sola vulnerabilidad, lo que exige un monitoreo sostenido, la adopción rápida de parches y una reevaluación continua de qué componentes de código abierto están discretamente empaquetados en las cargas de trabajo críticas.

Indicadores de Compromiso (IoCs):-

Nota: Las direcciones IP y los dominios han sido desactivados intencionadamente (ej., [.]) para evitar la resolución accidental o el hipervínculo. Solo reactívalos dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.