# 0day Rubbish
> **在 AI 时代，0day 漏洞已经沦为垃圾。**
[](./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)
**🌐 官方网站**：<https://0day-rubbish.com/blog>
---
## 🎯 为何存在
传统的漏洞披露机制已经失灵。它缓慢、官僚化且效率低下。在 AI 时代，我们可以大规模批量生产 0day——这使得单个漏洞的价值降低，但直接披露时的影响却更大。
我们相信**事件驱动的安全加固**是最有效的方法：只有当厂商面临真实、可利用的威胁时，他们才会优先修复。
## 🔄 我们的披露流程
### 第一步：AI 发现
我们的自动化 AI 系统持续扫描真实世界软件中的漏洞，通过模式分析、模糊测试和智能代码审查来识别潜在的 0day。
### 第二步：验证与 PoC 开发
每个发现都经过人工验证。我们开发可用的概念验证漏洞利用程序，以确认可利用性并评估真实世界的影响。
### 第三步：定期公开披露
每周——周一或周二——我们披露一批新的、经过验证且可利用的 0day 漏洞，这些漏洞由我们发现并验证：
- 完整的技术分析与根本原因
- 可用的 PoC 漏洞利用代码
- 受影响的版本与系统
- 影响评估
- 建议的缓解措施
没有延迟。没有官僚主义。只有事实。
**致所有厂商**：我们希望你们能在黑客利用这些漏洞之前完成修复。
## ⚡ 核心原则
- **仅限真实世界影响**：我们只披露影响具有实际用户基础的真实世界系统的漏洞
- **无价值目标不予披露**：不可利用的漏洞或用户采用率极低的设备被排除在外——它们是毫无价值的垃圾
- **速度优先于协议**：直接披露比传统渠道能推动更快的行动
- **证据胜于声明**：每次披露都包含可用的漏洞利用程序
- **影响重于数量**：专注于高严重性、广泛部署的漏洞
- **透明**：完整的技术细节，没有隐藏议程
- **非营利**：由对安全研究的热情驱动，而非经济利益
## 🤝 合作
我们与以下伙伴合作：
- 推进自动化安全研究的顶尖 AI 模型提供商
- 探索 AI 驱动发现的安全研究人员
## 🤖 使用的 AI 模型
我们的自动化漏洞发现利用来自领先 AI 提供商的尖端大型语言模型：
- **Anthropic (Claude)** - 深度安全模式识别与推理
- **OpenAI** - 高级推理与代码分析
- **DeepSeek** - 专业漏洞检测
- **Z.ai (GLM)** - 长上下文代码分析
- **Moonshot (Kimi)** - 长上下文安全分析
---
## 📋 已披露漏洞
AI 驱动的研究流程（多 LLM 集成：Claude、OpenAI、DeepSeek、GLM、Kimi）在真实世界企业软件中发现 0day。以下每份公告都附带**完整的根本原因分析**以及**可用的、可复现的漏洞利用脚本**——没有仅检测的报告，没有隐瞒细节。
### 最新批次 — 批次 16（6 份公告）
*六项发现都需要审计者自己的工具才能证实，且没有任何一项声称超出工具所显示的内容：一对匿名上传请求针对一个 PHP 端点，该端点从未超越其 2007 年时代的认证模型；一个路由守护进程的诊断端点反转了自身的主机名验证器；一台消费级路由器的 SOAP 应用安装字段变成了 shell；以及三个独立入口进入某工业蜂窝路由器的 shell 构建配置面。六项中有四项公布的数值低于原始来源记录所暗示的数值，而每一次下调都连同其算术过程一并印在它所修正的评分旁边。*
| # | 产品 | 受影响版本 | CVSS | 类别 | 公告与 PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | LAN 侧管理平面上的 SOAP InstallApp 动作通过 `apName` 参数构建 `rm -rf` shell 命令；`$(...)` 替换在命令词解析之前就到达了以 root 配置的 Web 栈 | [InstallApp apName → shell 命令替换](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | 一个裸 `copy()` 上传端点，无会话、无扩展名门控、无路径检查，延续了该厂商已停产产品线使之闻名的 Web 根目录落地模式；一对匿名请求即可写入一个可执行页面并将其取回 | [upload.php → Web 根目录写入 → Web 侧代码执行](https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce) |
| 3 | Raritan PX3 PDU G4 | 固件 4.3.14 | **8.8** \* | 一个诊断 `ping`/`traceroute` 处理器，其主机名验证器反转了自身的返回值检查，可被每个普通已认证会话访问，而 `netstat` 带有一个仅限管理员的属性，诊断对缺少该属性 | [diag ping → 返回值反转 → 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** \* | 管理 UI 的程序表将其 `argument` 字段直接传入用户程序启动器的命令行 | [Executer argument → 程序启动注入](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000（同一产品，同一批次） | V1.0 Build 15010909 | **7.2** \* | 五个独立的 `ipsec.py` 处理器通过 shell 调用路由管理命令，携带来自隧道地址字段的攻击者文本；同一产品的发现绝不跨批次拆分 | [隧道地址 → 路由管理 shell](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000（同一产品，同一批次） | V1.0 Build 15010909 | **7.2** \* | 一个场景引擎定期重新评估已保存的 `ping` 条件，且该线程在每一轮都重新构建 shell 命令，因此存储的载荷无需攻击者重新发送任何请求即可触发 | [scenario ping → 自动执行线程](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* 六项均公布了不止一种读数。每份公告都在其所支持的读数旁边附上它拒绝或设为条件性的读数，每种读数都有自己的向量和算术：
> - **发现 1** — **6.8** 发布于 `AV:A/PR:H`：没有任何已发布的产物证明存在 WAN 侧暴露，且该操作属于管理员层级，因此“8.8 且可网络访问”这一朴素解读的两半都经不起产物核查，而源记录自身的 8.8 在内部以 PR:L 变体连同其算术过程呈现，而非作为标题。7.2 的 `AV:N` 是标注为条件性的读数，适用于管理平面被刻意暴露的部署。
> - **发现 2** — **9.8** 位于 `PR:N`。一对匿名请求；Web 层会重新提供它所写入的任何内容。执行以复制环境的 Web 服务账户身份落地，并如实报告：设备侧的服务身份从未被测量，也不作此声称。10.0 的 `S:C` 连同算术过程一并印出并被否决；`AV:A` 8.8 是标注为条件性的读数，适用于管理 VLAN 隔离；设备身份未知的警示在摘要中醒目印出，并在文件名和正文中重复：本发现的标题、slug 或正文中均不携带任何“root”或“system”声称。厂商已停产产品线中的家族型号上传谱系按本公告系列的内部规则，以不含任何标识符的模式形式描述。
> - **发现 3** — **8.8** 位于 `PR:L`：已发布的 `netstat` 与诊断属性之间的不对称性，正是证明任何普通会话即为预期主体类别的产物；出厂默认账户对作为一项独立的相邻弱点披露，附带其自身的条件性 `PR:N` 9.8 读数，绝不作为本发现的向量。7.2 的 `PR:H` 印出并被否决。
> - **发现 4-6** — 三者均为 **7.2** 位于 `PR:H`，印出时附带更正说明：源记录的 8.8 是在更正后的 881 关系家族规则下的 `PR:L` 算术，作为被否决的变体算术并列展示。三项出厂默认凭据条件性读数（各 9.8，若未更改）均被标注，绝不作为标题，且 `S:C` 9.1 对三者均印出并被否决。三者均携带诚实的负面结果：场景 ping 接收器中的分号载荷会失败并阻塞评估线程，因此可用的形式（`$(...)`、换行）随测试一并印出。
> - **验证边界，统一陈述** — 本批次中每个沙箱标记 `uid=0` 都是用于测试它的复制环境的属性，而若某已发布镜像将其自身的 Web 栈配置为 root，那是镜像内的事实，照此印出。没有任何发现矩阵声称设备侧身份，本批次中任何地方都不作实机声称：三项发现通过 `在隔离的云托管沙箱上进行接收器级复制` 测试，一项（Crystal Server）通过其自身 VM 镜像内的端到端 HTTP 链测试，一项（PX3）通过镜像的指令级分析及接收器的命令级复制测试（无端到端；RPC→cfgd→硬件链在模拟环境下无法完成），一项（RAX120）通过指令级请求路径反汇编，加上针对三个相互独立的标记及一个良性对照的原生 gcc 接收器复制测试。
> - **Root 与身份声称，逐项核实**：已发布的 9.8（`发现 2`）明确不声称 root 或 system；已发布的 `发现 4-6` slug 声称止于“shell-injected into the management stack”，并披露复制沙箱身份为 `uid=0` 行的来源；RAX120 发现的 slug 和行内声称是本批次中唯一携带 root 一词的，其两个锚点均为镜像内 lighttpd 的 `User root` 配置，加上三个零 ID 标记和一个对照，绝非实机。
**总计**：6 条公告 · 4 个产品 · 4 家厂商组织（NETGEAR、NUUO、Raritan/Legrand、Moxa），其中 MAR-2000 系列占据三条，因为同一产品的合格发现绝不会被拆分到不同批次 · 1 条未认证链 · 5 条认证链，其中四条明确要求管理员级会话，一条要求任意普通会话。单个 6.8 承载了知名品牌席位的主标题，而这刻意是本批次中最不戏剧化的数字：`AV` 和 `PR` 都降至已发布工件所证明的水平，而非朴素模型模板所暗示的水平，已发布的 `Totals` 也如实说明了这一点。六条中有四条发布的至少一个数值低于原始来源记录所暗示的水平——两次是无证据的 WAN 侧，四次是错误录入的 PR 等级——而每一次降级都印在读者能看到的地方，被拒绝的算术、向量、理由和更正历史与存留的评分并列呈现。
**仪器实际显示的内容**——之所以明确说明，是因为本批次的可信度恰恰建立在此之上：
- **两条链端到端，四条到汇聚点。** 发现 2 针对厂商自己的 VM 镜像运行了完整的匿名 HTTP 请求对，并确认了所写页面的执行；发现 3 的 `diag` 处理器通过已发布固件进行了指令级验证，并通过三种载荷形态的命令级注入（含良性对照）进行了验证；发现 4-6 通过固件源码分析以及针对每个精确汇聚点构造的原生 gcc shell 复现进行了验证，包含标记和良性对照；发现 1 在反汇编中的请求路径行处进行了验证，随后通过原生 gcc 汇聚点复现对三个独立标记加一个良性对照进行了验证。对任何非实时发现均未做出端到端声明，本批次中每条发现的 README 行都明确写着“反汇编”或“复现”。
- **视角，统一而言：** 本批次任何发现中的请求或执行均未跨越不可信网络边界。当某项发现声称的范围超出复现环境时，该声明锚定于已发布工件——镜像内绑定或镜像内 Web 栈配置——并明确如此表述。
- **我们自己的测试框架提供了什么**——因为我们创建的状态不是产品默认值：复现主机环境（沙箱账户身份作为主机属性进行测量，然后镜像到发现中关于设备侧未声称内容的声明中）；将发现与意外区分开的良性对照；在入口点首次使用后关闭的单次使用闭合标记（单向窗口）。
*所有之前的批次及其公告均列于 [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) 下。*
*所有之前的批次及其公告均列于 [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) 下。*
---
## 🔁 持续系列——每周披露
这是一个**持续披露系列**。得益于持续优化，AI 驱动的发现流水线现在以稳定的每日速率产出新的 0-day 发现，我们以**每周节奏**披露已验证的批次。
- **最新批次**：批次 16——6 条公告；16 个批次累计 144 条
- **下次发布**：每周一或周二
- **未来范围**：从企业 IT 扩展到 **ICS / SCADA、能源和航空航天**系统
如果你想在下次发布落地的那一刻抓住它：
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star** 以收藏 · 👁 **Watch**（自定义 → Releases + Discussions）以获取新批次 · 🌐 **Follow** 博客以获取每条公告的更新。
---
## 📂 漏洞提交格式
所有已披露的漏洞均遵循标准化的目录结构：
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### 目录规则
- **product/**：所有漏洞的根目录
- **<vendor>/**：厂商或产品名称（例如 `apache`、`cisco`、`sonicwall`）
- **<version>/**：受影响的版本范围（例如 `6.11.0`、`12.4.2`）
- **<vulnerability_type>/**：分类（例如 `unauth-rce`、`auth-bypass`、`deserialization-rce`）
### 每个漏洞目录中必需的文件
1. **exploit/**：包含可用的漏洞利用脚本和 PoC 代码的目录
2. **analysis.md**：全面的技术分析，包括根本原因、攻击向量和影响
3. **summary.md**：简明的漏洞概述，包含受影响版本和快速缓解步骤
### 示例
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
---
**与我们一起重新定义 AI 时代的漏洞披露方式。**
