exploit-garbage/0day-rubbishRedéfinir la divulgation des vulnérabilités à l'ère de l'IA. Nous produisons en masse des 0day exploitables et les divulguons directement, en utilisant une pression pilotée par les événements pour élever les normes de sécurité des éditeurs et faire progresser le domaine.
# 0day Rubbish
> **Les vulnérabilités 0day sont devenues de la camelote à l'ère de l'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)
**🌐 Site officiel** : <https://0day-rubbish.com/blog>
---
## 🎯 Pourquoi ce projet existe
La divulgation traditionnelle des vulnérabilités est cassée. Elle est lente, bureaucratique et inefficace. À l'ère de l'IA, nous pouvons produire des 0day en masse — rendant les vulnérabilités individuelles moins précieuses mais plus impactantes lorsqu'elles sont divulguées directement.
Nous croyons que le **durcissement de sécurité piloté par les événements** est l'approche la plus efficace : ce n'est que lorsque les éditeurs font face à de réelles menaces exploitables qu'ils priorisent les correctifs.
## 🔄 Notre processus de divulgation
### Étape 1 : Découverte par IA
Nos systèmes d'IA automatisés scannent en continu les vulnérabilités dans les logiciels du monde réel, identifiant les 0-day potentiels grâce à l'analyse de motifs, au fuzzing et à la revue de code intelligente.
### Étape 2 : Vérification et développement de PoC
Chaque découverte fait l'objet d'une validation manuelle. Nous développons des exploits proof-of-concept fonctionnels pour confirmer l'exploitabilité et évaluer l'impact réel.
### Étape 3 : Divulgation publique périodique
Chaque semaine — le lundi ou le mardi — nous divulguons un nouveau lot de vulnérabilités 0-day vérifiées et exploitables que nous avons découvertes et validées :
- Analyse technique complète et cause racine
- Code d'exploit PoC fonctionnel
- Versions et systèmes affectés
- Évaluation de l'impact
- Mesures d'atténuation recommandées
Pas de délais. Pas de bureaucratie. Juste des faits.
**À tous les éditeurs** : Nous espérons que vous pourrez terminer les correctifs avant que les hackers n'exploitent ces vulnérabilités.
## ⚡ Principes fondamentaux
- **Impact réel uniquement** : Nous ne divulguons que les vulnérabilités qui affectent des systèmes réels avec de véritables bases d'utilisateurs
- **Pas de cibles sans valeur** : Les vulnérabilités non exploitables ou les appareils à l'adoption négligeable sont exclus — ce sont des camelotes sans aucune valeur
- **La rapidité avant le protocole** : La divulgation directe entraîne une action plus rapide que les canaux traditionnels
- **La preuve avant les affirmations** : Chaque divulgation inclut des exploits fonctionnels
- **L'impact avant la quantité** : Concentration sur les vulnérabilités de haute gravité et largement déployées
- **Transparence** : Détails techniques complets, aucun agenda caché
- **À but non lucratif** : Motivé par la passion pour la recherche en sécurité, non par le gain financier
## 🤝 Collaboration
Nous collaborons avec :
- Les principaux fournisseurs de modèles d'IA qui font progresser la recherche automatisée en sécurité
- Des chercheurs en sécurité explorant la découverte assistée par IA
## 🤖 Modèles d'IA utilisés
Notre découverte automatisée de vulnérabilités s'appuie sur des grands modèles de langage de pointe provenant de fournisseurs d'IA de premier plan :
- **Anthropic (Claude)** - Reconnaissance approfondie des motifs de sécurité et raisonnement
- **OpenAI** - Raisonnement avancé et analyse de code
- **DeepSeek** - Détection spécialisée de vulnérabilités
- **Z.ai (GLM)** - Analyse de code à contexte long
- **Moonshot (Kimi)** - Analyse de sécurité à contexte long
---
## 📋 Vulnérabilités divulguées
Un processus de recherche piloté par l'IA (ensemble multi-LLM : Claude, OpenAI, DeepSeek, GLM, Kimi) découvre des 0-day dans des logiciels d'entreprise réels. Chaque avis ci-dessous est livré avec une **analyse complète de la cause racine** ainsi qu'un **script d'exploit fonctionnel et reproductible** — pas de rapports de détection seule, pas de détails retenus.
### Dernier lot — Lot 16 (6 avis)
*Six constats dont la démonstration a tous exigé les propres instruments de l'auditeur, et dont aucun ne revendique plus que ce que les instruments ont montré : une paire de téléversements anonymes contre un point de terminaison PHP qui n'a jamais dépassé son modèle d'authentification de l'époque 2007 ; le point de terminaison de diagnostic d'un démon de routage qui a inversé son propre validateur de nom d'hôte ; un routeur grand public dont le champ d'installation d'application SOAP est devenu un shell ; et trois points d'entrée distincts dans la surface de configuration construite par shell d'un routeur cellulaire industriel. Quatre des six publient une note inférieure à ce que suggérait l'enregistrement brut de la source, et chacun de ces déclassements est imprimé avec son arithmétique à côté du score qu'il corrige.*
| # | Produit | Version affectée | CVSS | Classe | Avis & PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | L'action SOAP InstallApp sur le plan de gestion côté LAN construit une commande shell `rm -rf` à partir de l'argument `apName` ; une substitution `$(...)` atteint la pile web configurée en root avant que le mot de commande ne soit résolu | [InstallApp apName → substitution de commande shell](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | Un point de terminaison de téléversement `copy()` nu, sans session, sans filtre d'extension et sans vérification de chemin, perpétuant un schéma d'atterrissage dans la racine web rendu célèbre par la gamme abandonnée du fournisseur ; une seule paire de requêtes anonymes écrit une page exécutable et la récupère | [upload.php → écriture dans la racine web → exécution de code côté 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 gestionnaire de diagnostic `ping`/`traceroute` dont le validateur de nom d'hôte inverse sa propre vérification de retour, accessible à toute session authentifiée ordinaire, tandis que `netstat` porte un attribut réservé aux administrateurs qui manque à la paire de diagnostics | [diag ping → inversion de la valeur de retour → injection 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 table des programmes de l'interface de gestion transmet son champ `argument` directement dans la ligne de commande du lanceur de programmes utilisateur | [Executer argument → injection au lancement de programme](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (même produit, même lot) | V1.0 Build 15010909 | **7.2** \* | Cinq gestionnaires `ipsec.py` distincts invoquent des commandes de gestion de routes en y injectant du texte contrôlé par l'attaquant issu des champs d'adresse de tunnel ; les constats d'un même produit ne sont jamais répartis entre plusieurs lots | [adresse de tunnel → shell de gestion de routes](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (même produit, même lot) | V1.0 Build 15010909 | **7.2** \* | Un moteur de scénarios réévalue périodiquement une condition `ping` enregistrée, et le thread reforme la commande shell à chaque passage, de sorte qu'une charge utile stockée se déclenche sans que l'attaquant ait à renvoyer la moindre requête | [scenario ping → thread d'auto-exécution](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* Les six publient plus d'une lecture. Chaque avis présente les lectures qu'il a rejetées ou rendues conditionnelles à côté de celle qu'il retient, chacune avec son propre vecteur et son arithmétique :
> - **Constat 1** — **6.8** publié à `AV:A/PR:H` : aucun artefact livré ne démontre une exposition côté WAN, et l'action relève du niveau administrateur, de sorte que les deux moitiés de la lecture naïve 8.8-et-réseau ont échoué aux vérifications d'artefacts, et le 8.8 propre à l'enregistrement source est présenté à l'intérieur comme la variante PR:L avec son arithmétique, et non comme le titre principal. `AV:N` à 7.2 est le conditionnel étiqueté pour les déploiements dont le plan de gestion est délibérément exposé.
> - **Constat 2** — **9.8** à `PR:N`. Une seule paire de requêtes anonymes ; la couche web re-sert tout ce qu'elle a écrit. L'exécution se fait sous le compte de service web de l'environnement de réplication et est rapportée exactement comme telle : l'identité de service côté appareil n'a jamais été mesurée et n'est pas revendiquée. `S:C` à 10.0 est imprimé avec son arithmétique et rejeté ; un `AV:A` 8.8 est le conditionnel étiqueté pour l'isolation du VLAN de gestion ; une mise en garde sur l'identité d'appareil inconnue figure de manière proéminente dans le résumé et est répétée dans le nom de fichier et le texte : aucune revendication « root » ou « system » n'est portée nulle part dans le titre, le slug ou le corps de ce constat. La lignée de téléversement du modèle de famille dans la gamme abandonnée du fournisseur est décrite comme un schéma sans aucun identifiant, conformément à la règle interne de cette série d'avis.
> - **Constat 3** — **8.8** à `PR:L` : l'asymétrie livrée entre `netstat` et l'attribut de diagnostics est l'artefact qui prouve que toute session ordinaire constitue la classe de principal visée ; la paire de comptes par défaut d'usine est divulguée comme une faiblesse adjacente distincte avec sa propre lecture conditionnelle `PR:N` 9.8, jamais comme le vecteur de ce constat. `PR:H` à 7.2 est imprimé et rejeté.
> - **Constats 4-6** — tous les trois **7.2** à `PR:H`, imprimés avec la correction que le 8.8 de l'enregistrement source est l'arithmétique `PR:L` sous la règle de famille 881-relation corrigée, présentée à côté comme arithmétique de variante rejetée. Les trois conditionnels d'identifiants par défaut d'usine (9.8 chacun, si inchangés) sont étiquetés, jamais mis en titre, et `S:C` 9.1 est imprimé et rejeté pour les trois. Tous les trois portent le résultat négatif honnête qu'une charge utile avec point-virgule dans le puits scenario-ping échoue et bloque le thread évaluateur, de sorte que les formes fonctionnelles (`$(...)`, saut de ligne) sont imprimées avec le test.
> - **Frontière de vérification, énoncée uniformément** — chaque marqueur de bac à sable `uid=0` dans ce lot est une propriété de l'environnement de réplication utilisé pour le tester, et lorsqu'une image livrée configure sa propre pile web en tant que root, il s'agit d'un fait propre à l'image imprimé comme tel. Aucun constat ne revendique dans sa matrice une identité côté appareil, et aucune revendication sur un appareil réel n'est faite nulle part dans ce lot : trois constats ont été testés par `réplication au niveau du puits sur un bac à sable isolé hébergé dans le cloud`, un (Crystal Server) par une chaîne HTTP de bout en bout au sein de sa propre image de VM, un (PX3) au niveau instruction à partir de l'image et par réplication au niveau commande du puits (pas de bout en bout ; la chaîne RPC→cfgd→matériel ne se terminerait pas sous émulation), et un (RAX120) par désassemblage du chemin de requête au niveau instruction plus réplication native-gcc du puits pour trois marqueurs mutuellement indépendants plus un contrôle bénin.
> - **Revendications de root et d'identité, vérifiées une par une** : le 9.8 publié (`Constat 2`) ne revendique explicitement ni root ni system ; les revendications du slug des `Constats 4-6` publiés s'arrêtent à « shell-injected into the management stack », l'identité du bac à sable de réplication étant divulguée comme la source des lignes `uid=0` ; le slug et les revendications en ligne du constat RAX120 sont les seuls du lot à porter le mot root, et ses deux ancrages sont la configuration `User root` de lighttpd dans l'image plus trois marqueurs à identifiant zéro et un contrôle, jamais un appareil réel.
**Totaux** : 6 avis · 4 produits · 4 organisations fournisseurs (NETGEAR, NUUO, Raritan/Legrand, Moxa), la série MAR-2000 en portant trois à elle seule car les constats qualifiants d'un même produit ne sont jamais répartis entre plusieurs lots · 1 chaîne non authentifiée · 5 chaînes authentifiées, dont quatre exigent explicitement une session de classe administrateur et une n'importe quelle session ordinaire. Un seul 6.8 porte le titre de la place réservée aux marques célèbres, et c'est délibérément le chiffre le moins spectaculaire du lot : `AV` et `PR` sont tous deux tombés à ce que les artefacts livrés ont prouvé, plutôt qu'à ce que suggère le modèle naïf, et les `Totaux` publiés le disent clairement. Quatre des six publient au moins un chiffre inférieur à ce que suggérait l'enregistrement source brut — un côté WAN non étayé à deux reprises, un niveau PR mal saisi à quatre reprises — et chacune de ces révisions à la baisse est imprimée là où le lecteur la verra, avec l'arithmétique rejetée, le vecteur, la justification et l'historique de correction à côté du score retenu.
**Ce que les instruments ont réellement montré** — précisé car la crédibilité du lot repose exactement sur cela :
- **Deux chaînes de bout en bout, quatre jusqu'au sink.** Le constat 2 a exécuté une paire complète de requêtes HTTP anonymes contre l'image VM du fournisseur lui-même et confirmé l'exécution de la page écrite ; le gestionnaire `diag` du constat 3 a été vérifié au niveau instruction à partir du firmware publié, plus une injection au niveau commande de trois formes de payload avec un contrôle bénin ; les constats 4 à 6 ont été vérifiés par analyse du code source du firmware plus réplication en shell avec gcc natif de chaque construction exacte du sink, marqueurs et contrôles bénins inclus ; le constat 1 a été vérifié à la ligne du chemin de requête en désassemblage, puis par réplication du sink avec gcc natif pour trois marqueurs indépendants plus un contrôle bénin. Aucune affirmation de bout en bout n'est faite pour un constat non exécuté en direct, et la ligne README du lot pour chacun indique « disassembly » ou « replication » en toutes lettres.
- **Point d'observation, uniformément :** les requêtes ou exécutions n'ont jamais franchi de frontière réseau non fiable dans aucun constat de ce lot. Lorsqu'un constat revendique une portée plus large que l'environnement de réplication, cette revendication est ancrée à un artefact livré — une liaison dans l'image ou une configuration de pile web dans l'image — et le dit en ces termes.
- **Ce que notre propre harnais a fourni** — car un état que nous avons créé n'est pas un défaut par défaut du produit : l'environnement hôte de réplication (identités de compte sandbox mesurées comme propriété de l'hôte, puis reflétées dans les revendications des constats sur ce qui n'est PAS revendiqué côté appareil) ; les contrôles bénins qui distinguent un constat d'un accident ; les marqueurs de fermeture à usage unique (une fenêtre à sens unique) lorsqu'un point d'entrée est fermé après le premier usage.
*Chaque lot précédent et ses avis sont listés sous [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
*Chaque lot précédent et ses avis sont listés sous [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases).*
---
## 🔁 Une série en cours — Divulgations hebdomadaires
Il s'agit d'une **série de divulgations continues**. Grâce à une optimisation continue, le pipeline de découverte piloté par IA produit désormais de nouveaux constats 0-day à un rythme quotidien stable, et nous divulguons les lots vérifiés selon une **cadence hebdomadaire**.
- **Dernier lot** : Lot 16 — 6 avis ; cumul de 144 sur 16 lots
- **Prochaine publication** : chaque lundi ou mardi
- **Périmètre futur** : extension au-delà de l'IT d'entreprise vers les systèmes **ICS / SCADA, énergie et aérospatiale**
Si vous voulez saisir la prochaine publication dès sa mise en ligne :
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star** pour mettre en favori · 👁 **Watch** (personnalisé → Releases + Discussions) pour les nouveaux lots · 🌐 **Follow** le blog pour les mises à jour par avis.
---
## 📂 Format de soumission des vulnérabilités
Toutes les vulnérabilités divulguées suivent une structure de répertoire standardisée :
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### Règles de répertoire
- **product/** : Répertoire racine de toutes les vulnérabilités
- **<vendor>/** : Nom du fournisseur ou du produit (par ex., `apache`, `cisco`, `sonicwall`)
- **<version>/** : Plage de versions affectées (par ex., `6.11.0`, `12.4.2`)
- **<vulnerability_type>/** : Classification (par ex., `unauth-rce`, `auth-bypass`, `deserialization-rce`)
### Fichiers requis dans chaque répertoire de vulnérabilité
1. **exploit/** : Répertoire contenant les scripts d'exploitation fonctionnels et le code PoC
2. **analysis.md** : Analyse technique complète incluant la cause racine, le vecteur d'attaque et l'impact
3. **summary.md** : Aperçu concis de la vulnérabilité avec les versions affectées et les étapes d'atténuation rapides
### Exemple
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
**Rejoignez-nous pour redéfinir la divulgation des vulnérabilités à l'ère de l'IA.**