exploit-garbage/0day-rubbishDie Offenlegung von Sicherheitslücken im KI-Zeitalter neu definieren. Wir produzieren massenhaft ausnutzbare 0days und legen sie direkt offen – mit ereignisgetriebenem Druck erhöhen wir die Sicherheitsstandards der Anbieter und bringen das Feld voran.
# 0day Rubbish
> **0day-Schwachstellen sind im KI-Zeitalter zu Müll geworden.**
[](./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)
**🌐 Offizielle Website**: <https://0day-rubbish.com/blog>
---
## 🎯 Warum es das gibt
Die traditionelle Offenlegung von Schwachstellen ist kaputt. Sie ist langsam, bürokratisch und ineffektiv. Im KI-Zeitalter können wir 0days in großem Maßstab massenproduzieren – was einzelne Schwachstellen weniger wertvoll macht, aber wirkungsvoller, wenn sie direkt offengelegt werden.
Wir glauben, dass **ereignisgesteuerte Sicherheitshärtung** der effektivste Ansatz ist: Erst wenn Hersteller mit echten, ausnutzbaren Bedrohungen konfrontiert werden, priorisieren sie Korrekturen.
## 🔄 Unser Offenlegungsprozess
### Schritt 1: KI-Entdeckung
Unsere automatisierten KI-Systeme scannen kontinuierlich nach Schwachstellen in realer Software und identifizieren potenzielle 0-Days durch Musteranalyse, Fuzzing und intelligente Code-Reviews.
### Schritt 2: Verifizierung & PoC-Entwicklung
Jeder Fund wird manuell validiert. Wir entwickeln funktionierende Proof-of-Concept-Exploits, um die Ausnutzbarkeit zu bestätigen und die reale Auswirkung zu bewerten.
### Schritt 3: Regelmäßige öffentliche Offenlegung
Jede Woche – Montag oder Dienstag – legen wir eine neue Charge verifizierter, ausnutzbarer 0-Day-Schwachstellen offen, die wir entdeckt und validiert haben:
- Vollständige technische Analyse und Ursachenanalyse
- Funktionierender PoC-Exploit-Code
- Betroffene Versionen und Systeme
- Auswirkungsbewertung
- Empfohlene Gegenmaßnahmen
Keine Verzögerungen. Keine Bürokratie. Nur Fakten.
**An alle Hersteller**: Wir hoffen, dass Sie die Korrekturen abschließen können, bevor Hacker diese Schwachstellen ausnutzen.
## ⚡ Kernprinzipien
- **Nur reale Auswirkungen**: Wir legen nur Schwachstellen offen, die reale Systeme mit tatsächlicher Nutzerbasis betreffen
- **Keine wertlosen Ziele**: Nicht ausnutzbare Schwachstellen oder Geräte mit vernachlässigbarer Nutzerakzeptanz werden ausgeschlossen – sie sind Müll ohne jeglichen Wert
- **Geschwindigkeit vor Protokoll**: Direkte Offenlegung treibt schnelleres Handeln voran als traditionelle Kanäle
- **Beweis vor Behauptung**: Jede Offenlegung enthält funktionierende Exploits
- **Wirkung vor Quantität**: Fokus auf hochgradig schwerwiegende, weit verbreitete Schwachstellen
- **Transparenz**: Vollständige technische Details, keine versteckten Absichten
- **Gemeinnützig**: Angetrieben von Leidenschaft für Sicherheitsforschung, nicht von finanziellem Gewinn
## 🤝 Zusammenarbeit
Wir arbeiten zusammen mit:
- Führenden KI-Modellanbietern, die automatisierte Sicherheitsforschung vorantreiben
- Sicherheitsforschern, die KI-gestützte Entdeckung erforschen
## 🤖 Verwendete KI-Modelle
Unsere automatisierte Schwachstellenerkennung nutzt modernste große Sprachmodelle führender KI-Anbieter:
- **Anthropic (Claude)** – Tiefgehende Erkennung und Schlussfolgerung von Sicherheitsmustern
- **OpenAI** – Fortschrittliche Schlussfolgerung und Codeanalyse
- **DeepSeek** – Spezialisierte Schwachstellenerkennung
- **Z.ai (GLM)** – Codeanalyse mit langem Kontext
- **Moonshot (Kimi)** – Sicherheitsanalyse mit langem Kontext
---
## 📋 Offengelegte Schwachstellen
Ein KI-gesteuerter Forschungsprozess (Multi-LLM-Ensemble: Claude, OpenAI, DeepSeek, GLM, Kimi) entdeckt 0-Days in realer Unternehmenssoftware. Jede der folgenden Advisories enthält eine **vollständige Ursachenanalyse** sowie ein **funktionierendes, reproduzierbares Exploit-Skript** – keine reinen Erkennungsberichte, keine zurückgehaltenen Details.
### Neueste Charge — Charge 16 (6 Advisories)
*Sechs Befunde, die alle die eigenen Instrumente des Prüfers erforderten, um sie zu belegen, und von denen keiner mehr behauptet, als die Instrumente zeigten: ein anonymes Upload-Paar gegen einen PHP-Endpunkt, der sein Authentifizierungsmodell aus der Ära von 2007 nie überwunden hat; der Diagnose-Endpunkt eines Routing-Daemons, der seinen eigenen Hostname-Validator umkehrte; ein Consumer-Router, dessen SOAP-App-Install-Feld zu einer Shell wurde; und drei separate Einstiegspunkte in die shell-basierte Konfigurationsoberfläche eines industriellen Mobilfunk-Routers. Vier der sechs veröffentlichen einen Wert, der niedriger liegt als der rohe Quellbeleg nahelegte, und jede dieser Herabstufungen wird mit ihrer Arithmetik neben dem Score abgedruckt, den sie korrigiert.*
| # | Produkt | Betroffene Version | CVSS | Klasse | Advisory & PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | Die SOAP-Aktion InstallApp auf der LAN-seitigen Management-Ebene baut über das Argument `apName` einen `rm -rf`-Shell-Befehl; eine `$(...)`-Substitution erreicht den root-konfigurierten Web-Stack, bevor das Befehlswort aufgelöst wird | [InstallApp apName → Shell-Befehlssubstitution](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | Ein nackter `copy()`-Upload-Endpunkt ohne Session, ohne Erweiterungsprüfung und ohne Pfadprüfung, der ein Web-Root-Landemuster fortführt, das die eingestellte Produktlinie des Herstellers berühmt machte; ein einzelnes anonymes Anfragepaar schreibt eine ausführbare Seite und ruft sie wieder ab | [upload.php → Schreiben ins Web-Root → Codeausführung auf der Web-Seite](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** \* | Ein Diagnose-Handler für `ping`/`traceroute`, dessen Hostname-Validator seine eigene Rückgabeprüfung umkehrt, erreichbar aus jeder gewöhnlichen authentifizierten Sitzung, während `netstat` ein nur für Administratoren geltendes Attribut trägt, das dem Diagnose-Paar fehlt | [diag ping → Umkehrung des Rückgabewerts → Shell-Injection](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** \* | Die Programm-Tabelle der Management-UI reicht ihr Feld `argument` direkt an die Kommandozeile des Benutzerprogramm-Starters weiter | [Executer argument → Injection beim Programmstart](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (gleiches Produkt, gleiche Charge) | V1.0 Build 15010909 | **7.2** \* | Fünf separate `ipsec.py`-Handler rufen per Shell in Routenverwaltungsbefehle aus, die Angreifertext aus den Tunneladressfeldern tragen; die Befunde eines Produkts werden nie über Chargen aufgeteilt | [Tunneladresse → Shell der Routenverwaltung](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (gleiches Produkt, gleiche Charge) | V1.0 Build 15010909 | **7.2** \* | Eine Szenario-Engine wertet periodisch eine gespeicherte `ping`-Bedingung neu aus, und der Thread bildet bei jedem Durchlauf den Shell-Befehl neu, sodass eine gespeicherte Payload ausgelöst wird, ohne dass der Angreifer jemals eine Anfrage erneut senden muss | [scenario ping → Auto-Ausführungs-Thread](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* Alle sechs veröffentlichen mehr als einen Messwert. Jedes Advisory führt die Messwerte, die es verworfen oder an Bedingungen geknüpft hat, neben demjenigen auf, hinter dem es steht, jeweils mit eigenem Vektor und eigener Arithmetik:
> - **Befund 1** — **6.8** veröffentlicht unter `AV:A/PR:H`: Kein ausgeliefertes Artefakt belegt eine WAN-seitige Exposition, und die Aktion gehört zur Admin-Ebene, sodass beide Hälften der naiven 8.8-und-vernetzt-Lesart den Artefaktprüfungen zum Opfer fielen, und die 8.8 des Quelldatensatzes selbst wird im Inneren als die PR:L-Variante mit ihrer Arithmetik gezeigt, nicht als Schlagzeile. `AV:N` bei 7.2 ist das gekennzeichnete Konditional für Bereitstellungen, deren Management-Ebene bewusst exponiert ist.
> - **Befund 2** — **9.8** bei `PR:N`. Ein einziges anonymes Anfragepaar; die Web-Ebene liefert erneut aus, was sie geschrieben hat. Die Ausführung landet als das Webdienst-Konto der Replikationsumgebung und wird genau so berichtet: Die geräteseitige Dienstidentität wurde nie gemessen und wird nicht behauptet. `S:C` bei 10.0 wird mit Arithmetik gedruckt und verworfen; ein `AV:A` 8.8 ist das gekennzeichnete Konditional für Management-VLAN-Isolation; ein Vorbehalt zur unbekannten Geräteidentität wird prominent in der Zusammenfassung gedruckt und im Dateinamen und Text wiederholt: Nirgendwo in der Schlagzeile, dem Slug oder dem Text dieses Befunds wird eine „root“- oder „system“-Behauptung getragen. Die Familienmodell-Upload-Abstammung in der eingestellten Produktlinie des Herstellers wird gemäß der Hausregel dieser Advisory-Reihe als Muster ohne jegliche Identifikatoren beschrieben.
> - **Befund 3** — **8.8** bei `PR:L`: Die ausgelieferte Asymmetrie zwischen `netstat` und Diagnose-Attribut ist das Artefakt, das beweist, dass jede gewöhnliche Sitzung die beabsichtigte Prinzipal-Klasse ist; das werksseitige Standard-Kontenpaar wird als separate angrenzende Schwäche mit ihrer eigenen konditionalen `PR:N`-9.8-Lesart offengelegt, niemals als Vektor dieses Befunds. `PR:H` bei 7.2 wird gedruckt und verworfen.
> - **Befunde 4-6** — alle drei **7.2** bei `PR:H`, gedruckt mit der Korrektur, dass die 8.8 des Quelldatensatzes die `PR:L`-Arithmetik unter der korrigierten 881-Relations-Familienregel ist, daneben als verworfene Varianten-Arithmetik gezeigt. Die drei Konditionale zu werksseitigen Standard-Anmeldedaten (je 9.8, falls unverändert) sind gekennzeichnet, niemals als Schlagzeile, und `S:C` 9.1 wird für alle drei gedruckt und verworfen. Alle drei tragen das ehrliche negative Ergebnis, dass eine Semikolon-Payload in der Scenario-Ping-Senke fehlschlägt und den auswertenden Thread blockiert, sodass die funktionierenden Formen (`$(...)`, Zeilenumbruch) mit dem Test gedruckt werden.
> - **Verifikationsgrenze, einheitlich angegeben** — jeder Sandbox-Marker `uid=0` in diesem Batch ist eine Eigenschaft der Replikationsumgebung, die zu seiner Prüfung verwendet wurde, und wo ein ausgeliefertes Image seinen eigenen Web-Stack als root konfiguriert, ist das ein In-Image-Faktum, das als solches gedruckt wird. Keine Befundmatrix behauptet geräteseitige Identität, und nirgendwo in diesem Batch wird eine Live-Geräte-Behauptung aufgestellt: Drei Befunde wurden durch `sink-level replication on an isolated cloud-hosted sandbox` getestet, einer (Crystal Server) durch eine End-to-End-HTTP-Kette innerhalb seines eigenen VM-Images, einer (PX3) auf Instruktionsebene aus dem Image und durch Befehls-Ebenen-Replikation der Senke (kein End-to-End; die RPC→cfgd→Hardware-Kette ließ sich unter Emulation nicht abschließen), und einer (RAX120) durch Instruktionsebenen-Disassemblierung des Anfragepfads plus native-gcc-Senken-Replikation für drei voneinander unabhängige Marker plus eine harmlose Kontrolle.
> - **Root- und Identitätsbehauptungen, einzeln verifiziert**: Die veröffentlichte 9.8 (`Befund 2`) behauptet ausdrücklich weder root noch system; die Slugs der veröffentlichten `Befunde 4-6` enden bei „shell-injected into the management stack“, wobei die Identität der Replikations-Sandbox als Quelle der `uid=0`-Zeilen offengelegt wird; der Slug und die Inline-Behauptungen des RAX120-Befunds sind die einzigen im Batch, die das Wort root tragen, und beide seine Anker sind die In-Image-lighttpd-Konfiguration `User root` plus drei Zero-ID-Marker und eine Kontrolle, niemals ein Live-Gerät.
**Gesamtsummen**: 6 Advisories · 4 Produkte · 4 Herstellerorganisationen (NETGEAR, NUUO, Raritan/Legrand, Moxa), wobei die MAR-2000-Serie drei davon trägt, weil die qualifizierenden Befunde eines Produkts niemals über Batches hinweg aufgeteilt werden · 1 nicht authentifizierte Kette · 5 authentifizierte Ketten, von denen vier ausdrücklich eine Sitzung der Admin-Klasse und eine jede gewöhnliche Sitzung erfordern. Eine einzelne 6.8 trägt die Schlagzeile des Slots der bekannten Marke, und das ist bewusst die am wenigsten dramatische Zahl des Batches: `AV` und `PR` fielen beide auf das, was die ausgelieferten Artefakte belegten, statt auf das, was das Naivmodell-Template nahelegt, und die veröffentlichten `Totals` sagen das schlicht. Vier der sechs veröffentlichen mindestens eine Zahl niedriger als der rohe Quellendatensatz nahelegte — eine nicht belegte WAN-Seite gleich zweimal, eine falsch eingetragene PR-Stufe gleich viermal — und jede dieser Herabstufungen ist dort abgedruckt, wo der Leser sie sieht, mit der verworfenen Arithmetik, dem Vektor, der Begründung und der Korrekturhistorie neben der überlebenden Bewertung.
**Was die Instrumente tatsächlich zeigten** — genannt, weil die Glaubwürdigkeit des Batches genau darauf beruht:
- **Zwei Ketten von Anfang bis Ende, vier bis zur Senke.** Befund 2 führte ein vollständiges anonymes HTTP-Anfragepaar gegen das eigene VM-Image des Herstellers aus und bestätigte die Ausführung der geschriebenen Seite; der `diag`-Handler von Befund 3 wurde auf Instruktionsebene aus der veröffentlichten Firmware sowie auf Befehlsebene durch Injektion von drei Payload-Formen mit einer benignen Kontrolle verifiziert; Befunde 4-6 wurden durch Firmware-Quellcode-Analyse plus native-gcc-Shell-Replikation jeder exakten Senkenkonstruktion verifiziert, Marker und benigne Kontrollen eingeschlossen; Befund 1 wurde an der Request-Path-Zeile in der Disassembly und anschließend durch native-gcc-Senkenreplikation für drei unabhängige Marker plus eine benigne Kontrolle verifiziert. Für keinen nicht-live Befund wird eine End-to-End-Behauptung aufgestellt, und die README-Zeile des Batches für jeden sagt mit genau diesen Worten „disassembly" oder „replication".
- **Blickwinkel, einheitlich:** Anfragen oder Ausführungen überschritten in keinem Befund dieses Batches eine nicht vertrauenswürdige Netzwerkgrenze. Wo ein Befund einen weiteren Geltungsbereich als die Replikationsumgebung beansprucht, ist dieser Anspruch an ein ausgeliefertes Artefakt geknüpft — eine In-Image-Bindung oder eine In-Image-Web-Stack-Konfiguration — und sagt das mit diesen Worten.
- **Was unser eigener Harness beisteuerte** — denn ein von uns erzeugter Zustand ist kein Produktstandard: die Replikations-Hostumgebung (Sandbox-Kontoidentitäten als Eigenschaft des Hosts gemessen und dann in die Behauptungen der Befunde darüber gespiegelt, was auf der Geräteseite NICHT beansprucht wird); die benignen Kontrollen, die einen Befund von einem Zufall trennen; die Einmal-Abschlussmarker (ein Einwegfenster), wo ein Einstiegspunkt nach der ersten Nutzung geschlossen wird.
*Jeder vorherige Batch und seine Advisories sind unter [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) aufgeführt.*
*Jeder vorherige Batch und seine Advisories sind unter [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) aufgeführt.*
---
## 🔁 Eine fortlaufende Serie — wöchentliche Offenlegungen
Dies ist eine **fortlaufende Offenlegungsserie**. Dank kontinuierlicher Optimierung erzeugt die KI-gesteuerte Discovery-Pipeline nun neue 0-Day-Befunde in einer stabilen täglichen Rate, und wir legen verifizierte Batches im **wöchentlichen Rhythmus** offen.
- **Neuester Batch**: Batch 16 — 6 Advisories; kumulativ 144 über 16 Batches
- **Nächster Drop**: jeden Montag oder Dienstag
- **Zukünftiger Umfang**: Ausweitung über Enterprise-IT hinaus auf **ICS / SCADA, Energie und Luft- und Raumfahrt**-Systeme
Wenn du den nächsten Drop in dem Moment mitbekommen willst, in dem er erscheint:
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star** zum Merken · 👁 **Watch** (benutzerdefiniert → Releases + Discussions) für neue Batches · 🌐 **Follow** dem Blog für Updates zu einzelnen Advisories.
---
## 📂 Format für Schwachstellen-Einreichungen
Alle offengelegten Schwachstellen folgen einer standardisierten Verzeichnisstruktur:
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### Verzeichnisregeln
- **product/**: Stammverzeichnis für alle Schwachstellen
- **<vendor>/**: Hersteller- oder Produktname (z. B. `apache`, `cisco`, `sonicwall`)
- **<version>/**: Betroffener Versionsbereich (z. B. `6.11.0`, `12.4.2`)
- **<vulnerability_type>/**: Klassifizierung (z. B. `unauth-rce`, `auth-bypass`, `deserialization-rce`)
### Erforderliche Dateien in jedem Schwachstellenverzeichnis
1. **exploit/**: Verzeichnis mit funktionierenden Exploit-Skripten und PoC-Code
2. **analysis.md**: Umfassende technische Analyse einschließlich Ursache, Angriffsvektor und Auswirkungen
3. **summary.md**: Prägnante Übersicht der Schwachstelle mit betroffenen Versionen und schnellen Gegenmaßnahmen
### Beispiel
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
**Gestalte mit uns die Neudefinition der Schwachstellenoffenlegung für das KI-Zeitalter.**