vulnerability-writeup

用途：把提供的漏洞笔记、披露文档、现有报告、PoC、源码树或扫描发现作为输入，产出供其他安全研究者理解、检查并尽量复现的披露报告。将原始发现视为假设而非结论，需先确认受影响软件版本、攻击者位置、可达入口、预期安全行为、实际失败与最小可证明影响。不要求扫描 ID、finding bundle 或 Codex Security 扫描产物。\n\n主要能力：每个独立漏洞对应独立报告目录，仅由一个起草子代理负责，主代理负责清点、去重、源码核对与最终验收。若可获得确切易受攻击源码版本，需实际检查，尽量在内部解析完整提交，并记录 dirty、shallow、缺失、已修补或不匹配等状态；对分发包需按确切已修补源码核验每个引用片段和行号。可用 git show REV:PATH 查看未检出修订。当源码与发布历史可得时，追溯引入漏洞的变更，检查标签、发布分支、修复与回移，确定最早受影响版本与修复版本，不把未验证提交范围当作受影响版本声明。\n\n使用方式：先建立证据清单，包括原始发现、源码根与固定提交或标签、受影响路径与函数、Alice/Bob/Mallory/Eve 等命名角色及其真实权限与可控输入、攻击面、有限原语、PoC 与日志、以及测试授权与一次性环境。把最小触发写成假设后再跟踪。起草前阅读 references/report-format.md，并按单漏洞子代理提示提供材料；Codex Security 最终报告阶段写入 findings/<slug>/<slug>.md 并记录 writeup.reportPath，其他情况保留用户指定目录与文件名，仅在有真实 PoC 产物时才建 poc/ 目录。\n\n限制：不得编造源码片段、行号、版本、CVE、CVSS 向量、利用路径或运行结果；区分源码证据、已审未执行 PoC、实际运行观察与未知。仅在用户明确授权范围内测试，对崩溃、破坏性或提权 PoC 使用一次性本地目标，未经目标级许可不得测试公网、外部或生产目标。无法获得确切源码或修订时应停下索取；只有用户明确接受时才做仅报告评估，且所有依赖源码的结论保持有条件。缺少标签或历史时须说明，不得断言确定的最早受影响版本。delegation 不可用时需报告限制，而非在主代理中静默起草生产扫描发现。