Exploit-Garbage/0day-Rubbish

# 0day 垃圾 ## 🎯 为什么会有这个项目 传统的漏洞披露机制已经失效了。它既缓慢、官僚，又低效。在 AI 时代，我们可以大规模批量生产 0day——这使得单个漏洞的价值降低，但在直接披露时却能产生更大的影响力。 我们坚信**事件驱动的安全加固**是最有效的策略：只有当供应商面临真实的、可利用的威胁时，他们才会优先进行修复。 ## 🔄 我们的披露流程 ### 步骤 1：AI 发现 我们的自动化 AI 系统会持续扫描真实世界软件中的漏洞，通过模式分析、fuzzing 和智能代码审查来识别潜在的 0day。 ### 步骤 2：验证与 PoC 开发 每一项发现都会经过人工验证。我们会开发可运行的 proof-of-concept exploit，以确认其可利用性并评估在真实世界中的影响。 ### 步骤 3：不定期的公开披露 我们会定期披露那些我们已经发现并验证过的、可利用的 0day 漏洞： - 完整的技术分析与根本原因 - 可运行的 PoC exploit 代码 - 受影响的版本与系统 - 影响评估 - 建议的缓解措施 没有拖延。没有繁文缛节。只有事实。 **致所有供应商**：我们希望你们能在黑客利用这些漏洞之前完成修复。 ## ⚡ 核心原则 - **仅限真实世界影响**：我们只披露影响真实世界系统且拥有实际用户群体的漏洞 - **拒绝无价值目标**：排除无法利用的漏洞或用户采用率极低的设备——它们就是毫无价值的垃圾 - **速度优先于协议**：直接披露比传统渠道更能推动快速行动 - **证据优先于声明**：每次披露都包含可运行的 exploit - **影响优先于数量**：专注于高严重性、广泛部署的漏洞 - **透明度**：提供完整的技术细节，没有隐藏目的 - **非营利**：出于对安全研究的热爱而驱动，而非经济利益 ## 🤖 使用的 AI 模型 我们的自动化漏洞发现利用了前沿的大语言模型： - **GPT-5.5** - 高级推理与代码分析 - **Claude Opus 4.8** - 深度安全模式识别 - **DeepSeek V4** - 专门的漏洞检测 ## 📂 漏洞提交格式 所有披露的漏洞都遵循标准化的目录结构： ``` product/ └── / └── / └── / ├── exploit/ # Exploit scripts and PoC code ├── analysis.md # Detailed vulnerability analysis └── summary.md # Brief vulnerability overview ``` ### 目录规则 - **product/**: 所有漏洞的根目录 - **/**: 供应商或产品名称（例如：`apache`, `microsoft`, `oracle`） - **/**: 受影响的版本范围（例如：`2.4.49`, `11.0.12`） - **/**: CVE 风格的分类（例如：`rce`, `sql-injection`, `auth-bypass`） ### 每个漏洞目录中必需的文件 1. **exploit/**: 包含可运行的 exploit 脚本和 PoC 代码的目录 2. **analysis.md**: 全面的技术分析，包括根本原因、攻击向量和影响 3. **summary.md**: 简明的漏洞概述，包含受影响版本和快速缓解步骤 ### 示例 ``` product/ └── apache/ └── 2.4.49/ └── path-traversal/ ├── exploit/ │ ├── poc.py │ └── exploit.sh ├── analysis.md └── summary.md ``` **加入我们，共同为 AI 时代重新定义漏洞披露。**

标签：CISA项目, Cutter, Maven, PoC, 人工智能, 暴力破解, 漏洞披露, 漏洞验证, 用户模式Hook绕过, 逆向工具