exploit-garbage/0day-rubbishRidefinire la divulgazione delle vulnerabilità nell'era dell'IA. Produciamo in serie 0day sfruttabili e le divulghiamo direttamente, usando una pressione basata sugli eventi per innalzare gli standard di sicurezza dei vendor e far avanzare il settore.
# 0day Rubbish
> **Le vulnerabilità 0day sono diventate spazzatura nell'era dell'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)
**🌐 Sito Web Ufficiale**: <https://0day-rubbish.com/blog>
---
## 🎯 Perché Esiste
La divulgazione tradizionale delle vulnerabilità è rotta. È lenta, burocratica e inefficace. Nell'era dell'IA, possiamo produrre 0day su larga scala—rendendo le singole vulnerabilità meno preziose ma più impattanti quando divulgate direttamente.
Crediamo che il **rafforzamento della sicurezza guidato dagli eventi** sia l'approccio più efficace: solo quando i fornitori affrontano minacce reali e sfruttabili danno priorità alle correzioni.
## 🔄 Il Nostro Processo di Divulgazione
### Fase 1: Scoperta tramite IA
I nostri sistemi automatizzati basati su IA scansionano continuamente alla ricerca di vulnerabilità nel software del mondo reale, identificando potenziali 0-day attraverso l'analisi dei pattern, il fuzzing e la revisione intelligente del codice.
### Fase 2: Verifica e Sviluppo del PoC
Ogni scoperta viene sottoposta a validazione manuale. Sviluppiamo exploit proof-of-concept funzionanti per confermare la sfruttabilità e valutare l'impatto nel mondo reale.
### Fase 3: Divulgazione Pubblica Periodica
Ogni settimana — lunedì o martedì — divulghiamo un nuovo lotto di vulnerabilità 0-day verificate e sfruttabili che abbiamo scoperto e validato:
- Analisi tecnica completa e causa radice
- Codice exploit PoC funzionante
- Versioni e sistemi interessati
- Valutazione dell'impatto
- Mitigazioni raccomandate
Nessun ritardo. Nessuna burocrazia. Solo fatti.
**A tutti i fornitori**: Speriamo che possiate completare le correzioni prima che gli hacker sfruttino queste vulnerabilità.
## ⚡ Principi Fondamentali
- **Solo impatto nel mondo reale**: Divulghiamo solo vulnerabilità che interessano sistemi del mondo reale con basi di utenti effettive
- **Nessun obiettivo senza valore**: Le vulnerabilità non sfruttabili o i dispositivi con un'adozione trascurabile sono esclusi—sono spazzatura senza alcun valore
- **Velocità prima del protocollo**: La divulgazione diretta guida un'azione più rapida rispetto ai canali tradizionali
- **Prove invece di affermazioni**: Ogni divulgazione include exploit funzionanti
- **Impatto invece di quantità**: Focus su vulnerabilità ad alta gravità e ampiamente diffuse
- **Trasparenza**: Dettagli tecnici completi, nessun secondo fine
- **Senza scopo di lucro**: Guidati dalla passione per la ricerca sulla sicurezza, non dal guadagno finanziario
## 🤝 Collaborazione
Collaboriamo con:
- I principali fornitori di modelli IA che avanzano la ricerca automatizzata sulla sicurezza
- Ricercatori di sicurezza che esplorano la scoperta basata sull'IA
## 🤖 Modelli IA Utilizzati
La nostra scoperta automatizzata di vulnerabilità sfrutta modelli linguistici di grandi dimensioni all'avanguardia dei principali fornitori di IA:
- **Anthropic (Claude)** - Riconoscimento approfondito dei pattern di sicurezza e ragionamento
- **OpenAI** - Ragionamento avanzato e analisi del codice
- **DeepSeek** - Rilevamento specializzato delle vulnerabilità
- **Z.ai (GLM)** - Analisi del codice a contesto lungo
- **Moonshot (Kimi)** - Analisi della sicurezza a contesto lungo
---
## 📋 Vulnerabilità Divulgate
Un processo di ricerca guidato dall'IA (ensemble multi-LLM: Claude, OpenAI, DeepSeek, GLM, Kimi) scopre 0-day nel software aziendale del mondo reale. Ogni avviso di seguito include una **analisi completa della causa radice** più uno **script exploit funzionante e riproducibile** — nessun report di sola rilevazione, nessun dettaglio omesso.
### Ultimo Lotto — Lotto 16 (6 avvisi)
*Sei riscontri che hanno tutti richiesto gli strumenti propri del revisore per essere dimostrati, e nessuno dei quali afferma più di quanto gli strumenti abbiano mostrato: una coppia di upload anonimi contro un endpoint PHP che non è mai cresciuto oltre il suo modello di autenticazione risalente al 2007; l'endpoint di diagnostica di un daemon di routing che ha invertito il proprio validatore di hostname; un router consumer il cui campo di installazione app SOAP è diventato una shell; e tre punti di ingresso separati nella superficie di configurazione costruita tramite shell di un router cellulare industriale. Quattro dei sei pubblicano un punteggio inferiore a quello suggerito dal record grezzo della fonte, e ciascuno di questi ribassamenti è stampato con la sua aritmetica accanto al punteggio che corregge.*
| # | Prodotto | Versione interessata | CVSS | Classe | Advisory e PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | L'azione SOAP InstallApp sul piano di gestione lato LAN costruisce un comando shell `rm -rf` sull'argomento `apName`; una sostituzione `$(...)` raggiunge lo stack web configurato come root prima che la parola del comando venga risolta | [InstallApp apName → sostituzione di comando 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 di upload `copy()` nudo, senza sessione, senza filtro sulle estensioni e senza controllo del percorso, che prosegue un pattern di atterraggio nella web-root reso celebre dalla linea discontinuata del fornitore; una singola coppia di richieste anonime scrive una pagina eseguibile e la recupera | [upload.php → scrittura nella web-root → esecuzione di codice lato 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 gestore di diagnostica `ping`/`traceroute` il cui validatore di hostname inverte il proprio controllo sul valore di ritorno, raggiungibile da ogni sessione autenticata ordinaria mentre `netstat` porta un attributo riservato agli amministratori che manca alla coppia di diagnostica | [diag ping → inversione del valore di ritorno → iniezione 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 tabella dei programmi dell'interfaccia di gestione passa il proprio campo `argument` direttamente nella riga di comando del launcher dei programmi utente | [Argomento Executer → iniezione nel lancio del programma](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (stesso prodotto, stesso lotto) | V1.0 Build 15010909 | **7.2** \* | Cinque gestori `ipsec.py` separati invocano comandi di gestione delle rotte che trasportano testo controllato dall'attaccante dai campi degli indirizzi del tunnel; i riscontri di un prodotto non vengono mai suddivisi tra lotti | [indirizzo del tunnel → shell di gestione delle rotte](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (stesso prodotto, stesso lotto) | V1.0 Build 15010909 | **7.2** \* | Un motore di scenari rivaluta periodicamente una condizione `ping` salvata, e il thread ricostruisce il comando shell a ogni passaggio, così un payload memorizzato si attiva senza che l'attaccante invii mai di nuovo alcuna richiesta | [ping di scenario → thread di esecuzione automatica](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* Tutti e sei pubblicano più di una lettura. Ogni advisory riporta le letture che ha scartato o reso condizionali accanto a quella che sostiene, ciascuna con il proprio vettore e la propria aritmetica:
> - **Riscontro 1** — **6.8** pubblicato con `AV:A/PR:H`: nessun artefatto distribuito dimostra un'esposizione lato WAN, e l'azione appartiene al livello amministrativo, quindi entrambe le metà della lettura ingenua 8.8-e-in-rete sono cadute sotto i controlli degli artefatti, e l'8.8 del record sorgente è mostrato all'interno come variante PR:L con la sua aritmetica, non come titolo principale. `AV:N` a 7.2 è il condizionale etichettato per le distribuzioni il cui piano di gestione è deliberatamente esposto.
> - **Riscontro 2** — **9.8** con `PR:N`. Una singola coppia di richieste anonime; il livello web ri-serve qualunque cosa abbia scritto. L'esecuzione avviene come account del servizio web dell'ambiente di replica ed è riportata esattamente come tale: l'identità del servizio lato dispositivo non è mai stata misurata e non viene rivendicata. `S:C` a 10.0 è stampato con l'aritmetica e respinto; un `AV:A` 8.8 è il condizionale etichettato per l'isolamento della VLAN di gestione; un'avvertenza sull'identità del dispositivo sconosciuta è stampata in modo prominente nel Riepilogo ed è ripetuta nel nome del file e nel testo: nessuna rivendicazione di "root" o "system" è riportata in alcun punto del titolo, dello slug o del corpo di questo riscontro. La discendenza dell'upload del modello di famiglia nella linea discontinuata del fornitore è descritta come un pattern senza alcun identificatore, secondo la regola interna di questa serie di advisory.
> - **Riscontro 3** — **8.8** con `PR:L`: l'asimmetria tra `netstat` distribuito e attributo di diagnostica è l'artefatto che dimostra che qualsiasi sessione ordinaria è la classe di principale prevista; la coppia di account predefiniti di fabbrica è divulgata come debolezza adiacente separata con la propria lettura condizionale `PR:N` 9.8, mai come vettore di questo riscontro. `PR:H` a 7.2 è stampato e respinto.
> - **Riscontri 4-6** — tutti e tre **7.2** con `PR:H`, stampati con la correzione che l'8.8 del record sorgente è l'aritmetica `PR:L` secondo la regola corretta della famiglia di relazioni 881, mostrata a fianco come aritmetica di variante respinta. I tre condizionali sulle credenziali predefinite di fabbrica (9.8 ciascuno, se invariati) sono etichettati, mai posti come titolo principale, e `S:C` 9.1 è stampato e respinto per tutti e tre. Tutti e tre riportano l'onesto risultato negativo che un payload con punto e virgola nel sink scenario-ping fallisce e blocca il thread di valutazione, quindi le forme funzionanti (`$(...)`, newline) sono stampate insieme al test.
> - **Confine di verifica, dichiarato uniformemente** — ogni marcatore sandbox `uid=0` in questo batch è una proprietà dell'ambiente di replica usato per testarlo, e dove un'immagine distribuita configura il proprio stack web come root, questo è un fatto interno all'immagine stampato come tale. Nessuna matrice di riscontri rivendica l'identità lato dispositivo, e nessuna rivendicazione su dispositivo live è fatta in alcun punto di questo batch: tre riscontri sono stati testati tramite `replica a livello di sink su un sandbox isolato ospitato nel cloud`, uno (Crystal Server) tramite una catena HTTP end-to-end all'interno della propria immagine VM, uno (PX3) a livello di istruzioni dall'immagine e replica a livello di comando del sink (nessun end-to-end; la catena RPC→cfgd→hardware non si completerebbe sotto emulazione), e uno (RAX120) tramite disassemblaggio del percorso di richiesta a livello di istruzioni più replica nativa con gcc del sink per tre marcatori mutuamente indipendenti più un controllo benigno.
> - **Rivendicazioni su root e identità, verificate una per una**: il 9.8 pubblicato (`Riscontro 2`) esplicitamente non rivendica root o system; lo slug dei `Riscontri 4-6` pubblicati si ferma a "shell-injected into the management stack", con l'identità del sandbox di replica divulgata come origine delle righe `uid=0`; lo slug e le rivendicazioni inline del riscontro RAX120 sono le uniche nel batch a riportare la parola root, ed entrambi i suoi ancoraggi sono la configurazione `User root` di lighttpd interna all'immagine più tre marcatori a id zero e un controllo, mai un dispositivo live.
**Totali**: 6 advisory · 4 prodotti · 4 organizzazioni vendor (NETGEAR, NUUO, Raritan/Legrand, Moxa), con la serie MAR-2000 che ne contiene tre perché i risultati qualificanti di un prodotto non vengono mai suddivisi tra batch · 1 catena non autenticata · 5 catene autenticate, di cui quattro richiedono esplicitamente una sessione di classe admin e una qualsiasi sessione ordinaria. Un singolo 6.8 porta il titolo dello slot del marchio famoso, ed è deliberatamente il numero meno drammatico del batch: `AV` e `PR` sono entrambi scesi a ciò che gli artefatti distribuiti hanno dimostrato, anziché a ciò che suggerisce il template del modello ingenuo, e i `Totals` pubblicati lo dicono chiaramente. Quattro dei sei pubblicano almeno una cifra inferiore a quanto suggeriva il record grezzo della fonte — un lato WAN non evidenziato due volte, un livello PR inserito erroneamente quattro volte — e ognuno di questi declassamenti è stampato dove il lettore lo vedrà, con l'aritmetica rifiutata, il vettore, la motivazione e la cronologia delle correzioni accanto al punteggio sopravvissuto.
**Cosa hanno effettivamente mostrato gli strumenti** — affermato perché la credibilità del batch si basa esattamente su questo:
- **Due catene end-to-end, quattro fino al sink.** Il Finding 2 ha eseguito una coppia completa di richieste HTTP anonime contro l'immagine VM del vendor stesso e ha confermato l'esecuzione della pagina scritta; l'handler `diag` del Finding 3 è stato verificato a livello di istruzione dal firmware rilasciato, oltre all'iniezione a livello di comando di tre forme di payload con un controllo benigno; i Finding 4-6 sono stati verificati tramite analisi del codice sorgente del firmware più la replica shell con gcc nativo di ogni esatta costruzione del sink, marker e controlli benigni inclusi; il Finding 1 è stato verificato alla riga del percorso di richiesta nel disassemblato e poi tramite replica del sink con gcc nativo per tre marker indipendenti più un controllo benigno. Nessuna affermazione end-to-end viene fatta per alcun finding non live, e la riga README del batch per ciascuno dice "disassembly" o "replication" a chiare lettere.
- **Punto di osservazione, uniformemente:** le richieste o esecuzioni non hanno mai attraversato un confine di rete non attendibile in alcun finding di questo batch. Laddove un finding rivendica una portata più ampia dell'ambiente di replica, tale affermazione è ancorata a un artefatto distribuito — un binding nell'immagine o una configurazione dello stack web nell'immagine — e lo dice con queste parole.
- **Cosa ha fornito il nostro harness** — perché uno stato che abbiamo creato non è un default del prodotto: l'ambiente host di replica (identità degli account sandbox misurate come proprietà dell'host, poi rispecchiate nelle affermazioni dei finding su ciò che NON viene rivendicato sul lato dispositivo); i controlli benigni che separano un finding da un incidente; i marker di chiusura monouso (una finestra unidirezionale) dove un punto di ingresso viene chiuso dopo il primo utilizzo.
*Ogni batch precedente e i suoi advisory sono elencati sotto [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
*Ogni batch precedente e i suoi advisory sono elencati sotto [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
---
## 🔁 Una serie in corso — Divulgazioni settimanali
Questa è una **serie di divulgazione continua**. Grazie all'ottimizzazione continua, la pipeline di scoperta guidata dall'AI produce ora nuovi finding 0-day a un ritmo giornaliero stabile, e divulghiamo i batch verificati con **cadenza settimanale**.
- **Ultimo batch**: Batch 16 — 6 advisory; cumulativo 144 su 16 batch
- **Prossimo rilascio**: ogni lunedì o martedì
- **Ambito futuro**: espansione oltre l'IT aziendale verso sistemi **ICS / SCADA, energia e aerospaziale**
Se vuoi cogliere il prossimo rilascio nel momento in cui arriva:
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star** per aggiungere ai segnalibri · 👁 **Watch** (personalizzato → Releases + Discussions) per i nuovi batch · 🌐 **Follow** il blog per gli aggiornamenti per singolo advisory.
---
## 📂 Formato di invio delle vulnerabilità
Tutte le vulnerabilità divulgate seguono una struttura di directory standardizzata:
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### Regole della directory
- **product/**: Directory radice per tutte le vulnerabilità
- **<vendor>/**: Nome del vendor o del prodotto (ad es. `apache`, `cisco`, `sonicwall`)
- **<version>/**: Intervallo di versioni interessate (ad es. `6.11.0`, `12.4.2`)
- **<vulnerability_type>/**: Classificazione (ad es. `unauth-rce`, `auth-bypass`, `deserialization-rce`)
### File richiesti in ciascuna directory di vulnerabilità
1. **exploit/**: Directory contenente gli script di exploit funzionanti e il codice PoC
2. **analysis.md**: Analisi tecnica completa che include causa principale, vettore di attacco e impatto
3. **summary.md**: Panoramica concisa della vulnerabilità con le versioni interessate e i passaggi rapidi di mitigazione
### Esempio
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
**Unisciti a noi nel ridefinire la divulgazione delle vulnerabilità per l'era dell'IA.**