exploit-garbage/0day-rubbishRedefiniendo la divulgación de vulnerabilidades en la era de la IA. Producimos en masa 0days explotables y los divulgamos directamente, utilizando presión impulsada por eventos para elevar los estándares de seguridad de los proveedores y avanzar en el campo.
# 0day Rubbish
> **Las vulnerabilidades 0day se han convertido en basura en la era de la IA.**
[](./LICENSE)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com)
[](https://github.com/Exploit-Garbage/0day-Rubbish/subscription)
[](https://github.com/Exploit-Garbage/0day-Rubbish/discussions)
[](https://github.com/Exploit-Garbage/0day-Rubbish/commits)
**🌐 Sitio web oficial**: <https://0day-rubbish.com/blog>
---
## 🎯 Por qué existe esto
La divulgación tradicional de vulnerabilidades está rota. Es lenta, burocrática e ineficaz. En la era de la IA, podemos producir 0days en masa a escala, lo que hace que las vulnerabilidades individuales sean menos valiosas pero más impactantes cuando se divulgan directamente.
Creemos que el **endurecimiento de seguridad basado en eventos** es el enfoque más eficaz: solo cuando los proveedores se enfrentan a amenazas reales y explotables priorizan las correcciones.
## 🔄 Nuestro proceso de divulgación
### Paso 1: Descubrimiento con IA
Nuestros sistemas automatizados de IA escanean continuamente en busca de vulnerabilidades en software del mundo real, identificando posibles 0-days mediante análisis de patrones, fuzzing y revisión inteligente de código.
### Paso 2: Verificación y desarrollo de PoC
Cada hallazgo se somete a validación manual. Desarrollamos exploits de prueba de concepto funcionales para confirmar la explotabilidad y evaluar el impacto en el mundo real.
### Paso 3: Divulgación pública periódica
Cada semana —lunes o martes— divulgamos un nuevo lote de vulnerabilidades 0-day verificadas y explotables que hemos descubierto y validado:
- Análisis técnico completo y causa raíz
- Código de exploit PoC funcional
- Versiones y sistemas afectados
- Evaluación del impacto
- Mitigaciones recomendadas
Sin retrasos. Sin burocracia. Solo hechos.
**A todos los proveedores**: Esperamos que puedan completar las correcciones antes de que los hackers exploten estas vulnerabilidades.
## ⚡ Principios fundamentales
- **Solo impacto en el mundo real**: Solo divulgamos vulnerabilidades que afectan a sistemas del mundo real con bases de usuarios reales
- **Sin objetivos sin valor**: Se excluyen las vulnerabilidades no explotables o los dispositivos con una adopción de usuarios insignificante: son basura sin ningún valor
- **Velocidad por encima del protocolo**: La divulgación directa impulsa una acción más rápida que los canales tradicionales
- **Pruebas por encima de afirmaciones**: Cada divulgación incluye exploits funcionales
- **Impacto por encima de cantidad**: Enfoque en vulnerabilidades de alta gravedad y ampliamente desplegadas
- **Transparencia**: Detalles técnicos completos, sin agendas ocultas
- **Sin ánimo de lucro**: Impulsado por la pasión por la investigación de seguridad, no por el beneficio económico
## 🤝 Colaboración
Colaboramos con:
- Proveedores líderes de modelos de IA que impulsan la investigación de seguridad automatizada
- Investigadores de seguridad que exploran el descubrimiento impulsado por IA
## 🤖 Modelos de IA utilizados
Nuestro descubrimiento automatizado de vulnerabilidades aprovecha modelos de lenguaje de gran tamaño de vanguardia de proveedores líderes de IA:
- **Anthropic (Claude)** - Reconocimiento y razonamiento profundo de patrones de seguridad
- **OpenAI** - Razonamiento avanzado y análisis de código
- **DeepSeek** - Detección especializada de vulnerabilidades
- **Z.ai (GLM)** - Análisis de código de contexto largo
- **Moonshot (Kimi)** - Análisis de seguridad de contexto largo
---
## 📋 Vulnerabilidades divulgadas
Un proceso de investigación impulsado por IA (conjunto multi-LLM: Claude, OpenAI, DeepSeek, GLM, Kimi) descubre 0-days en software empresarial del mundo real. Cada aviso a continuación incluye un **análisis completo de la causa raíz** más un **script de exploit funcional y reproducible**: sin informes de solo detección, sin detalles ocultos.
### Último lote — Lote 16 (6 avisos)
*Seis hallazgos que requirieron los propios instrumentos del auditor para demostrarse, y ninguno de los cuales afirma más de lo que los instrumentos mostraron: un par de cargas anónimas contra un endpoint PHP que nunca superó su modelo de autenticación de la era de 2007; el endpoint de diagnóstico de un demonio de enrutamiento que invirtió su propio validador de nombres de host; un router de consumo cuyo campo de instalación de aplicaciones SOAP se convirtió en un shell; y tres puntos de entrada separados en la superficie de configuración construida con shell de un router celular industrial. Cuatro de los seis publican una cifra inferior a la que sugería el registro de origen sin procesar, y cada una de esas rebajas se imprime con su aritmética junto a la puntuación que corrige.*
| # | Producto | Versión afectada | CVSS | Clase | Aviso y PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | La acción SOAP InstallApp en el plano de gestión del lado LAN construye un comando de shell `rm -rf` sobre el argumento `apName`; una sustitución `$(...)` alcanza la pila web configurada como root antes de que se resuelva la palabra del comando | [InstallApp apName → sustitución de comando de shell](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | Un endpoint de carga con `copy()` sin sesión, sin restricción de extensión y sin comprobación de ruta, que continúa un patrón de aterrizaje en la raíz web que la línea descontinuada del proveedor hizo famosa; un único par de solicitudes anónimas escribe una página ejecutable y la recupera | [upload.php → escritura en la raíz web → ejecución de código del lado web](https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce) |
| 3 | Raritan PX3 PDU G4 | firmware 4.3.14 | **8.8** \* | Un manejador de diagnóstico `ping`/`traceroute` cuyo validador de nombres de host invierte su propia comprobación de retorno, accesible por toda sesión autenticada ordinaria, mientras que `netstat` lleva un atributo exclusivo de administrador que el par de diagnóstico no tiene | [diag ping → inversión del valor de retorno → inyección de shell](https://0day-rubbish.com/blog/raritan-px3-pdu-g4-diag-ping-traceroute-command-injection) |
| 4 | Moxa MAR-2000 FWR_MAR2000 V1.0 Build 15010909 | V1.0 Build 15010909 | **7.2** \* | La tabla de programas de la interfaz de gestión pasa su campo `argument` directamente a la línea de comandos del lanzador de programas de usuario | [Argumento de Executer → inyección en el lanzamiento de programas](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (mismo producto, mismo lote) | V1.0 Build 15010909 | **7.2** \* | Cinco manejadores separados de `ipsec.py` invocan comandos de gestión de rutas que llevan texto del atacante desde los campos de dirección del túnel; los hallazgos de un producto nunca se dividen entre lotes | [dirección del túnel → shell de gestión de rutas](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (mismo producto, mismo lote) | V1.0 Build 15010909 | **7.2** \* | Un motor de escenarios reevalúa periódicamente una condición `ping` guardada, y el hilo vuelve a formar el comando de shell en cada pasada, de modo que una carga almacenada se ejecuta sin que el atacante reenvíe ninguna solicitud | [ping de escenario → hilo de auto-ejecución](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* Los seis publican más de una lectura. Cada aviso incluye las lecturas que rechazó o hizo condicionales junto a la que defiende, cada una con su propio vector y aritmética:
> - **Hallazgo 1** — **6.8** publicado en `AV:A/PR:H`: ningún artefacto entregado evidencia exposición del lado WAN, y la acción pertenece al nivel de administrador, por lo que ambas mitades de la lectura ingenua de 8.8-y-en-red cayeron ante las comprobaciones de artefactos, y el propio 8.8 del registro de origen se muestra internamente como la variante PR:L con su aritmética, no como el titular. `AV:N` en 7.2 es el condicional etiquetado para despliegues cuyo plano de gestión está deliberadamente expuesto.
> - **Hallazgo 2** — **9.8** en `PR:N`. Un único par de peticiones anónimas; la capa web vuelve a servir lo que escribió. La ejecución aterriza como la cuenta de servicio web del entorno de replicación y se reporta exactamente como tal: la identidad del servicio del lado del dispositivo nunca se midió y no se afirma. `S:C` en 10.0 se imprime con aritmética y se rechaza; un `AV:A` 8.8 es el condicional etiquetado para el aislamiento de la VLAN de gestión; una advertencia de identidad de dispositivo desconocida se imprime de forma prominente en el Resumen y se repite en el nombre de archivo y el texto: ninguna afirmación de "root" o "system" se incluye en ningún lugar del titular, slug o cuerpo de este hallazgo. El linaje de carga del modelo de familia en la línea descontinuada del proveedor se describe como un patrón sin ningún identificador, conforme a la regla interna de esta serie de avisos.
> - **Hallazgo 3** — **8.8** en `PR:L`: la asimetría de atributos entre `netstat` y diagnósticos tal como se entrega es el artefacto que demuestra que cualquier sesión ordinaria es la clase de principal prevista; el par de cuentas predeterminadas de fábrica se divulga como una debilidad adyacente separada con su propia lectura condicional `PR:N` 9.8, nunca como el vector de este hallazgo. `PR:H` en 7.2 se imprime y se rechaza.
> - **Hallazgos 4-6** — los tres **7.2** en `PR:H`, impresos con la corrección de que el 8.8 del registro de origen es la aritmética `PR:L` bajo la regla corregida de la familia de relaciones 881, mostrada junto como aritmética de variante rechazada. Los tres condicionales de credenciales predeterminadas de fábrica (9.8 cada uno, si no se modifican) están etiquetados, nunca como titular, y `S:C` 9.1 se imprime y se rechaza para los tres. Los tres llevan el resultado negativo honesto de que una carga útil con punto y coma en el sumidero scenario-ping falla y bloquea el hilo evaluador, por lo que las formas funcionales (`$(...)`, nueva línea) se imprimen junto con la prueba.
> - **Límite de verificación, declarado de forma uniforme** — cada marcador de sandbox `uid=0` en este lote es una propiedad del entorno de replicación usado para probarlo, y donde una imagen entregada configura su propia pila web como root, eso es un hecho dentro de la imagen impreso como tal. Ningún hallazgo reclama en su matriz la identidad del lado del dispositivo, y no se hace ninguna afirmación sobre dispositivo en vivo en ningún lugar de este lote: tres hallazgos se probaron mediante `replicación a nivel de sumidero en un sandbox aislado alojado en la nube`, uno (Crystal Server) mediante una cadena HTTP de extremo a extremo dentro de su propia imagen de VM, uno (PX3) a nivel de instrucción a partir de la imagen y replicación a nivel de comando del sumidero (sin extremo a extremo; la cadena RPC→cfgd→hardware no se completaría bajo emulación), y uno (RAX120) mediante desensamblado del camino de petición a nivel de instrucción más replicación nativa con gcc del sumidero para tres marcadores mutuamente independientes más un control benigno.
> - **Afirmaciones de root e identidad, verificadas una por una**: el 9.8 publicado (`Hallazgo 2`) explícitamente no afirma root ni system; las afirmaciones del slug de los `Hallazgos 4-6` publicados se detienen en "shell-injected into the management stack", con la identidad del sandbox de replicación divulgada como el origen de las líneas `uid=0`; el slug y las afirmaciones en línea del hallazgo RAX120 son los únicos del lote que contienen la palabra root, y ambas anclas son la configuración `User root` de lighttpd dentro de la imagen más tres marcadores de id cero y un control, nunca un dispositivo en vivo.
**Totales**: 6 avisos · 4 productos · 4 organizaciones proveedoras (NETGEAR, NUUO, Raritan/Legrand, Moxa), con la serie MAR-2000 portando tres de ellos porque los hallazgos calificados de un producto nunca se dividen entre lotes · 1 cadena no autenticada · 5 cadenas autenticadas, de las cuales cuatro requieren explícitamente una sesión de clase administrador y una cualquier sesión ordinaria. Un único 6.8 porta el titular del espacio de marca famosa, y ese es deliberadamente el número menos dramático del lote: `AV` y `PR` cayeron ambos a lo que los artefactos entregados probaron, en lugar de lo que sugiere la plantilla del modelo ingenuo, y los `Totales` publicados lo dicen sin rodeos. Cuatro de los seis publican al menos una cifra inferior a la que sugería el registro fuente en bruto —un lado WAN sin evidencia por partida doble, un nivel PR mal introducido por cuadruplicado— y cada una de esas degradaciones se imprime donde el lector la verá, con la aritmética rechazada, el vector, la justificación y el historial de corrección junto a la puntuación superviviente.
**Lo que los instrumentos mostraron realmente** — se declara porque la credibilidad del lote descansa exactamente en esto:
- **Dos cadenas de extremo a extremo, cuatro hasta el sumidero.** El Hallazgo 2 ejecutó un par completo de solicitudes HTTP anónimas contra la propia imagen de VM del proveedor y confirmó la ejecución de la página escrita; el manejador `diag` del Hallazgo 3 se verificó a nivel de instrucción a partir del firmware publicado, además de la inyección a nivel de comando de tres formas de payload con un control benigno; los Hallazgos 4-6 se verificaron mediante análisis de firmware-fuente más replicación de shell con gcc nativo de cada construcción exacta del sumidero, marcadores y controles benignos incluidos; el Hallazgo 1 se verificó en la línea de ruta de solicitud en el desensamblado y luego mediante replicación del sumidero con gcc nativo para tres marcadores independientes más un control benigno. No se afirma ninguna conclusión de extremo a extremo para ningún hallazgo no en vivo, y la fila del README del lote para cada uno dice "desensamblado" o "replicación" con todas las palabras.
- **Punto de observación, uniformemente:** las solicitudes o ejecuciones nunca cruzaron un límite de red no confiable en ningún hallazgo de este lote. Cuando un hallazgo afirma un alcance más amplio que el entorno de replicación, esa afirmación está anclada a un artefacto entregado —un binding en la imagen o una configuración de pila web en la imagen— y lo dice con esas palabras.
- **Lo que nuestro propio arnés aportó** — porque un estado que creamos no es un valor predeterminado del producto: el entorno del host de replicación (identidades de cuenta del sandbox medidas como una propiedad del host, luego reflejadas en las afirmaciones de los hallazgos sobre lo que NO se afirma del lado del dispositivo); los controles benignos que separan un hallazgo de un accidente; los marcadores de cierre de un solo uso (una ventana unidireccional) donde un punto de entrada se cierra tras el primer uso.
*Cada lote anterior y sus avisos están listados en [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
*Cada lote anterior y sus avisos están listados en [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
---
## 🔁 Una serie en curso — Divulgaciones semanales
Esta es una **serie de divulgación continua**. Gracias a la optimización continua, el pipeline de descubrimiento impulsado por IA ahora produce nuevos hallazgos 0-day a un ritmo diario estable, y divulgamos lotes verificados con una **cadencia semanal**.
- **Último lote**: Lote 16 — 6 avisos; acumulado 144 en 16 lotes
- **Próxima entrega**: cada lunes o martes
- **Alcance futuro**: expandiéndose más allá de la TI empresarial hacia sistemas **ICS / SCADA, energía y aeroespaciales**
Si quieres captar la próxima entrega en el momento en que llegue:
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star** para guardar en marcadores · 👁 **Watch** (personalizado → Releases + Discussions) para nuevos lotes · 🌐 **Follow** el blog para actualizaciones por aviso.
---
## 📂 Formato de envío de vulnerabilidades
Todas las vulnerabilidades divulgadas siguen una estructura de directorio estandarizada:
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### Reglas de directorios
- **product/**: Directorio raíz para todas las vulnerabilidades
- **<vendor>/**: Nombre del proveedor o producto (p. ej., `apache`, `cisco`, `sonicwall`)
- **<version>/**: Rango de versiones afectadas (p. ej., `6.11.0`, `12.4.2`)
- **<vulnerability_type>/**: Clasificación (p. ej., `unauth-rce`, `auth-bypass`, `deserialization-rce`)
### Archivos requeridos en cada directorio de vulnerabilidad
1. **exploit/**: Directorio que contiene scripts de explotación funcionales y código PoC
2. **analysis.md**: Análisis técnico exhaustivo que incluye la causa raíz, el vector de ataque y el impacto
3. **summary.md**: Resumen conciso de la vulnerabilidad con las versiones afectadas y pasos de mitigación rápidos
### Ejemplo
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
**Únete a nosotros para redefinir la divulgación de vulnerabilidades para la era de la IA.**