report — 漏洞报告成稿收口

EN: This skill turns confirmed vulnerabilities into submission-ready DOCX reports. The body is in Chinese because the target platforms (Chinese SRCs, CNVD/CNNVD, EDUSRC) require Chinese reports; the methodology is language-agnostic. See README.md for an English overview.

这是薄编排层，只做一件事：把已确认的漏洞写成可直接提交给审核方的 DOCX 提交稿。 漏洞怎么挖、怎么验证不在本 skill 范围；但"什么漏洞够格写成报告"的分层验证门已内联在本文，自成一体。

何时用 / 何时不用

• ✅ 用：漏洞已确认（硬门过了）、准备成稿交付、扩大危害后更新报告、被驳回后追加申诉。
• ❌ 不用：还在挖 / 还在验证 / 只有单点信号没到终局 → 继续验证，别急着开报告。

前置铁律：无 PoC = 不存在漏洞；影响没落地到链路终局 = 不写报告。P3 以下不写。

---

双重审查机制（第一道挖掘期快筛，第二道成稿前严审）

别把所有判断都攒到写报告前——那时才驳回，验证花的 token 全浪费了。第一道筛在挖掘过程中就跑，明显不够格的当场止损，根本不进报告候选；只有过了第一道筛的候选漏洞，才走到第二道完整验证门。

第一道：挖掘期信号快筛（轻量，遇到信号就跑，只花判断力）

信号 ≠ 漏洞。每遇到一个信号，先花几秒钟分三档：

档位	判据	动作
当场止损	只读到自己测试账号的数据；内容是公开页面/默认样例/模板；疑似 catch-all 路由（用 zzz不存在<时间戳> 同协议跑一次就露馅）；只有版本号/指纹/安全头缺失这类无危害信息	不再追、不进候选、不记录为漏洞
待验证信号	有异常但还没打到终局	继续往"别人的数据 / 真实生效的操作 / 命令执行回显"方向追；追不到就停在信号，不写报告
候选漏洞	已看到他人真实数据 / 操作真实生效 / 命令执行回显等终局迹象	标记候选、补证据，成稿前过第二道

第一道的目的是把"注定写不成报告的方向"在深挖之前砍掉，省的是整段验证的 token。

第二道：成稿前分层验证门 —— 候选漏洞走到写报告这一步时，过下方完整判据（硬门 + 类型命门 + 质量项），缺一不写。

---

分层验证门（成稿前必过，本 skill 自带完整判据）

分两层：硬门（所有漏洞必过，缺一不报）+ 按类型命门（不同类型的"关键钥匙"）+ 质量项（尽力，不卡报告）。

硬门（所有漏洞必过，缺一不报）

0. 先证伪（正常功能排除） — 先假设"这就是正常功能"，主动跑否定实验去推翻它：未授权→用 zzz不存在<时间戳> 跑同协议，看是不是 catch-all/公开/样例；越权→用合法 body 重测排除 400 假阳性、POST 排除 SPA 回退；SSRF→确认是不是服务端正常连接功能而非越过边界。证伪不掉，才可能是漏洞；证伪掉了，作废不报。
1. PoC 可复现 — 能直接粘贴原始 HTTP 请求块（从抓包工具原文复制），不需要额外解释上下文。
2. 真实业务影响（链路终局，危害要实际打出来） — 拿到别人的 ≥3 个敏感字段真实数据 / 操作真实生效改了别人业务状态 / 凭证实际访问到敏感内容。是数据泄露/账户接管/资金损失/服务端 RCE/内网横向的终局结果，不是中间信号（文档/token/拓扑泄露不是终点），不是"理论上有风险"。打不出实际危害 = 信号作废 = 不报。
3. 服务端/权限边界确认 — 是服务端或权限边界问题，不是浏览器 JS 假象/调试功能/页面渲染。
4. 类型命门 — 命中下方按类型命门表中对应行的硬条件。
5. 链式追问到终局 — 已顺根因穷举同类接口 + 纵深追到危害边界（不是问一层就交），或已记录"为什么到此为止"。

按类型命门表（不同类型，关键钥匙不同）

漏洞类型	命门（硬条件）
数据泄露	别人的数据 + ≥3 敏感字段 + 非公开/非样例/非模板；自己测试账号数据 ≠ 漏洞
越权 / IDOR	A/B 交叉证明：A 拥有的资源，B 的 token 能读/改；只读到自己不报
RCE / 命令执行	真实命令执行实证；"别人的数据"对 RCE 天然不适用，能执行命令本身就是危害
SSRF	服务端发出（回调 UA 证明 Java/Go/Python，非客户端 JS fetch）+ 有官方靶场必须先过靶场（不过不收）；无靶场必须回显内网数据（云元数据/内网服务 banner/内网页面内容）。DNSlog 只是其中一步：出网响了 = 敲门砖，必须继续打到回显/危害终点，仅 dnslog 记录直接交 = 半成品不收
认证绕过 / ATO	任意用户可绕过/接管，不只证明自己能登自己号；OAuth/JWT/密码重置逻辑要 A/B 双账号证明
业务逻辑 / 资金	操作真实生效 + 影响的是他人业务状态（金额/订单/状态机跳转），不是自己测试数据
文件上传	造成实际效果才算：webshell 可执行（getshell）或存储型 XSS 触发（HTML/SVG 被服务端解析）；只传上去/能访问但纯存储不解析 = 不成立
注入 (SQL/NoSQL/SSTI/XXE)	有确定输出/副作用证明（错误回显、时间差、OOB marker），不是"报错就报"；SQL 注入最低共识 = 注出库名 database()（盲注需时间差 + 库名内容，特殊情况另议）

质量项（不卡报告，写进报告说明即可）

• 否定实验：对存疑结论写出"如果这不是漏洞，最可能的解释"并执行证伪。
• 跨环境复现：两个 IP/浏览器/账号/机器之一复现。
• WAF/防护绕过已记录：有防护→试了哪些绕过→结果；无防护→说明确认方式。

0day / 通用产品漏洞：收录审查门（按 0day 成稿前必过）

各收录平台（CNNVD/CNVD/补天/厂商 SRC 等）规则取最严并集，任一否决项命中 = 不按 0day 成稿。

A. 版本与公开性（最新版不带洞 = 不是 0day）

• 漏洞在厂商当前最新版仍存在：GitHub 漏洞文件引入时间 vs 最新 release tag 日期对比 / 官网下载最新版实测 / 厂商安全公告与 changelog 检索，三选一。只在未发布分支或老版本存在 → 不按 0day 成稿
• 老版本洞例外：最新版已修但老版本测绘存量巨大 → 报告必须写清受影响版本范围 + 修复版本 + 修复 commit/版本对比证据
• 未完全公开：无 CVE/CNVD/CNNVD 编号、无公开 PoC/分析文章/厂商公告；OEM/同源源码产品任一已公开 = 全线视为公开
• 产品本身三年内官方有更新维护（废弃/测试/演示系统不收）

B. 类型与前提（平台明文不收的类型，一票否决）

• 非通用型弱口令/默认口令；非"需账号密码/验证码登录后台为前提"；非用户配置不当/主动暴露；非沙箱预期功能 RCE；非单纯盲注/仅延时无明确危害；非未越权的 DOM/反射 XSS
• 同根因多个同类问题并为一洞；同系统相似类型历史只发一次
• 危害已实证（数据/权限/RCE 终局），非"存在可能性"

C. 案例与证据

• 黑盒底线 ≥10 互联网案例（3 个详细 + 10 个以上其他）；目标高奖金档位需更多独立 IP（按目标平台档位对齐，成稿前如实告知预期档位）
• 证据 2 周内（事件型 3 天内）+ 保留时间戳；案例 IP 提交时现场验证存活
• 测绘语法精准 + 独立 IP 数 + 统计来源与时间进报告
• 白盒另需：代码审计/逆向过程 + 准确版本号 + 当前最新版本证明 + 待测试程序

D. 投递纪律（诚信红线）

• 一洞只交一家（多交会被各平台拉黑/信用评估）。交前定主平台路由：未授权前台 RCE → 通用漏洞高奖金平台；认证绕过/文件读取/凭证泄露等非 RCE → CNNVD/CNVD 类；老版本洞 → CNVD/CNNVD 类；教育行业资产 → EDUSRC
• 附件齐套：Word 报告 + POC/EXP + 待测试程序 + 复现录屏（按目标平台要求）

---

核心写作标准：双重可读（每份报告都要同时做到）

报告必须同时满足两个维度，缺一份都不合格：

① 小白可复现 —— 让完全不懂安全的审核者也能照着一步步复现出来：

• 每个 Step 让人看懂：做什么 → 在哪个 URL 操作 → 实际看到什么结果；不跳步、不省略上下文、不用只有安全圈才懂的黑话而不解释。
• 但"能复现"≠啰嗦：背景交代一两句够用，禁止八股标签和填充语（见下方「简洁硬规」）。
• PoC 给可直接复制粘贴的完整原始 HTTP 请求块（从 Burp/Yakit 等抓包工具原文复制，不放 curl），配真实截图，照做就能看到同样结果。
• 逻辑连贯顺滑，像一条能走通的路，不是散落的证据堆。

② 技术不空洞 —— 该有的技术深度一分不能少：

• 讲清根因：为什么会有这个漏洞（鉴权缺失在哪一层/逻辑缺陷在哪/信任边界哪里破了）。
• 讲清原理：接口如何工作、参数如何被利用、鉴权差异如何证明、payload 为何生效。
• 给出关键技术证据：真实请求/响应字段、路由映射、代码片段、鉴权头对照、规模化数据统计。
• 结论有据可查，不是"我觉得有问题"，而是"因为 X 技术事实所以是 Y 漏洞"。

判断标准：一个产品经理照着能复现，一个安全工程师看了觉得技术扎实、无懈可击。两个都过才算合格。

---

DOCX 版式规格（格式基准，不得自由发挥）

生成方式：python-docx。从同目录 template.docx 复制起步（已含全部样式），逐节 append。不要手写 HTML 再转换。

样式（模板已内置，直接用样式名）：

• 正文 Normal（微软雅黑 11pt）；章节标题 Heading 2（13pt 加粗）；Step 标题 Heading 3；bullet 用 List Bullet。
• 全文统一黑色：模板已去除 Word 默认主题蓝（Heading/Title/边框全部 000000），标题与正文颜色一致。生成时不得再给任何文字/边框手动设置彩色。
• 不用表格堆排版、不用卡片/配色——审核接受的是朴素的线性文档。

章节骨架（Heading 2 按此顺序，可选节用〔〕标注）：

章节（Heading 2）	内容要求
漏洞名称	一句话：资产 存在 漏洞类型 + 终局危害 漏洞
漏洞等级	严重/高危/中危 + 一句定级依据（标题就叫"漏洞等级"，不加"自评"等后缀）
漏洞类型	类型全称 + CWE（如有）
漏洞影响资产	主资产域名/范围 + API 路径 + 关联资产
漏洞URL	纯 URL 列表，一行一个，不写注解（"它是干什么的、参数怎么被利用"归漏洞描述讲）
漏洞描述	功能如何工作 → 根因 → 攻击者能干什么（编号列点）→ 关键验证结论（规模数字/IP/已确认事实）
〔测试账号与会话上下文〕	测试角色、account_id、复验用 Cookie/token（注明"过期重登替换即可"）
漏洞复现步骤（POC）	见下方 Step 规格
漏洞危害	危害枚举（编号，每条带已验证事实）+ 影响数据明文样本（便于审核直接验证，不打码）+ 边界声明（未做的越权动作）。就这一节，不另开"影响数据示例"
修复建议	具体可执行（编号，含网段/参数级细节；根因已在漏洞描述讲清，不另开"根因分析"节）

报告正文到「修复建议」为止。「复验清单」「建议评级说明」「实际攻击场景」「根因分析」「漏洞关键点」「影响数据示例」一律不单开节——复验走上方分层验证门（内部动作）；定级理由只保留「漏洞等级」里的一句；攻击链时序和根因并进漏洞描述；数据样本并进漏洞危害。

0day / 通用产品漏洞：走通用型漏洞报告模板

成稿前先过上方「0day 收录审查门」（A 版本公开性 / B 类型前提 / C 案例证据 / D 投递纪律，任一否决项命中不成稿）。审查门没过 = 不按 0day 交付，回挖掘或换平台通道。

0day、通用产品漏洞不用上面的 SRC 章节骨架，一律按通用型漏洞报告模板成稿。章节顺序：

漏洞报告标题 → 漏洞发现时间 → 漏洞技术类型 → 漏洞描述（两段式：第一段产品介绍、第二段成因+危害）→ 漏洞危害 → 漏洞厂商全称 → 已知受影响产品及版本（附资产-产品强相关证明截图）→ 互联网资产证明（精准测绘语法 / 独立 IP 数量文字描述 / 测绘平台截图）→ 1、漏洞技术细节（完整 PoC：原始请求块+每步真实截图；触发条件）→ 2、复现证明（黑盒：3 个详细案例 + 10 个以上其他受影响目标）→ 3、修复方案（厂商修复 + 运维临时方案）→ 4、备注（边界声明）。

• 案例 IP 必须提交时现场验证存活，宁换不凑（云上动态实例隔天就会掉线，演示目标死掉会导致审核复现失败）。
• 测绘数据用测绘平台 API 取当日口径（独立 IP 数/国家分布/端口分布），测绘平台截图贴结果页。
• PoC 请求块用等宽字体段落；每步真实截图、不打码、不放 curl 等既有硬规全部沿用不变。

Step 规格（POC 章节内，每步严格这个结构）：

[Heading 3] Step N：一句话标题
[Normal] 一两句话交代这步做什么、在哪个 URL 操作（必要背景并入此处，不写"为什么:"标签）
[Normal] PoC:
[Normal] POST /path HTTP/2          ← 抓包工具原始请求块整段贴入（纯文本段落，不打码）
Host: ...
...
[Normal] 结果: 一句结论（证明了什么）。**不贴返回数据包原文**——响应内容以截图为准，文字只写结论
[Normal] 截图(说明这是什么的截图):
<内嵌图片>                          ← docx.add_picture，紧跟"截图"段
[Normal] 图：xx_说明.png            ← 图注一句

简洁硬规（违反即返工）：

• 禁止"为什么:"/"操作:"这类八股标签，Step 用一两句自然语言交代动作即可；背景知识确有必要才写，能省就省。
• 同一事实全文只出现一次：IP 清单、测绘数字、版本号、实证结论，写在哪一章就只在哪一章；其它章节需要时用"见漏洞描述"式指代，不整段复读。
• 相邻章节不得内容重叠：漏洞描述讲清链路和结论后，后续章节需要时用"见漏洞描述"式指代，不整段复读；漏洞危害每条一行事实，不展开复述攻击过程。
• 一句话能说完的不写三句：删掉"值得注意的是""也就是说""换句话说"类填充语，删掉对截图内容的文字复述（截图就在下面）。

去AI腔硬规（违反即返工）： 报告要读起来像安全工程师手写的，不像模型生成的。

• 内部方法论黑话不进报告：证伪/否定实验/同根因/命门/链路终局等过程词一个都不出现。这些结论用自然语言陈述事实（"同框架其余接口鉴权正常，排除是公开查询功能"），不点名方法论。
• 禁止破折号拖尾解释：结果一句话写完，不用"——证明了……/——即……/——说明……"收尾；结论确有必要时独立成短句。
• 禁止形容词渲染：删掉"极具迷惑性""防骗难度极大""恶性竞争""天然构成"类修饰，只摆事实，严重性由审核者自己判断。
• 禁止截图元描述：不写"下图为浏览器内实时请求后将响应转表格展示"这类关于截图本身的说明；截图处只有"截图（内容）:" + 图片 + 一句图注。
• bullet 不强行"主题词："排比：一事一句自然陈述，类别前缀只在确有助分类时用。
• 不单独开节游说评级：「建议评级说明」不进报告（重申）；定级依据只在「漏洞等级」留一句，升级理由融进漏洞危害的事实里。

---

成稿流程（按序执行）

第 0 步：查重（写之前必做，命中重复就停）

写任何新报告前，先 Glob/Read 目标单位的报告目录，按四项查重：

资产（同域名/IP）  根因（同一鉴权缺失/同一逻辑缺陷）  接口/功能点  影响面

• 四项高度重合 → 不新写。要么作为原报告的补强（见第 5 步），要么换资产/换漏洞类型。
• 只重合资产但根因/影响不同 → 可新写，但报告里说明与已有报告的区别。

第 1 步：过分层验证门（判据见本文「分层验证门」节）

逐条打勾，硬门缺一不写：

[ ] 硬门0 证伪：假设"这是正常功能"并跑了否定实验，证伪不掉
[ ] 硬门1 PoC 可复现：能直接粘贴原始请求块，不需额外解释
[ ] 硬门2 危害是链路终局：资金/数据/接管/RCE/横向，不是中间信号
[ ] 硬门3 服务端/权限边界确认：不是浏览器 JS 假象/调试/渲染
[ ] 硬门4 命中类型命门（见上方按类型命门表对应行）
[ ] 硬门5 同根因接口穷举完、纵深追到边界，或记录"为什么到此为止"
[ ] 质量 否定实验：对存疑结论写出"如果这不是漏洞最可能的解释"并证伪
[ ] 质量 跨环境/跨账号/跨IP 至少一种复现
[ ] 质量 WAF：有防护记录绕过；无防护说明确认方式
[ ] 截图 每一步都有真实截图（浏览器打开原始 URL / 抓包工具实际响应，后台截图不抢前台），无一处自造渲染
[ ] 双读 小白照着能复现（操作→PoC→结果）且技术不空洞（根因+原理+关键证据）

硬门全过 → 写。质量项缺 → 不卡报告，但报告里说明。

第 2 步：生成 DOCX

复制 template.docx → python-docx 按「DOCX 版式规格」逐节填充。要求：

• 每个 Step 的截图用 doc.add_picture(png路径, width=Inches(6)) 内嵌，紧跟"截图(...):"段落。
• PoC 请求块保持等宽可读：整块作为独立 Normal 段落（可用单个段落内换行），不打码。
• 数字、IP、marker、时间等所有事实必须与截图/原始日志逐字一致——写完回读截图核对一遍。凭记忆写数字极易出错（真实教训：一份报告里 DNSLog 数字凭记忆写了四处，全错，复核时才抓出来）。

截图铁律（最高优先级，绝不违反）

报告每一步都必须配真实截图，绝不允许自己 PS/仿造/手绘渲染效果。

• 截图来源只能是：浏览器打开目标原始 URL/响应后截图（用浏览器自动化工具的后台截图能力）、抓包工具实际请求/响应的证据（文本块或详情面板截图）。
• 凡绕过限制后能在浏览器直接打开渲染的图片/视频/页面/文件/JSON 响应 → 必须用浏览器打开原始 URL 截图放进报告。
• 每个 Step 的关键结果都要有对应截图，让审核者能看到"我确实在真实目标上看到了这个"。
• 唯一例外：目标内容客观无法在浏览器渲染时，才允许离线渲染/转存，并在报告里明确写出为什么无法用浏览器直接截图。
• PoC 数据包以文本完整保留即可，审核方会另行核对，不强制截图（但有请求/响应详情截图更好）。

截图行为纪律（不打扰用户 + 证据可用，必守）

• 全程后台截图，禁止抢前台：截图过程不能打断用户当前操作，任何窗口都不应被弹到前台。
  • 浏览器截图：用 headless 模式或 CDP 类后台截图（Playwright headless、Page.captureScreenshot 等），禁止把浏览器窗口激活/聚焦到前台。
  • 抓包工具界面截图（确有必要时）：用后台窗口截图（如 Windows 下 PrintWindow 按窗口句柄抓图），禁止 SetForegroundWindow / Activate / 模拟点击把 Burp/Yakit 等窗口拉到前台。
• 数据包证据优先文本块：请求/响应一律以原始文本块嵌入 PoC（照抄抓包工具原文），不依赖工具界面截图。确实要截工具界面时，必须打开数据包详情的 Request/Response 面板再截——禁止只截历史列表（列表里没有包内容，审核无法核对，等于没截）。
• 工具中立：Burp Suite / Yakit / Reqable / mitmproxy / Caido 等任何抓包工具均可，报告里是"原始请求块"，不绑定具体工具。

截图 PNG 统一放临时目录 shots/（与 DOCX 同目录）。图片已内嵌 DOCX，报告成稿交付后 shots/ 随其它临时产物一并删除，不长期留存。

截图能力检测与降级（开工前先判定，三级阶梯）

AI 不是天生会截图——截图能力来自浏览器自动化工具（MCP）。成稿流程开始时先检测当前环境，按三级阶梯走：

1. 自动检测：检查当前可用工具列表，凡是能"打开 URL + 截图"的都算——Playwright MCP、chrome-devtools MCP、Puppeteer MCP 等浏览器类 MCP 提供的 navigate/screenshot 工具。检测到就直接用，每个 Step 由 AI 打开原始 URL 自动截图，无需询问用户。
2. 没有工具 → 给建议：明确告诉用户"检测到当前环境没有浏览器工具，无法自动截图"，并给出推荐安装命令（如 claude mcp add playwright -- npx @playwright/mcp@latest）。用户愿意装 → 装完回到第 1 级全自动。
3. 用户不装 → 人工供图：每到一个需要截图的 Step，明确告诉用户"请把这一步的抓包工具/浏览器截图保存为 shots/step<N>_<说明>.png"，用户放好后嵌入对应位置。禁止因为没工具就静默跳过截图、用"此处应有截图"占位、或用文字描述代替。

用户也不提供截图 → 报告不满足截图铁律，明确告知"缺真实截图的报告大概率被平台驳回"，由用户决定是否继续，不偷偷降级成无图报告。

提交前自检（交稿前必过）

• 截图裁掉/遮盖：任务栏、本机用户名（含路径里的用户名）、其他浏览器标签页标题、书签栏、浏览器登录头像
• 请求块：不含与漏洞无关的个人标识（自己的 cookie/token/测试账号之外的隐私信息）
• PoC/正文：本地路径打码；IOC 按目标平台风控规则脱敏（有平台会因正文含特定 IOC 关键词整单拒收，被拦时二分定位脱敏）
• DOCX 元数据：作者/公司字段清空（生成后检查 docProps/core.xml）
• 报告内不留测试基础设施细节（代理、接码、邮箱服务商等）

去 AI 腔检查（交稿前必过）

平台审核开始用 AI 检测+人工直觉筛报告，模板化 AI 腔会被降权/忽略。逐条过：

• 句式人化：消灭"首先/其次/综上所述/值得注意的是"类连接词；长短句混排，允许口语化短句（"这里直接就断了""这步没拦"）
• 结构去模板：不机械分"漏洞描述/漏洞危害/复现步骤"八股标题堆砌；按这个洞的叙事顺序走（怎么发现的→怎么验证的→打到什么）
• 删掉正确的废话：危害段不写"攻击者可能利用该漏洞造成严重影响"类空话，只写实际打出来的东西
• 保留人味细节：复现里带上真实判断痕迹（"一开始以为是 X，测了 Y 排除"），这种否定实验过程 AI 腔写不出来，也是审核信任点
• 术语不翻译腔：直接用 Burp/越权/getshell 等行话，不写"未经授权的访问漏洞（IDOR）"类教科书腔
• 列表节制：满屏 bullet 是 AI 指纹；能一段话说清的不拆列表

第 3 步：语义化命名

文件名格式：资产 存在 漏洞类型 漏洞.docx

api.example.com 存在订单接口越权读取他人敏感信息漏洞.docx
console.example.com 存在文件上传绕过致存储型XSS漏洞_详细复现_2026-08-01.docx

阶段总结类可用：单位SRC测试工作存在阶段总结报告.docx

第 4 步：放对目录

报告统一放 reports/ 下按单位/类型分目录：

目标	目录
企业 SRC	reports/<单位>src/
EDU	reports/edu报告/（根目录，不放子目录）
0day / 通用产品	reports/0day/（走通用型模板；报告内需含测绘语法、独立 IP 数、统计来源和时间）
其他新单位	在 reports/ 下新建 <单位>src/

只有确认漏洞的最终 DOCX 进这里。JS/抓取归档/临时产物一律不进，任务结束即删。

第 5 步：更新 vs 驳回（两种截然不同的处理）

• 正常补强 / 扩大危害（未被驳回）→ 融合改写：把新证据整合进对应章节（描述/Step/危害/评级），必要时重排 Step、替换旧证据为更强证据，重新生成一版干净 DOCX。不要在底部堆"补充/追加/扩大说明"。
• 被审核驳回 / 需申诉（明确被打回）→ 底部追加：保留原报告上下文，在 DOCX 底部追加"驳回后补充说明/复核证据/申诉证据"（Heading 2 + 同样 Step 规格），不覆盖不另起；关键 PoC 保留在抓包工具的重放功能（Repeater 等）里便于复核。

第 6 步：收尾

• 只保留 DOCX；shots/ 截图目录随对应临时目录/中间产物一并删除（图片已内嵌 DOCX；Markdown 稿、转换中间文件也删）。
• 确认漏洞后写复盘记录（什么信号命中的、哪步卡过、下次怎么更快）。

---

硬约束速查

• 每一步配真实截图，绝不自己 PS/仿造渲染；来源只能是浏览器打开原始 URL / 抓包工具实际响应（后台截图，不抢前台）。PoC 数据包保留文本即可。
• 报告内证据不打码（提交稿要能被平台验证）；普通聊天里可摘要。
• 只写能证明非公开、他人数据、真实业务影响的证据；公开内容/默认样例/自己测试账号数据 ≠ 危害，不写进危害。
• 单纯密钥/token 泄露不单独成报，只作高危链证据。
• CORS/安全头/版本号/Cookie 标志位/Self-XSS 不成报。
• 报告最终产物只有 DOCX，不留 HTML/Markdown。