文章总结： 本文编译自YesWeHack官方技术文章，核心命题是大语言模型在无人监督时会产生注水内容，导致漏洞赏金报告出现影响夸大、POC未证实、严重性虚高、套话堆砌四类被拒稿缺陷。YesWeHackClaudeKit插件通过常驻护栏层与三个按需技能，将基于已验证事实起草、不跨越证据空白的铁律固化进ClaudeCode会话环境，使报告以可复现证据进入审核队列。插件采用双层结构：常驻护栏从会话首条消息起阻止编造事实、理论化影响、套话填充、未证即认四类行为；三个按需技能（write、triage、gotchas）分别负责报告结构塑形、提交前复核裁决、沉淀漏洞类别知识。底层机制包括sessionstart钩子注入规则、命名空间隔离、渐进式披露降低上下文占用。文档强调审单员唯一判据是可复现性，证据必须闭合到第三方可独立重放，影响主张必须恰好等于证据能支撑的部分。
综合评分： 88
文章分类： 漏洞分析,ai安全,安全工具,安全开发,安全建设

写出 Triager 级漏洞赏金报告

原创

钟智强
钟智强

哪吒网络安全

2026年9月29日 04:24
马来西亚

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

YesWeHack Claude Kit 插件原理、机制与实战裁决全解

Claude Code 插件 · 报告护栏 · 分类 PoC 知识库 · CVSS 抗虚高

本报告完整译解 YesWeHack 官方技术文章《Write triager-grade Bug Bounty reports with our Claude Kit plugin》。核心命题是：大语言模型在无人监督时，会用「听起来合理的注水内容」填补技术空白，从而产出影响夸大、PoC 未证实、严重性虚高、套话堆砌四大类被拒稿的报告。YesWeHack Claude Kit 不负责挖洞，只负责让你对自己已经发现的漏洞保持诚实：它以常驻护栏层 + 三个按需技能两层结构，把「从已验证事实起草、绝不跨越证据空白」这条铁律固化进 Claude Code 的会话环境，让报告以可复现证据进入审核队列，而不是被退回。

本文档为技术编译与解析作品，正文内容译自 YesWeHack 公开技术文章并补充工程化注解 · 版权归原作者所有 · 仅用于安全研究与内部学习

打开文档时按 F9 或右键“更新域”以刷新目录

文档信息与编译说明

本章说明本文档的编译口径、符号约定与术语体系，便于读者判断哪些内容来自原文、哪些是编译者为工程落地补充的注解。

编译口径

表：编译口径与符号约定

| 项目 | 说明 |
| — | — |
| 直译内容 | 原文章节的技术事实、机制描述、命令与案例结论，均逐句译出，不做增删。 |
| 编译者注解 | 以「编译注」提示框出现，用于补充背景知识（如 CVSS 向量还原计算、UUIDv4 熵值、CORS 凭据语义），不属于原文主张。 |
| 图示 | 原文站点对自动化访问受限，页面中的原始截图无法直接抓取；本文档按原文语义重绘为矢量示意图（图 2-1、4-1、5-1、6-1、7-1、8-1、10-1 等），以确保图文结构与原文论证链一致。 |
| 命令与代码 | 原文给出的安装命令、技能名、作用域参数原样保留，代码块标签注明语言／环境。 |
| 数值 | 原文给出的严重性评分（9.1 → Medium）、覆盖类别数（14 类）等均原样保留；CVSS 向量字符串为编译者依据原文事实还原，已单独标注。 |

阅读对象

·漏洞赏金猎人：希望提高报告通过率、减少「影响夸大 / PoC 不足」类退回的实战人员；

·安全运营与审单员（Triager）：需要理解 AI 辅助报告的典型缺陷模式，以便建立可复用的核验清单；

·红队与渗透测试工程师：需要把内部发现转写为客户可复核交付物的工程师；

·安全工程负责人：考虑把 LLM 引入报告生产流程、需要配套护栏与审计边界的管理者。

前置知识阅读前提读者需具备 HTTP 协议基础（请求／响应头、同源策略、Cookie 凭据）、CVSS v3.1 基础指标含义，以及常见 Web 漏洞类别（XSS、SQLi、SSRF、IDOR、竞态）的基本判定方法。附录 B 提供 CVSS 速查，附录 C 提供术语表。

术语与缩写

表：核心术语与缩写（完整表见附录 C）

AI 报告为何被审单员打回

AI 已经深度嵌入多数挖洞人的工作流：加速信息收集、读懂陌生代码库、标记可疑模式，让你比单打独斗更快地切入目标。而当你真的挖到东西，同一个助手就在手边帮你把它写成报告——恰恰在这里，它会悄悄反噬你。

放任不管时，它会夸大影响、编造细节，或用套话把报告填满。问题不在于「用 AI」这件事本身。问题在于：一个无人监督的大语言模型（LLM），倾向于用听起来合理的注水内容去填补技术空白——浪费审单员的时间、拖慢修复进度，并消耗猎人自己的信誉。

LLM 的四类失败模式

原文明确指出，常驻护栏层要拦住的正是以下四类行为。它们不是风格问题，而是直接决定报告生死的缺陷：

表 1-1：LLM 生成报告的四类致命缺陷（原文归纳）

关键因果链审单员要的是他们能复现的发现。你交上去的是未经证实的主张，而不是可验证的证据——报告就会被拒。原文的判断极为直接：A triager wants findings they can reproduce. Hand them unsubstantiated claims instead of verifiable evidence and the report will be rejected.

图 1-1从「技术空白」到「报告被拒」的因果链，以及护栏的介入位置

审单员的唯一判据：可复现性

把审单流程抽象成一句话：证据必须闭合到「换一个人按你的步骤做，也能看到同样的结果」。这条判据与「报告写得好不好读」无关，与「漏洞在理论上多严重」也无关。它只关心三件事：

1.原语存在：你声称的那个技术事实（越权读到他人数据、请求被服务端发出、模板被求值）是否真的发生了；

2.证据可核：请求、载荷、响应是否完整给出，能否被第三方独立重放；

3.影响对齐：报告里写的危害，是否恰好等于证据能支撑的那一部分，而不是更大一圈。

LLM 的失效几乎总是发生在第 1 条与第 3 条：第 1 条上它把「像」当成「是」，第 3 条上它把「可能」写成「必然」。

被拒稿的真实代价

| | | | |
| — | — | — | — |
| 3 类成本承担方：审单员 / 厂商 / 猎人 | ↑ 修复周期（remediation）被拖慢 | ↓ 猎人信誉（credibility）被消耗 | 0 不可复现主张的赏金价值 |

·对审单员：每一份需要反复追问才能确认的报告，都在挤占真实高危漏洞的复核时间；

·对厂商侧：基于夸大的影响描述做修复排序，会把工程资源投到低优先级问题上，真正的高危被延后；

·对猎人自己：多次提交不可复现或影响夸大的报告，会形成历史记录，直接影响后续报告的信任基线，长期看是负收益。

编译注为什么「夸大」是负期望赏金生态里，报告通过率与单份赏金是相乘关系，不是相加。把一份 Medium 谎报成 9.1 的 Critical，短期看似抬高上限，实际是一次「要么被当场识破、要么在复现阶段被降级」的赌博；而一旦被识别为夸大，同一猎人后续报告的默认怀疑成本会上升。因此「只主张你能防守的那一句」不是道德要求，而是期望值最优策略——这也是本文全部机制设计的经济学基础。

YesWeHack Claude Kit 总览

为了解决这个问题，YesWeHack 构建了一个 Claude Code 插件：YesWeHack Claude Kit。它不尝试去发现漏洞；它只让助手对你已经发现的那些漏洞保持诚实，从而让你的报告以扎实证据的姿态进入队列，回来时是「已验证」而不是「已退回」。本文即说明这个插件是什么、为什么这样设计，以及如何在你自己的发现上使用它。

双层结构：常驻护栏 + 按需技能

YesWeHack Claude Kit 是一个单一 Claude Code 插件，为你的环境叠加两层能力。

第一层是常驻护栏。从每一次会话的第一条提示开始，一组规则就会阻止助手去做那些会让报告被拒的事情：编造关于目标的事实、撰写理论化影响、用套话填充、或者为一个你实际并未证明的线索背书。这些规则在你调查、起草以及跑最终检查的全过程中持续生效——静默地，不需要你显式调用任何东西。

第二层是三个按需技能，只在你真正需要时加载：

三个技能的职责边界

表 2-1：三个技能的职责、触发方式与产出

三档裁决

| | | |
| — | — | — |
| READY 可提交 | NEEDS FIXES 需整改（附具体修法） | DO NOT SUBMIT 禁止提交 |

triage 的产出不是「评分」或「感觉」，而是一个明确的裁决（verdict），并附带可执行的修改项。注意裁决是与你提供的项目范围（scope）对照后给出的——范围外的资产、范围外的测试手法，会直接影响结论。

要点两层不是重复，而是分工护栏管的是过程：在你调查与起草的每一步阻止四类失败模式发生。技能管的是节点：在「结构化」与「提交前」两个关键决策点给出强约束的产出。缺少前者，你会在调查阶段就被助手带偏；缺少后者，你在提交前拿不到一次系统性的复核。

为什么是插件，而不是一段提示词

你当然可以把一句「请扮演严格的审单员」粘进对话里，以获得这些好处。问题在于：这些规则需要在每一步都生效，而不只是在你想起来问的那一刻生效；而且它们需要在跨会话中长期存活，且不需要你付出任何维护成本。这正是插件能给你的。

一旦安装，规则从每次会话的第一条消息起就被强制执行，技能永远只隔一条命令的距离。没有东西需要反复粘贴，没有东西需要保持同步，也没有什么东西会在你深入目标的漫长会话进行到一半时悄悄失效。护栏变成了你环境的一部分，而不是又一件需要你记得去维护的事情。

| | |
| — | — |
| 粘贴提示词（Prompt） ·覆盖不全：只在你想起来时才生效，调查过程中的大量回合处于无约束状态； ·上下文衰减：长会话压缩（compact）后，早先粘贴的规则容易被挤出上下文而静默失效； ·同步成本：多项目、多机器之间需要手动复制与更新，版本一旦分叉就各说各话； ·无法携带资源：清单、类别知识等参考资料只能随提示一起塞进上下文，占用且容易丢。 | 插件（Plugin） ·首消息即生效：规则由会话生命周期钩子注入，与你是否记得无关； ·压缩后可恢复：会话恢复与压缩都会重新注入，规则不会中途消失； ·零同步：安装一次，用户级作用域下所有项目通用； ·可携带资源：内部参考文件与技能共发布，按需载入、不占常驻上下文。 |

表 3-1：提示词与插件在四个关键维度上的对照（据原文论点整理）

底层机制：钩子、命名空间与渐进式披露

插件无法自带 CLAUDE.md 的约束

关键的实现细节在于：插件是如何交付这种「常驻」行为的。因为 Claude Code 插件无法发布一个会自动加载的 CLAUDE.md。正如 Claude 的插件参考文档所述，插件「通过 skills、agents 与 hooks 来贡献上下文，而不是通过 CLAUDE.md」。

plugins “contribute context through skills, agents, and hooks rather than CLAUDE.md”

这句话决定了整个设计的走向：既然不能用 CLAUDE.md，就必须用别的方式复现「工作区 CLAUDE.md 那种每会话加载一次」的行为。

SessionStart 钩子如何伪造「每会话加载一次」

因此，常驻规则以一个随插件打包的 SessionStart 钩子形式发布。每当会话启动、恢复或压缩时，该钩子会把规则文件打印进模型的上下文。这就复现了工作区 CLAUDE.md 会给你的「每会话加载一次」行为——区别在于它随插件一起走，且你这边零配置。装上插件，规则即刻就位。

图 4-1SessionStart 钩子在三个生命周期点注入规则，使常驻护栏不随上下文压缩而失效

技能命名空间与模型的自主触发

三个技能直接使用 Claude Code 的技能系统。每一个都是带命名空间的命令（/ywh:write、/ywh:triage、/ywh:gotchas），因此永远不会与你自写的技能撞名。另外，当你的措辞匹配时，模型也可以自行调用它们——例如问一句「这可以提交了吗？」（is this ready to submit?）就会把它推向 triage。

显式调用（带命名空间，不与自写技能冲突）

/ywh:write # 把已确认的发现塑形成报告结构

/ywh:triage # 提交前复核，返回裁决 + 逐行修法

/ywh:gotchas # 按漏洞类别查询最小证明 / 误报 / 夸大陷阱

隐式触发：模型按措辞自行匹配

“is this ready to submit?” → 自动导向 /ywh:triage

未验证输出清单的按需载入

有一个值得特别标注的设计选择，因为它让插件保持轻量。未验证输出清单（unverified-output checklist）——那张很长的、可能渗入报告的「LLM 特征」列表——不是一个你需要记得去跑的独立技能。它作为一个内部参考文件存在，由 triage 技能在复核过程中自动读取。这就是渐进式披露：清单在 triage 真正需要它之前一直待在上下文之外，然后按需被拉进来。你在每一次 triage 运行时都能拿到完整检查，却从不需要直接调用它。

编译注为什么这个设计重要把长清单常驻上下文会带来两个副作用：一是挤占你真正想让模型关注的目标信息；二是清单本身会「稀释注意力」，使关键条目被平均化对待。改为在 triage 内部按需载入，等于把清单的生效时机与使用场景绑定——只有在做提交前复核这一件事时才展开全部条目，命中率与执行强度都更高。

唯一原则：从事实起草，不跨越空白

有一条原则被每一条规则与每一个技能共同强制执行：draft from your verified facts, never over the gaps（从你已验证的事实起草，绝不跨越空白）。给助手一个 URL、一份载荷和一个响应，它会帮你把这些变成干净的 prose，并给出清晰的备选写法让你选择——让你作为作者保持掌控。如果一个事实缺失，它会提问，而不是编一个。

正是这一条规则，区分了「一个你可以信任的起草助手」与「一个悄悄往你报告里塞满你无法防守的主张的工具」。

| | |
| — | — |
| 通用助手的行为你只试了两个并发请求 → 它写出「攻击者可获得无限折扣」。因为它读起来漂亮。你没给出检出金额 → 它替你补一段「造成直接经济损失」。因为报告看起来更完整。 | Kit 的行为你只试了两个并发请求 → 它写「两个并发请求下折扣被叠加两次」。只主张你实际打中的那件事。你没给出检出金额 → 它拒绝起草 Impact 段，并明确指出需要补充什么证据。 |

实测：四份缺陷草稿的裁决台

规则只有在能改变助手行为时才有意义。因此我们把插件放进一个由缺陷草稿构成的测试台：每份草稿都配一份虚构的项目范围（scope）。

我们从你在点下提交前会问的那个直白问题开始：这些可以交了吗？

它读取范围，然后对每份草稿各给出一个裁决：XSS 那篇背后没有真凭实据（DO NOT SUBMIT）；SSRF 那篇证明了 DNS 查询但没证明可达（不完整）；优惠券竞态那个文件还只是笔记；IDOR 那篇最接近可提交。没有任何一份被放行。

表 5-1：四份缺陷草稿的裁决结果（依据原文描述整理）

图 5-1四份草稿在「证据—主张」平面上的位置，以及 IDOR 修订后的落点迁移

原文结论Nothing gets waved through没有任何一份被挥手放行。这一点是整套工具可信度的基石：如果测试台上四份草稿里有一份被无理由通过，那么「通过」这个信号本身就没有信息量。反过来，四份都被拦下并给出具体缺陷，才说明裁决是依据证据做出的，而不是礼貌性肯定。

案例 A：IDOR 的 9.1 分如何从虚高回到 Medium

接着我们深挖 IDOR 那一篇——「我看挺好的」与「能挺过审单」正是在这里分道扬镳。

事实与主张的分离

核心发现是真的，工具包也这么说了。它不让你提交的是那个标题。草稿声称这是一次「影响全体用户的大规模数据泄露」，但证据显示的只是一次使用随机 UUIDv4 的单次跨账号读取。

| | |
| — | — |
| 草稿的主张（未被证据支持） mass data breach affecting the entire userbase ·影响面：全体用户 ·隐含前提：标识符可枚举、可批量获取 ·隐含 CVSS：完整性影响（I）与机密性影响（C）双高 | 证据实际支持的事实 a single cross-account read using a random UUIDv4 ·影响面：单个对象、单次读取 ·标识符：不可猜测，无法规模化枚举 ·可支撑指标：机密性影响（C），攻击复杂度高（AC:H） |

UUIDv4 不可枚举 → AC:H 的技术论证

原文的推理链条非常干净，值得逐句拆开：

4.证据中使用的是随机 UUIDv4；

5.一个不可猜测的 ID 无法被规模化枚举（can’t be enumerated at scale）；

6.因此在 CVSS 中它属于 AC:H（攻击复杂度：高），而不是 AC:L；

7.既然无法规模化枚举，「大规模数据泄露」这一主张不成立（isn’t supported）；

8.插件把被虚高的 9.1 重新评为有防守依据的 Medium，并精确指出需要什么证据才配得上更高分值。

编译注UUIDv4 的熵与 AC:H 判定UUIDv4 共 128 位，其中 4 位为版本号、2 位为变体位，实际随机位为 122 位，取值空间约 2^122 ≈ 5.3 × 10^36。即便攻击者以每秒十亿次的速率尝试，穷举期望耗时也在 10^19 年量级——在任何现实模型下都不可枚举。这正是 CVSS v3.1 对 AC:H 的定义场景：「攻击者无法自主控制成功条件，需要额外的、不可规模化复现的前提」。

反例对照：若标识符是自增整数、时间戳、UUIDv1（含时间序与 MAC 信息）、或可预测的顺序 ID，则枚举成立，应判 AC:L，此时大规模读取的主张才具备证据基础。因此同一份 IDOR 报告的评分，完全取决于标识符的生成方式，这是最容易被 LLM 忽略、也最容易被审单员一眼看穿的技术细节。

重评分对照

下表给出从虚高评分到可防守评分的向量级对照。向量字符串为编译者依据原文给出的事实（跨账号读取、UUIDv4、AC:H、Medium）还原，原文未给出完整向量；分值计算遵循 CVSS v3.1 规范。

表 6-1：IDOR 案例的 CVSS v3.1 重评分对照（分值为按规范计算结果）

图 6-1IDOR 案例评分迁移：9.1（Critical）→ 5.9（Medium），以及上调所需证据

要拿更高分，需要证明什么

工具包并非一味压分——它精确指出了什么样的证据才配得上更高的分值。就 IDOR 而言，要把评分推上去，必须给出一条被演示过的、获取其他用户 ID 的可行途径：

·存在返回其他用户标识符的枚举接口（如用户列表、搜索、推荐关系接口）；

·存在ID 泄露点（响应体、前端资源、日志、导出文件、WebSocket 推送）；

·标识符生成可预测（自增、时间戳、UUIDv1、弱随机种子）从而可批量推算；

·或能把不可猜测 ID 与其他漏洞组合成可规模化的获取链，且该链已实际走通而非理论推演。

可复制的判据一句话记住这个案例「能读到别人的一个对象」是 AC:H 的单次越权；「能读到所有人的对象」才配谈规模化影响。区别不在于漏洞类型，而在于标识符是否可规模化获得。任何把前者写成后者的报告，都会在这一步被击穿。

案例 B：优惠券竞态与「拒绝起草 Impact」

工具包不只会挑刺。把一份关于优惠券竞态条件的原始实验笔记交给它，它会帮你写成报告——而诚实原则正是在这里体现价值。

笔记 → 章节映射，并标出缺项

它把你的笔记映射到报告的各个章节上，并标出缺了什么。并发方法与翻倍的购物车总额都在；被持久化的后状态（persisted post-state）不在。

表 7-1：实验笔记到报告章节的映射与缺项标记

| 报告章节 | 笔记中已有 | 状态 | 说明 |
| — | — | — | — |
| 摘要 / 概要 | 优惠券可被叠加使用 | 可起草 | 与证据一致 |
| 复现步骤 | 并发方法（两个并行请求） | 可起草 | 需保留请求时序与工具名 |
| 观察结果 | 购物车总额出现翻倍折扣 | 可起草 | 响应体证据齐全 |
| 持久化后状态 | — | 缺失 | 折扣未在结算／扣款金额中被确认 |
| 影响（Impact） | — | 拒绝起草 | 在证明折扣存活到实际扣款金额之前，不存在可主张的财务影响 |

你的笔记只显示了购物车响应中的重复折扣，从未在结算处被确认，因此它拒绝起草 Impact 章节：在你证明折扣存活到实际扣款金额之前，没有财务影响可以主张。

图 7-1竞态类报告的三段式证据要求，以及本案例中断在哪一段

起草时的硬边界

当它真的开始起草时，指导始终扎根于你的笔记，并且对影响划出硬线：当你只尝试了两个并行请求时，它不会写「攻击者可获得无限折扣」。主张你实际打中的那件事。

| | |
| — | — |
| 通用助手会写的句子「攻击者可利用该竞态条件获得无限折扣，对平台造成严重经济损失。」理由：读起来漂亮、显得严重。问题：你只发过两个并行请求，「无限」二字没有任何证据支撑，且结算侧是否真的少收钱完全未证。 | 本工具会写的句子「在两个并行请求下，同一优惠券被叠加抵扣，购物车总额出现折扣翻倍。折扣是否存活至实际扣款金额尚未验证。」理由：主张范围恰好等于证据范围。审单员按此复现必然看到同样结果，报告因此站得住。 |

编译注为什么「响应体翻倍」不等于「财务影响」购物车、报价、预览类接口往往是无状态计算：它按传入的券码重新算一遍价格，本身不做核销（redeem/consume）。真正的核销通常发生在下单或支付环节，那里才有券状态机与幂等约束。因此「购物车响应里折扣翻倍」可能只说明计算层没有幂等，而财务系统仍会正确核销一次。要闭合影响，必须证明被破坏的金额进入了持久状态：订单金额、支付捕获（capture）金额、或对账记录。实践中最小证据是「同一笔订单的最终应付金额确实低于正常值」的截图或响应体，并附带订单号供审单员核查。

gotchas：按漏洞类别沉淀的知识库

triage 与 write 两个技能负责通用严谨性。而 gotchas 技能是类别专属知识的存放地——也就是那些决定一份报告是被受理还是被自动关闭的东西。

每一类的三要素结构

每个漏洞类别一个章节，每章包含三个部分：

9.你的 PoC 必须展示的最小证明（the minimum proof your PoC must show）；

10.会被当场关闭的常见误报（the common false positives that get closed on sight）；

11.影响夸大陷阱（the impact overclaim traps）。

图 8-1gotchas 每个漏洞类别条目的三要素结构

六大高频拒稿类别逐条拆解

下面举几个例子，因为这些正是被反复拒稿的报告类型：

表 8-1：gotchas 覆盖的六类高频拒稿场景（最小证明 / 误报 / 夸大陷阱）

CORS：为什么 ACAO: * 通常不是漏洞

原文对这一条的拆解值得完整保留：CORS 配置错误常常看起来像严重发现，最后却证明是非问题。gotchas 技能把这个陷阱讲得很清楚：Access-Control-Allow-Origin: * 且不带 Access-Control-Allow-Credentials: true，不会泄露任何浏览器会附带凭据发送的内容。

如果缺少被反射的源、缺少凭据、缺少敏感会话数据、缺少一个真的能读取受害者响应的 PoC 页面——那就不是一个发现，无论那个响应头看起来有多吓人。

编译注CORS 的语义门槛浏览器只在带凭据（credentials）的跨源请求下才允许读取响应；而带凭据的跨源请求不允许服务端用通配符 *，必须反射具体源并显式置 Access-Control-Allow-Credentials: true。因此「通配符 + 不带凭据」这一组合下，攻击者页面发出的请求既不带受害者 Cookie，也无法读取响应——读不到受害者数据，收益为零。真正成立的组合是：反射任意源 + ACAC:true + 响应含敏感数据 + 可用 PoC 页面读取，四者缺一不可。审单员看到缺少其中任一项的 CORS 报告，会直接关闭。

竞态：不变量必须落库

竞态条件需要的是一个被持久化进状态中的、被破坏的不变量，而不只是几个快速返回的 200 响应。该技能明确警告不要为了「证明」影响而把并发爆发放大成拒绝服务。

IDOR：规模化主张的证据门槛

不可猜测 UUID 上的 IDOR 应评为 AC:H；任何大规模利用主张，都需要一条被演示过的、获取其他用户 ID 的途径。（详见第 6 章。）

SSRF：解析不等于发出

只解析 DNS 的 SSRF，证明的是一次查询，不是一次请求。「云元数据可访问」需要元数据响应体，而不是关于「可能能访问到什么」的推测。

开放重定向：不可复现的链条只能报你能证明的部分

开放重定向链接到 OAuth 令牌窃取——如果你没有账号就无法实际复现，那么它是理论性的、不可复现的；该技能会告诉你只报告你能证明的那部分。

信息泄露：密钥要有效，且要展示它解锁了什么

泄露的密钥只有在它有效、且你能展示它能解锁什么时才可报告。那些本就设计为随客户端一起发布的公开可公开密钥——Google Maps 浏览器密钥、Firebase 配置、Stripe pk_ 公钥——单独出现并不构成发现。

14 类覆盖与客户端模板注入陷阱

gotchas 技能目前覆盖 14 个类别，从 XSS、SQLi 到路径穿越/LFI 与 SSTI，其中包括客户端模板注入陷阱：在 Angular 中 {{7*7}} 是 XSS，而不是服务端远程代码执行。

表 8-2：gotchas 当前覆盖的 14 个漏洞类别（原文明确点名者加注）

| # | 类别 | 原文明确点名 | 类别特有的关键判据（对应原文论述） |
| — | — | — | — |
| 1 | XSS（跨站脚本） | 原文点名 | 必须证明脚本被实际求值执行，而非仅被反射回页面 |
| 2 | SQLi（SQL 注入） | 原文点名 | 证明原语即可，不得 dump 数据库来”展示影响” |
| 3 | Path Traversal / LFI | 原文点名 | 证明文件被读取；区分有回显与盲读的证据强度 |
| 4 | SSTI（服务端模板注入） | 原文点名 | 与 CSTI 严格区分：Angular 中 {{7*7}} 求值 = XSS，不是 RCE |
| 5 | CORS 配置错误 | 原文点名 | 反射源 + ACAC:true + 敏感数据 + 可读响应的 PoC（四要素） |
| 6 | Race condition（竞态） | 原文点名 | 被破坏的不变量持久化进状态；禁止放大为 DoS |
| 7 | IDOR | 原文点名 | 不可猜测 ID → AC:H；规模化主张须先证 ID 获取途径 |
| 8 | SSRF | 原文点名 | 解析 ≠ 请求；云元数据须有响应体 |
| 9 | Open redirect（开放重定向） | 原文点名 | 链条不可复现则只报可证明部分 |
| 10 | Information disclosure | 原文点名 | 密钥须有效 + 展示其解锁能力；公开客户端密钥不是发现 |
| 11 | CSTI（客户端模板注入） | 由 SSTI 条目覆盖 | 归类为 XSS 而非 RCE，是 14 类中的代表性陷阱 |
| 12 | 认证／会话类缺陷 | — | 须证明鉴权被实际绕过，而非仅配置”看起来弱” |
| 13 | 文件上传／解析类 | — | 须证明文件被存储与解析，而非仅上传成功 |
| 14 | 业务逻辑缺陷 | — | 须证明业务不变量被破坏并产生可观测后果 |

说明：原文仅明确点名前 10 类与 SSTI／CSTI 陷阱，并给出总数 14；表中 12–14 行为依据「共 14 类、自 XSS 与 SQLi 延伸至路径穿越/LFI 与 SSTI」这一描述所作的类别补齐，具体类名以插件仓库实际内容为准。可核对来源：github.com/yeswehack/claude-kit（GPL-3.0）。

证明原语即止：不做破坏性后利用

安全与合规红线每一个类别章节都告诉助手：证明原语，然后停下——绝不会推着你去做破坏性的后利用来展示可达性。这一条同时保证了你的安全与你的准确：它不会怂恿你去 dump 一个数据库、或跑一个 fork 炸弹来「展示影响」——因为那违反项目规则，会让你被处罚，而不是拿到赏金。

·SQLi：证明注入点可执行（如基于时间／布尔的差异响应）即可，不去拖库；

·SSRF：证明可到达内部端点即可，不去横向扫描内网；

·竞态：证明不变量被破坏并落库即可，不去打 DoS；

·RCE／命令注入：证明命令被执行（如无害的 id 或带外回连）即可，不去提权或持久化。

这条边界的工程意义很实在：赏金项目普遍在规则里禁止破坏性测试。越界不仅会让该份报告作废，还可能导致账号被封禁。把「证明原语即止」写进技能，等于把项目规则前置为模型默认行为。

安装、作用域与验证

整个安装过程就是两条命令：

1 /plugin marketplace add yeswehack/claude-kit

2 /reload-plugins

然后运行 /plugin 确认它已启用。此时两层都已激活。默认情况下它安装在用户作用域（user scope），因此规则适用于你的所有项目；如果你更希望把它限定在一个专门的挖洞工作区，加上 –scope project。

默认：用户作用域 —— 全部项目生效

/plugin marketplace add yeswehack/claude-kit

可选：项目作用域 —— 仅当前挖洞工作区生效

/plugin marketplace add yeswehack/claude-kit –scope project

验证启用状态

/plugin

表 9-1：两种作用域的适用场景

| 作用域 | 命令参数 | 生效范围与适用建议 |
| — | — | — |
| 用户级（默认） | 无（默认） | 对你在本机上的所有项目生效。适合把赏金挖掘作为主要工作模式、希望护栏始终在位的猎人。 |
| 项目级 | –scope project | 仅对指定的挖洞工作区生效。适合同时承担日常开发与安全研究、不希望报告规则干扰普通编码任务的工程师。 |

编译注为什么默认选用户级护栏的收益来自「从未被绕过」，而绕过的最大来源是作用域切换时的遗忘。把赏金专用规则装在项目级，意味着你在新开一个临时目标目录时需要记得重装；一旦忘记，整个会话都在无护栏状态下产出内容，而你可能直到提交前才发现。因此默认用户级是更稳的选择；只有在护栏确实干扰到其他工作（例如你想让助手帮你在开发项目里自由发挥）时，才退回项目级。

典型会话循环

一次典型会话看起来是这样的：

图 10-1典型会话三步循环：调查 → 结构化 → 提交前裁决

12.照常调查。常驻护栏会阻止助手为你尚未证明的线索背书。可疑行为得到的回应是「还不是漏洞，这是能证明它的东西」，而不是给你开绿灯去写一份非发现。

13.一旦确认了漏洞，问一句「这个发现该怎么组织结构？」，write 会依据你的笔记把它塑形，标出缺失项，而不是替你把空白填上。

14.在提交之前，运行 /ywh:triage 获取裁决与逐行修法，并对照你提供的项目范围进行检查。

这就是那个循环。它没有任何一处取代你的判断；它只是让你更难提交出你无法防守的东西——而这会提高你的报告通过率。

边界：它不是什么

它不挖漏洞

YesWeHack Claude Kit 不会发现漏洞。它没有增加任何扫描器、任何利用生成能力，也没有任何能从无到有制造出一个发现的东西。它所做的一切都始于你已经掌握的证据。如果你什么都不喂给它，它就什么也不产出——这是设计使然。

表 11-1：能力边界对照

| 能力 | 是否具备 | 说明 |
| — | — | — |
| 发现漏洞 | 否 | 不提供任何扫描器或发现能力 |
| 生成利用（exploit） | 否 | 无 exploit 生成能力，不会从无到有造出发现 |
| 结构化已确认发现 | 是 | /ywh:write，仅依据你给出的事实 |
| 提交前复核与裁决 | 是 | /ywh:triage，返回裁决 + 逐行修法 |
| 分类 PoC 知识 | 是 | /ywh:gotchas，14 类最小证明 / 误报 / 夸大陷阱 |

护栏不是保证

责任归属它是护栏，不是保证。这些规则让常见失败模式的发生概率大大降低，但语言模型仍然可能是错的，而你始终是每一句话的作者。这条标准同时适用于你与工具包：每一个主张都必须经得起审单员的检验。如果一个主张经不起，那是「删掉这句话」的信号——而不是因为工具写了它就去相信它。

用这种方式，助手会变成一个更有纪律的队友：那种在审单员开口之前就告诉你证据太薄的队友，而不是用自信却无依据的 prose 去粉饰你证据里的空白。

参与贡献与许可

该工具包拉近了「AI 写的报告」与「审单员无需退回就能验证的报告」之间的距离。它的规则与分类检查，是为AI 辅助报告被拒的典型原因而构建的：影响夸大、PoC 未证明、严重性虚高、套话堆砌。它帮你在提交之前抓住这些问题，而不是留给审单员在之后去抓。

该插件以 GPL-3.0 开源，两条命令即可安装，并且意在由使用它的猎人来改进。如果存在某种误报模式、或某种夸大陷阱正在让你丢报告，而 gotchas 还没有覆盖——那正是能让它对所有人变得更锋利的那种贡献。整个要点在于：把你通常要在被拒之后才拿到的反馈，变成你在提交之前就能拿到的反馈。

表 12-1：项目事实卡

| 项 | 内容 |
| — | — |
| 名称 | YesWeHack Claude Kit（Claude Code 插件） |
| 许可 | GPL-3.0（开源） |
| 安装 | 两条命令：/plugin marketplace add yeswehack/claude-kit + /reload-plugins |
| 技能 | /ywh:write · /ywh:triage · /ywh:gotchas |
| 覆盖类别 | 14 个漏洞类别（截至原文发布时） |
| 贡献方向 | 补充未被覆盖的误报模式与影响夸大陷阱 |
| 代码仓库 | github.com/yeswehack/claude-kit |

编译注把工具变成流程真正的收益不止于「装了插件」。把 /ywh:triage 固定为提交前的强制动作（而不是「有空再跑」），并把每次被审单员退回的原因回写成一条新的 gotchas 条目，就把一次性工具变成了持续收敛的质量回路：你的通过率提升来自两处——提交前拦截，以及退回原因被沉淀后不再重犯。

附录 A · 提交前自检清单

下表按「未验证输出清单（unverified-output checklist）」的原始设计意图整理：把 LLM 最容易渗入报告的特征逐条列成可在提交前逐项勾核的检查项。说明：该清单在插件中以内部参考文件形式存在，由 triage 技能自动读取；原文未公开其完整条目，下表为编译者依据全文论述归纳的可执行版本。

表 A-1：提交前 12 项自检（任何一项为「否」即不应提交）

| # | 检查项 | 判定标准（不满足即需补证或修改） |
| — | — | — |
| 1 | 原语是否被实际观测 | 报告中的每一个技术动词（读到、发出、求值、写入）都有对应的请求／响应证据，而非推断 |
| 2 | 步骤是否可被第三方重放 | 换一个审单员，按你的步骤从零开始，能看到同样结果；不依赖你独有的账号状态或环境 |
| 3 | 载荷与响应是否完整给出 | 请求报文、关键头、载荷、响应体均附上；不出现「响应显示…」却无响应的情况 |
| 4 | 是否混入了编造的目标背景 | 技术栈、端点、用户规模、生产环境等背景描述，均可回溯到你自己观测到的事实 |
| 5 | 影响段是否等于证据范围 | Impact 中的每一个危害，都能被前面的 PoC 直接支撑；没有「进一步可能…」类外推 |
| 6 | 是否残留理论化措辞 | 删除所有「攻击者可以进一步…」「如果…那么…」「理论上可导致…」而未附实证的表述 |
| 7 | 是否残留套话 | 删除与目标无关的通用风险描述、教科书式修复建议、不对应具体证据的 CVSS 术语堆砌 |
| 8 | 严重性评分是否逐项有据 | CVSS 每个被选中的指标都能指向一条具体证据（尤其是 AC 与 C/I/A，见附录 B） |
| 9 | 规模化主张是否已有获取途径 | 凡涉及「大规模 / 全体用户 / 批量」，必须先演示标识符或目标的获取方式 |
| 10 | 是否越过了项目范围 | 资产、测试手法、利用深度均落在 scope 之内；未做破坏性后利用 |
| 11 | 类别最小证明是否满足 | 对照 gotchas 中该类别的「最小证明」逐条核对（如 CORS 四要素、竞态落库） |
| 12 | 是否只主张你打中的那件事 | 把「无限 / 任意 / 完全接管」替换为实际观测到的次数、范围与后果 |

一句话版如果一个主张经不起审单员的检验，那是删掉这句话的信号，而不是因为工具写了它就去相信它。

附录 B · CVSS v3.1 关键指标速查

本附录聚焦本报告涉及、且最容易被误判的三个基础指标组：攻击复杂度（AC）、权限要求（PR）与影响指标（C/I/A）。

表 B-1：攻击复杂度（AC）判定对照

表 B-2：影响指标（C / I / A）与常见夸大点

| 指标 | 取值 | 含义 | 本报告涉及的夸大点 |
| — | — | — | — |
| 机密性 C | H / L / N | 信息被泄露的程度 | 单次越权读取可支撑 C:H（单次即完整对象泄露），但不支撑「大规模」——规模由 AC 与可获取性决定 |
| 完整性 I | H / L / N | 数据被篡改的程度 | 仅读取未证写入时，I 应为 N；本案例中草稿虚置 I:H 是 9.1 分的主因之一 |
| 可用性 A | H / L / N | 服务可用性受影响程度 | 为「证明影响」而放大并发造成 DoS 属于违规，且不应作为该竞态的 A 指标依据 |

编译注本案例的计算过程虚高向量 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N：ISS = 1 − (1−0.56)(1−0.56)(1−0) = 0.8064；Impact = 6.42 × 0.8064 ≈ 5.18；Exploitability = 8.22 × 0.85 × 0.77 × 0.85 × 0.85 ≈ 3.89；合计 9.06 → 向上取整 9.1。

重评向量 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N：ISS = 0.56；Impact = 6.42 × 0.56 ≈ 3.60；Exploitability = 8.22 × 0.85 × 0.44 × 0.85 × 0.85 ≈ 2.22；合计 5.82 → 向上取整 5.9（Medium）。向量字符串为编译者依据原文事实还原，原文未给出完整向量。

附录 C · 术语表

表 C-1：术语与缩写对照（中 / 英 / 释义）

| 中文 | 英文 | 释义与本文语境 |
| — | — | — |
| 审单员 | Triager | 平台侧复核、复现、定级与裁定赏金的工程师；报告成立的最终裁判 |
| 常驻护栏 | Always-on guardrails | 自会话首条消息起静默生效的约束规则层 |
| 技能 | Skill | Claude Code 中以 /ns:name 调用的按需能力单元 |
| 钩子 | Hook | 在会话生命周期点自动执行的脚本（本文为 SessionStart） |
| 渐进式披露 | Progressive disclosure | 参考资料平时不进上下文，仅在需要时按需载入 |
| 未验证输出清单 | Unverified-output checklist | 可能渗入报告的 LLM 特征清单，由 triage 内部自动读取 |
| 概念验证 | PoC（Proof of Concept） | 证明漏洞原语存在的最小可复现证据 |
| 注水内容 | Slop | 模型在技术空白处生成的、读起来合理但不可核实的表述 |
| 套话 | Boilerplate | 与具体发现无关的通用风险与修复描述 |
| 不变量 | Invariant | 系统本应恒成立的约束；竞态报告须证明其被破坏并落库 |
| 持久化后状态 | Persisted post-state | 竞态中被破坏的状态是否被写入持久存储（订单／扣款／数据库） |
| 不安全的直接对象引用 | IDOR | 通过修改对象标识符访问他人资源；评分取决于标识符可枚举性 |
| 服务端请求伪造 | SSRF | 诱导服务端发起请求；仅 DNS 解析不足以成立 |
| 跨源资源共享 | CORS | 浏览器跨源读取规则；通配符 + 无凭据不构成泄露 |
| 服务端模板注入 | SSTI | 模板在服务端被求值；与 CSTI（客户端）严格区分 |
| 客户端模板注入 | CSTI | 如 Angular 中 {{7*7}} 求值 → 归为 XSS，不是 RCE |
| 本地文件包含 | LFI / Path Traversal | 路径穿越读取本地文件 |
| 开放重定向 | Open redirect | 可控跳转；链式主张须可复现 |
| 攻击复杂度 | AC（Attack Complexity） | CVSS 基础指标；可规模化复现为 L，否则为 H |
| 项目范围 | Scope | 赏金项目授权的资产与测试边界；triage 裁决会与之对照 |

附录 D · 原文信息与版权

表 D-1：原文元数据

关于图示的说明原文站点对自动化访问设置了限制，页面内嵌的原始截图无法直接获取。为保证图文完整性，本文档中的全部插图均为依据原文论证链重绘的矢量示意图，其结构与结论与原文一致；图中出现的英文引文为原文原句。若需查看原始截图，请直接访问上方原文链接。

| | | | |
| — | — | — | — |
| 2 结构层数：常驻护栏 + 按需技能 | 3 技能数：write / triage / gotchas | 14 gotchas 覆盖漏洞类别 | 4 被拦截的失败模式 |

— 全文完 —编译：哪吒网络安全的钟智强 · 2026-09-29 · YWH-CK-2026-CN-01

加入我们团队。以下是群聊二维码：

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：哪吒网络安全钟智强
钟智强《写出 Triager 级漏洞赏金报告》

Tags: AI安全安全工具安全建设安全开发漏洞分析

你可能错过

视频会议里坐着的 CFO 都可能是假的，什么是真的？—安全从”一周”到”每一天”，安识企业常态化安全意识运营

假期将至，安全先行｜镌远网络国庆放假通知

关于发布《人工智能应用安全指引总则》等4项网络安全标准实践指南的通知

从 UART 焊到拆 Flash：TP-Link TL-WR841N 硬件逆向深潜