0day-Rubbish batch-8-2026-08
Redefining vulnerability disclosure in the AI era. We mass-produce exploitable 0days and disclose them directly, using event-driven pressure to elevate vendor security standards and advance the field.
0day Rubbish
0day vulnerabilities have become rubbish in the AI era.
🌐 Official Website: https://0day-rubbish.com/blog
🎯 Why This Exists
Traditional vulnerability disclosure is broken. It's slow, bureaucratic, and ineffective. In the AI era, we can mass-produce 0days at scale—making individual vulnerabilities less valuable but more impactful when disclosed directly.
We believe event-driven security hardening is the most effective approach: only when vendors face real, exploitable threats do they prioritize fixes.
🔄 Our Disclosure Process
Step 1: AI Discovery
Our automated AI systems continuously scan for vulnerabilities across real-world software, identifying potential 0-days through pattern analysis, fuzzing, and intelligent code review.
Step 2: Verification & PoC Development
Each finding undergoes manual validation. We develop working proof-of-concept exploits to confirm exploitability and assess real-world impact.
Step 3: Periodic Public Disclosure
Every week — Monday or Tuesday — we disclose a new batch of verified, exploitable 0-day vulnerabilities we've discovered and validated:
- Full technical analysis and root cause
- Working PoC exploit code
- Affected versions and systems
- Impact assessment
- Recommended mitigations
No delays. No bureaucracy. Just facts.
To all vendors: We hope you can complete fixes before hackers exploit these vulnerabilities.
⚡ Core Principles
- Real-world impact only: We disclose only vulnerabilities that affect real-world systems with actual user bases
- No worthless targets: Non-exploitable vulnerabilities or devices with negligible user adoption are excluded—they're rubbish with zero value
- Speed over protocol: Direct disclosure drives faster action than traditional channels
- Proof over claims: Every disclosure includes working exploits
- Impact over quantity: Focus on high-severity, widely-deployed vulnerabilities
- Transparency: Full technical details, no hidden agendas
- Non-profit: Driven by passion for security research, not financial gain
🤝 Collaboration
We partner with:
- Top AI model providers advancing automated security research
- Security researchers exploring AI-powered discovery
🤖 AI Models Used
Our automated vulnerability discovery leverages cutting-edge large language models from leading AI providers:
- Anthropic (Claude) - Deep security pattern recognition and reasoning
- OpenAI - Advanced reasoning and code analysis
- DeepSeek - Specialized vulnerability detection
- Z.ai (GLM) - Long-context code analysis
- Moonshot (Kimi) - Long-context security analysis
📋 Disclosed Vulnerabilities
An AI-driven research process (multi-LLM ensemble: Claude, OpenAI, DeepSeek, GLM, Kimi) discovers 0-days in real-world enterprise software. Every advisory below ships a full root-cause analysis plus a working, reproducible exploit script — no detection-only writeups, no withheld details.
Latest Batch — Batch 16 (6 advisories)
Six findings that all took the auditor's own instruments to prove, and none of which claims more than the instruments showed: one anonymous upload pair against a PHP endpoint that never outgrew its 2007-era authentication model; one routing daemon's diagnostics endpoint that inverted its own hostname validator; one consumer router whose SOAP app-install field became a shell; and three separate entry points into an industrial cellular router's shell-built configuration surface. Four of the six publish a figure lower than the raw source record suggested, and each of those downgrades is printed with its arithmetic beside the score it corrects.
| # | Product | Affected Version | CVSS | Class | Advisory & PoC |
|---|---|---|---|---|---|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | 6.8 * | The SOAP InstallApp action on the LAN-side management plane builds an rm -rf shell command over the apName argument; a $(...) substitution reaches the root-configured web stack before the command word resolves | InstallApp apName → shell command substitution |
| 2 | NUUO Crystal Server | 3.19.0.85 | 9.8 * | A bare copy() upload endpoint with no session, no extension gate and no path check, carrying on a web-root landing pattern the vendor's discontinued line made famous; a single anonymous request pair writes an executable page and fetches it back | upload.php → web-root write → web-side code execution |
| 3 | Raritan PX3 PDU G4 | firmware 4.3.14 | 8.8 * | A diagnostics ping/traceroute handler whose hostname validator inverts its own return check, reachable by every ordinary authenticated session while netstat carries an admin-only attribute the diagnostics pair is missing | diag ping → return-value inversion → shell injection |
| 4 | Moxa MAR-2000 FWR_MAR2000 V1.0 Build 15010909 | V1.0 Build 15010909 | 7.2 * | The management UI's program table passes its argument field straight into the user-program launcher's command line | Executer argument → program-launch injection |
| 5 | Moxa MAR-2000 (same product, same batch) | V1.0 Build 15010909 | 7.2 * | Five separate ipsec.py handlers shell out into route-management commands carrying attacker text from the tunnel-address fields; one product's findings are never split across batches | tunnel address → route-management shell |
| 6 | Moxa MAR-2000 (same product, same batch) | V1.0 Build 15010909 | 7.2 * | A scenario engine periodically re-evaluates a saved ping condition, and the thread re-forms the shell command on each pass, so a stored payload fires without any request ever being resent by the attacker | scenario ping → auto-execution thread |
* All six publish more than one reading. Each advisory carries the readings it rejected or made conditional next to the one it stands behind, each with its own vector and arithmetic: