vuln-report

漏洞报告

概述

为一个已确认的漏洞起草一份可供披露的报告。报告应以证据为依据，内容具体且简洁。优先遵循 references/report-template.md 中的章节顺序和措辞规则。

工作流程

1. 确认报告只涉及一个漏洞。
2. 提取证明问题所需的最少事实：
   • 存在漏洞的组件或行为
   • 由攻击者控制的输入或缺失的验证
   • 前置条件和信任边界
   • 利用结果
   • 实际影响
   • 最有力的复现路径
   • 关键源码位置及任何相关修复提交
3. 区分已证实的事实和推断。明确说明假设。
4. 按照 references/report-template.md 中规定的章节顺序起草报告。
5. 始终嵌入至少一个来自关键代码路径的围栏代码片段，并说明每个代码片段证明了什么。
6. 始终将仓库文件引用和补丁引用转换为 GitHub Markdown 链接，并优先将这些链接直接嵌入相关说明中，而不是单独列出。
7. 只添加能实质提升准确性或分流价值的可选章节。
8. 将最终报告保存为 report.md，并放入以漏洞严重性标识符（如 C1、H1、M1 等）开头、后接根据最终报告标题生成的小写连字符分隔 slug 的文件夹中。严重性标识符分别使用 C（严重）、H（高）、M（中）；如果同一严重性级别存在多个漏洞，则按顺序编号。例如：C1-cross-site-websocket-hijacking-re-enabled-by-allow-websocket/report.md。此外，确保漏洞报告标题和内部引用中都使用此 ID（例如，[C1] 跨站 WebSocket 劫持）。低危漏洞不要撰写报告，只在汇总表中记录。
9. 定稿前删除填充内容、模糊措辞和未经证实的主张。

必需章节

始终按以下顺序包含这些章节：

1. Summary
2. Details
3. Root Cause
4. Proof of Concept (PoC)
5. Impact

如果仓库已在 Technical Details 下嵌套 Root Cause，则保留该本地格式。否则，将 Root Cause 作为独立章节。

证据规则

• 在报告中添加一个或多个围栏代码片段，通常放在 Details 或 Root Cause 中。
• 使用能证明漏洞的最小代码片段。
• 引用每个代码位置时，先简要说明其重要性；不要只列出未经说明的原始链接。
• 如果仓库托管在 GitHub 上，且目标 URL 已知或可以推导，则为源码文件、行锚点、控制器、辅助函数、补丁提交或受影响区域添加 GitHub Markdown 链接。
• 构造 GitHub 源码链接时，使用最新提交 SHA（通过 git rev-parse HEAD 获取，或使用上下文中可见的最新提交），而不是 main 或 master 等分支名称，以确保链接在未来提交后仍保持稳定。
• 优先将 Markdown 行内链接嵌入说明性句子中，例如：[build_request](https://github.com/org/repo/blob/main/src/executor.rs#L10) 中的以下代码会在未验证的情况下读取攻击者控制的输入。
• 非 GitHub 标准或规范的引用保留为普通 Markdown 链接。

自包含规则

report.md 是一份可直接披露的文档。读者无需打开任何同级工作文件（草稿、讨论记录、审查备注、内部元数据），就必须能够理解漏洞、攻击链、影响和复现方法。

• 不要使用指向其他文档的说明文字，例如 See draft.md、See debate.md、See adversarial-review.md、See metadata.json、See pN-NNN for full trace、See AP-NNN、Refer to the draft for impact analysis 或 for the full trace see ...。如果报告需要这些内容，请直接写入报告。
• 不要引用内部阶段 ID（pN-NNN、p10-NNN、AP-NNN）——这些是流水线内部记录，不是面向读者的引用。
• 仅当同级文件是随报告一起提供的可运行证据产物（例如 poc.<ext>、evidence/<file>）时，才允许引用；且只能在概念验证或影响部分引用。不要让读者去打开日志，应在正文中引用其中的关键行。
• 指向源代码的 GitHub 链接（固定到某个提交 SHA）属于外部证据，而非延后叙述——必须提供，不能省略。
• 定稿前，请检查草稿中是否包含上述禁止的措辞，并改写所有此类内容，将相关信息直接写入正文。

章节规则

摘要

开篇用一段简短文字说明易受攻击的行为、攻击者可控的内容以及造成的结果。只有在有助于清晰表达时，才指出组件名称。

详情

解释代码路径以及保护措施失效的原因。包含相关条件，例如身份验证模式、无状态模式、解析器行为、MIME 混淆或传输假设。使用代码片段和指向确切源代码位置的 GitHub Markdown 链接作为佐证。

根本原因

在一个聚焦的小节中说明设计或实现上的错误。尽量使用因果性表述，例如缺少来源验证、不安全地信任从扩展名推导出的 MIME，或策略仅在一种执行模式下生效。

概念验证（PoC）

采用最简短且可靠的复现方法。优先使用编号步骤，以及可运行的请求、命令或代码块。说明预期结果。

影响

描述可利用性及后果，而不仅仅是严重性标签。说明哪些人会受到影响、攻击者能获得什么，以及哪些环境风险最高。

可选章节

只有在能为问题分诊提供具体价值时，才加入可选章节。

允许的可选章节包括：

• 顶部的简短报告标题
• 漏洞类型
• CWE
• CVSS 向量或严重性指导
• 攻击前提或身份验证实际要求
• 受影响的攻击面或范围说明
• 规范或指导文档引用
• 补丁或修复提交元数据
• 漏洞利用限制、非默认假设或部署条件

除非用户明确要求，否则不要添加“受影响组件”或“修复措施”章节。

质量标准

• 每份报告只描述一个漏洞。
• 使用严重性前缀为漏洞编号（C1、H1、M1），并在报告标题和文件夹名称前加上此 ID。低严重性问题不单独报告。
• 将每份单漏洞报告保存到 <ID>-<title-slug>/report.md。
• 漏洞利用过程必须在没有外部上下文的情况下易于理解——明确要求无需打开任何同级工作文件（draft.md、debate.md、adversarial-review.md、metadata.json）。参见自包含规则。
• 不得使用指向同级叙述性文件的说明文字，也不得引用内部阶段 ID（pN-NNN、AP-NNN）。请将相关内容直接写入正文。
• 在相关情况下，使用准确的文件路径、端点、标头、选项或模式。
• 区分已观察到的行为和可能造成的影响。
• 使用适度的严重性描述，避免夸大。
• 若源材料已有特定于该仓库的术语，应予以保留。
• 每份报告都必须包含围栏代码片段和 GitHub Markdown 链接。
• 最终报告应可直接粘贴到安全公告、审计发现或维护者问题中，只需极少整理。