bugcrowd-reporting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

BUGCROWD REPORTING — Program-Specific Tactics

BUGCROWD 报告——项目专属策略

Companion to the generic
report-writing
skill. Use when working specifically on Bugcrowd submissions where VRT mapping, OOS-clause rebuttals, or per-program target selection matter.

This skill encodes patterns that apply specifically to Bugcrowd's submission flow. For the generic per-platform templates (HackerOne / Bugcrowd / Intigriti / Immunefi report bodies), use the

report-writing

skill. For the 7-Question Gate before deciding to report at all, use

triage-validation

report-writing
skill 的配套内容。专门用于处理 Bugcrowd 提交，因为其中涉及 VRT 映射、OOS 条款反驳或按项目选择 target。

本 skill 收录专门适用于 Bugcrowd 提交流程的模式。对于 HackerOne / Bugcrowd / Intigriti / Immunefi 等平台的通用报告正文模板，请使用

report-writing

skill。对于决定是否报告之前的 7-Question Gate，请使用

triage-validation

。

1. VRT Category Selection — Search & Fallback Strategy

1. VRT 类别选择——搜索与回退策略

Bugcrowd's submission form requires a single VRT (Vulnerability Rating Taxonomy) selection. The dropdown's default severity is bound to the chosen node — pick wrong and the form auto-suggests a lower priority (often P4) when the actual impact is P3 or P2.

Note: VRT default severities are not fixed constants. Bugcrowd revises the VRT schema across versions, and individual programs can remap defaults via their own priority configuration. The P-values shown in the examples below (e.g., "No Rate Limiting on Form → Login" defaulting to P4) are the typical baseline at time of writing — always read the severity the current form actually auto-suggests for this program rather than assuming the value here.

Bugcrowd 的提交表单要求选择一个 VRT（Vulnerability Rating Taxonomy）类别。下拉菜单的默认严重性与所选节点绑定——如果选择错误，当实际影响为 P3 或 P2 时，表单往往会自动建议较低的优先级（通常为 P4）。

注意：VRT 默认严重性并非固定常量。Bugcrowd 会跨版本修订 VRT schema，各项目也可以通过自己的 priority configuration 重新映射默认值。示例中显示的 P 值（例如“No Rate Limiting on Form → Login”默认对应 P4）只是撰写本文时的典型基线——始终应查看当前表单针对当前项目实际自动建议的严重性，而不要假设这里所列的数值。

1.1 Search hierarchy (try in order, pick the highest-severity match that still describes the bug)

1.1 搜索层级（按顺序尝试，选择仍能准确描述漏洞的最高严重性匹配项）

For any finding, search the VRT dropdown with these terms in this order:

The bug's primary class — e.g.,
```
IDOR
```
,
```
XSS
```
,
```
SSRF
```
,
```
auth bypass
```
,
```
2FA bypass
```

The data category exposed — e.g.,

PII

sensitive data exposure

disclosure of secrets

The control bypassed — e.g.,

broken access control

authentication bypass

The endpoint type — e.g.,

no rate limiting on form > login

no rate limiting on form > change password

The generic parent node — e.g.,

Server Security Misconfiguration > Other

Broken Access Control > Other

对于任何漏洞，请按以下顺序在 VRT 下拉菜单中搜索：

漏洞的主要类别——例如
```
IDOR
```
、
```
XSS
```
、
```
SSRF
```
、
```
auth bypass
```
、
```
2FA bypass
```

暴露的数据类别——例如

PII

、

sensitive data exposure

、

disclosure of secrets

被绕过的控制措施——例如

broken access control

、

authentication bypass

endpoint 类型——例如

no rate limiting on form > login

、

no rate limiting on form > change password

通用父节点——例如

Server Security Misconfiguration > Other

、

Broken Access Control > Other

1.2 Pick the highest-severity match that still accurately describes the bug

1.2 选择仍能准确描述漏洞的最高严重性匹配项

Never select a VRT that misrepresents the bug just to get a higher default severity. Triagers will reassign and may flag the misrepresentation. The discipline is: pick the most specific accurate VRT, then use §2 (Manual Severity Override) if the default is wrong.

绝不要仅为获得更高的默认严重性而选择歪曲漏洞性质的 VRT。Triager 会重新分配类别，并可能将这种错误归类标记为不当表述。应遵循以下原则：选择最具体且准确的 VRT；如果默认值有误，再使用 §2（手动覆盖严重性）。

1.3 Common mappings worth knowing

1.3 值得掌握的常见映射

Finding type	First-choice VRT	Fallback
ATO via missing 2FA on password change	Broken Authentication & Session Management → Second Factor Authentication (2FA/MFA) → Bypass	Broken Auth → Authentication Bypass → Other
Password oracle without rate limit	Broken Authentication & Session Management → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Form → Login
GraphQL introspection / APQ allowlist bypass	Server Security Misconfiguration → Other (justify in body)	Broken Access Control → Other
Username → real name PII enumeration	Sensitive Data Exposure → PII Leakage / Disclosure of Secrets → Non-Corporate User	Broken Access Control → Other
State desync on security-sensitive action	Application-Level DoS → Other (with state-desync framing)	Server Security Misconfiguration → Other
Email/SMS pumping on auth-flow endpoint	Server Security Misconfiguration → No Rate Limiting on Form → Email-Triggering / SMS-Triggering	Server Security Misconfiguration → No Rate Limiting on Action
Token brute-force (email-change OTP, password reset)	Broken Authentication → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Action

漏洞类型	首选 VRT	回退选项
通过密码更改时缺少 2FA 导致 ATO	Broken Authentication & Session Management → Second Factor Authentication (2FA/MFA) → Bypass	Broken Auth → Authentication Bypass → Other
无速率限制的密码 oracle	Broken Authentication & Session Management → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Form → Login
GraphQL introspection / APQ allowlist bypass	Server Security Misconfiguration → Other（在正文中说明理由）	Broken Access Control → Other
用户名 → 真实姓名 PII 枚举	Sensitive Data Exposure → PII Leakage / Disclosure of Secrets → Non-Corporate User	Broken Access Control → Other
安全敏感操作上的状态 desync	Application-Level DoS → Other（采用状态 desync 论证方式）	Server Security Misconfiguration → Other
auth-flow endpoint 上的 Email/SMS pumping	Server Security Misconfiguration → No Rate Limiting on Form → Email-Triggering / SMS-Triggering	Server Security Misconfiguration → No Rate Limiting on Action
Token brute-force（email-change OTP、password reset）	Broken Authentication → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Action

1.4 If no good VRT exists

1.4 如果没有合适的 VRT

Pick

Server Security Misconfiguration → Other

Broken Access Control → Other

and lead the description body with a "VRT mapping note" explaining why the chosen node is the closest available match and what the bug actually is.

选择

Server Security Misconfiguration → Other

或

Broken Access Control → Other

，并在描述正文开头加入“VRT mapping note”段落，说明为何所选节点是最接近的可用匹配项，以及该漏洞实际属于什么问题。

2. Manual Severity Override

2. 手动覆盖严重性

Bugcrowd's form lets you manually set Technical Severity separate from the VRT default. The form text itself states: "A severity rating suggested by the VRT is not guaranteed to be the severity rating applied to your submission."

Bugcrowd 表单允许在 VRT 默认值之外单独手动设置 Technical Severity。表单原文写道：“VRT 建议的严重性评级，不保证就是最终应用到你的提交上的严重性评级。”

2.1 When to override

2.1 何时覆盖

Override the VRT default when:

The chained outcome is a higher severity than the standalone bug class (chain → ATO)
The VRT category is approximate and its default doesn't reflect the actual impact class
The program's own Focus Areas explicitly list this outcome at a higher severity than VRT's default
The data class exposed is more sensitive than the VRT's example uses (e.g., real-name PII vs. handle enumeration)

出现以下情况时，应覆盖 VRT 默认值：

链式结果造成的严重性高于该漏洞类别单独存在时的严重性（chain → ATO）
VRT 类别只是一个近似匹配，其默认值没有反映实际影响类别
项目自己的 Focus Areas 明确将该结果列在高于 VRT 默认值的严重性等级中
暴露的数据类别比 VRT 示例中的数据更敏感（例如真实姓名 PII，而不只是 handle enumeration）

2.2 How to override (form mechanics)

2.2 覆盖方式（表单操作）

Select the VRT that most accurately describes the bug (per §1)
Note the auto-suggested severity (P4, P3, etc.)
In the Technical Severity field, manually pick the severity you're requesting
Add a Severity Request paragraph as the FIRST section of the description body (per §3)

选择最能准确描述漏洞的 VRT（参见 §1）
记下自动建议的严重性（P4、P3 等）
在 Technical Severity 字段中手动选择所请求的严重性
按照 §3，将 Severity Request 段落作为描述正文的第一部分

2.3 Don't over-claim

2.3 不要过度声称

P1 inflation is the fastest way to lose triager trust. Reserve P1 for ATO without interaction, RCE, mass PII exfiltration, fund theft, and similar Critical-bucket impacts. If the chain to P1 requires a separate stolen-cookie premise, file the standalone primitive at P3 and discuss the chain explicitly with cross-references (per §4).

夸大为 P1 是迅速失去 triager 信任的最快方式。仅应对无需交互即可完成的 ATO、RCE、大规模 PII 外泄、资金盗取等 Critical 级别影响使用 P1。如果要达到 P1 必须额外依赖被盗 cookie 这一前提，应将独立的基础漏洞按 P3 提交，并通过交叉引用明确讨论完整链条（参见 §4）。

3. Severity-Request Paragraph — Always First in the Body

3. 严重性请求段落——始终放在正文首位

When the VRT default underrates impact, the FIRST section of the description body should be a severity-request paragraph. This is the first thing the triager reads and it pre-empts the auto-close that often happens when triagers see "P4" in the form.

当 VRT 默认值低估了实际影响时，描述正文的第一部分应当是严重性请求段落。这是 triager 首先阅读的内容，可以避免 triager 看到表单中的“P4”后直接自动关闭报告。

3.1 Template

3.1 模板

markdown

undefined

markdown

undefined

Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "[chosen VRT]," which Bugcrowd defaults to P[N] ($X-$Y in [program]'s rubric). I am requesting evaluation at P[M] [standalone | in chain with submission XXXX] for the following reasons:

[Impact axis 1] — [specific reason this finding exceeds the VRT default's example]
[Impact axis 2] — [specific reason, often citing the program's own Focus Areas]
[Impact axis 3] — [specific reason, often comparing to historical bounty payouts for the same data class]

[Optional: one paragraph contrasting the VRT default's typical example with this finding's actual impact, e.g., "P4 = No Rate Limiting on Login Form" applies to ordinary login pages where brute force is bounded by lockout policies; this endpoint has neither lockout nor throttle.]

undefined

[Impact axis 1] — [specific reason this finding exceeds the VRT default's example]
[Impact axis 2] — [specific reason, often citing the program's own Focus Areas]
[Impact axis 3] — [specific reason, often comparing to historical bounty payouts for the same data class]

undefined

3.2 Worked example pattern

3.2 实战示例模式

markdown

undefined

markdown

undefined

Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "No Rate Limiting on Form → Login," which Bugcrowd defaults to P4 ($XX–$YY in this program's rubric). I am requesting evaluation at P3 standalone, P2 in chain with submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX for the following reasons:

[Endpoint] is a password-disclosure oracle, not a generic rate-limit gap. The endpoint returns true/false for a supplied password — combined with cookie theft, it is the exact primitive an attacker uses to learn the victim's durable credential from a stolen transient session.
The chained outcome is "Account Takeover," explicitly listed under the program → Focus Areas → Critical (P1) examples. This finding is one of two independent links that make that chain work; the other is submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
The two findings have independent fix surfaces. Per the program's "one fix = one bounty" rule they should be evaluated as two separate findings whose chain raises the joint severity.

The "P4 = No Rate Limiting on Login Form" default applies to ordinary login pages where brute-force is bounded by lockout policies. This endpoint has neither lockout nor throttle, and the result of brute force is the user's actual password (not a session) — making the impact significantly higher than the default VRT severity assumes.

undefined

[Endpoint] is a password-disclosure oracle, not a generic rate-limit gap. The endpoint returns true/false for a supplied password — combined with cookie theft, it is the exact primitive an attacker uses to learn the victim's durable credential from a stolen transient session.
The chained outcome is "Account Takeover," explicitly listed under the program → Focus Areas → Critical (P1) examples. This finding is one of two independent links that make that chain work; the other is submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
The two findings have independent fix surfaces. Per the program's "one fix = one bounty" rule they should be evaluated as two separate findings whose chain raises the joint severity.

undefined

3.3 Tone guidelines

3.3 语气指南

Open with "Severity request — please review carefully before applying VRT default" (literal phrase). Triagers recognize this and don't auto-close.
Use bold sparingly; one or two phrases per reason at most.
Never use "could potentially" or "may allow" — these are downgrade-bait.
Cite the program's own Focus Areas / accepted-impact list by exact name.
Cross-reference linked submissions by full submission ID (UUID format).

以 “Severity request — please review carefully before applying VRT default”（原文逐字使用）开头。Triager 会识别这一表述，不会自动关闭。
谨慎使用加粗；每条理由最多只强调一两个短语。
绝不要使用“could potentially”或“may allow”——这些措辞很容易导致降级。
按确切名称引用项目自己的 Focus Areas / accepted-impact list。
使用完整 submission ID（UUID 格式）交叉引用关联提交。

4. OOS-Clause Rebuttals — Templates

4. OOS 条款反驳——模板

Bugcrowd triagers sometimes auto-close findings by mapping them to an OOS clause without reading the report. Pre-empt this by including an In-scope justification section that quotes the OOS clause and explains why your finding doesn't fit it.

Bugcrowd triager 有时会直接将漏洞映射到某条 OOS 条款并自动关闭，而不会认真阅读报告。为避免这种情况，请加入 In-scope justification 部分，引用对应 OOS 条款，并解释为何你的漏洞不适用该条款。

4.1 "Rate limiting on non-authentication endpoints" rebuttal

4.1 “非身份验证 endpoint 上的速率限制”反驳

When the finding is on an authentication endpoint (login, password change, password verify, OTP verify, token validate):

markdown

undefined

当漏洞位于身份验证 endpoint（login、password change、password verify、OTP verify、token validate）时：

markdown

undefined

In-scope justification

The program OOS list excludes "Rate limiting or brute-force issues on non-authentication endpoints."

[endpoint name]

is the canonical authentication endpoint — it accepts a password/token/OTP and returns whether it matches the user's stored credential. By definition this is an authentication primitive. The OOS clause's "non-authentication" qualifier therefore does NOT apply.

undefined

The program OOS list excludes "Rate limiting or brute-force issues on non-authentication endpoints."

[endpoint name]

undefined

4.2 "Debug information disclosure" rebuttal (for schema/introspection findings)

4.2 “Debug 信息泄露”反驳（适用于 schema/introspection 类漏洞）

When the finding involves schema disclosure that's actually a control bypass (e.g., GraphQL allowlist bypass exposing the mutation surface):

markdown

undefined

当漏洞涉及 schema 泄露，但实际属于控制措施绕过时（例如 GraphQL allowlist bypass 暴露 mutation surface）：

markdown

undefined

In-scope justification

This is not a "debug information" finding. The [persisted-query allowlist | introspection gate | etc.] is acting as an authorization control on the [GraphQL surface | API tree | etc.]. The bypass converts that gate into a no-op — multiple [mutations | endpoints] become reachable that the official clients cannot invoke. The schema disclosure is incidental; the impact is mutation-surface unlock, not information leakage.

undefined

undefined

4.3 "User enumeration with low-risk information" rebuttal

4.3 “涉及低风险信息的用户枚举”反驳

When the finding leaks more than just "this handle/email exists":

markdown

undefined

当漏洞泄露的内容不只是“这个 handle/email 是否存在”时：

markdown

undefined

In-scope justification

The program OOS list excludes "User Enumeration issues with low-risk and insignificant information being enumerated." The data leaked here is neither low-risk nor insignificant: it includes the matched user's [full real first name, last name, profile photo / SSN last 4 / phone number / etc.]. Real-[name | identity | etc.] knowledge is the same data class that gates the program's own [account-recovery flows / fraud-investigation interviews / support-call verification], which means this lookup directly defeats one of the program's own anti-fraud controls. This is PII disclosure, not handle enumeration.

undefined

undefined

4.4 "Theoretical issues / not exploitable" rebuttal

4.4 “理论漏洞／无法利用”反驳

When the finding's exploitability has been demonstrated end-to-end:

markdown

undefined

当漏洞的可利用性已经通过端到端方式得到证明时：

markdown

undefined

In-scope justification

This finding is exploitable end-to-end as demonstrated in the PoC: [one-sentence summary of the proven exploitation path]. The PoC includes [N HTTP requests with redacted cookies | N screenshots | a sanitized HAR file | etc.] showing the attacker's session [reading victim data | changing victim credentials | etc.]. The OOS clause for "theoretical issues that are not exploitable, or can not be demonstrated as exploitable" does not apply.

undefined

undefined

4.5 If you don't have end-to-end proof

4.5 如果没有端到端证明

If you only have an "API behavior" observation without a fully demonstrated exploitation path, the finding is theoretical. Don't file it. Capture the missing evidence (delivery confirmation, token-format inspection, cross-account victim data in response, etc.) and re-evaluate. Filing theoretical findings damages researcher reputation on the platform.

如果你只观察到“API 行为”，但没有完整展示利用路径，那么该漏洞就是理论漏洞。不要提交。先补充缺失的证据，例如投递确认、token 格式检查、响应中的跨账户受害者数据等，然后重新评估。提交理论漏洞会损害你在平台上的研究者声誉。

5. Chained Findings — Cross-Reference Strategy

5. 链式漏洞——交叉引用策略

Many high-impact findings are chains of two or more standalone primitives (oracle + missing step-up = ATO). Bugcrowd's program rule: "Submit one vulnerability per report. If multiple vulnerabilities must be chained to demonstrate impact, you may include them together, but please clearly explain the chain."

许多高影响漏洞都是两个或更多独立基础漏洞组成的链条，例如 oracle + 缺少 step-up = ATO。Bugcrowd 的项目规则如下：“每份报告提交一个漏洞。如果必须串联多个漏洞才能展示影响，可以一并提交，但请清楚解释该链条。”

5.1 Filing strategy for chains

5.1 链式漏洞的提交策略

Identify the highest-severity chained outcome (typically the one that maps to a P1/P2 example in the program's Focus Areas).
File the chain primitives FIRST as separate reports — each at its standalone severity (typically P3/P4). A submission's UUID only exists after it is filed, so the primitives must exist before anything can reference them. Leave the cross-reference line in each primitive's body as a placeholder for now.
File the chain consumer — the report whose body describes the full ATO/RCE/etc. impact at the chained severity (e.g., P1). Because the primitives already exist, fill in their real UUIDs in the consumer's "Chain partners" block (per §5.2).
Edit each primitive after filing the consumer to backfill the consumer's UUID: "Chain partner: submission [UUID] for the full impact narrative." (The reference is bidirectional, so one report must be edited after the other is filed — Bugcrowd allows post-submission edits to the description body.)

确定链式结果中的最高严重性——通常对应项目 Focus Areas 中的 P1/P2 示例。
首先将链条基础漏洞（primitive）作为独立报告提交——各自采用其独立严重性（通常为 P3/P4）。报告 UUID 只有在提交后才会生成，因此必须先创建这些基础漏洞，才能引用它们。此时在每份基础漏洞正文中保留交叉引用行作为占位符。
提交链条消费方（chain consumer）——即正文描述完整 ATO/RCE 等影响并采用链式严重性（例如 P1）的报告。由于基础漏洞已经存在，可以在消费方报告的“Chain partners”部分填入它们的真实 UUID（参见 §5.2）。
提交消费方报告后，编辑每份基础漏洞并回填消费方 UUID：“Chain partner: submission [UUID] for the full impact narrative.” 由于引用必须是双向的，因此一份报告需要在另一份提交后进行编辑——Bugcrowd 允许在提交后编辑描述正文。

5.2 Cross-reference template

5.2 交叉引用模板

In the chain consumer's body, near the top:

markdown

undefined

在链条消费方报告正文靠近顶部的位置：

markdown

undefined

Chain partners (filed as separate reports)

submission [UUID-1] — [primitive 1: e.g.,
```
me.verify_password
```
no rate limit]
submission [UUID-2] — [primitive 2: e.g., GraphQL APQ allowlist bypass]

These primitives have independent fix surfaces and are filed separately per the program's "one fix = one bounty" rule. The chained impact described here requires both primitives to be exploited end-to-end.


In each primitive's body:

```markdown

submission [UUID-1] — [primitive 1: e.g.,
```
me.verify_password
```
no rate limit]
submission [UUID-2] — [primitive 2: e.g., GraphQL APQ allowlist bypass]


在每份基础漏洞正文中：

```markdown

Chain context

This finding is the [N]th of [M] independent primitives that together produce [impact, e.g., "permanent account takeover from a stolen session cookie"]. The full chain narrative and the chained severity (P1) are documented in submission [UUID]. This standalone report is at P3 reflecting the primitive's individual impact.

undefined

undefined

5.3 What NOT to do

5.3 不应采用的做法

Don't paste the entire chain narrative into every primitive's body. Cross-reference instead.
Don't claim each primitive is independently P1 — overclaiming damages credibility for all linked reports.
Don't ask for a single combined bounty for the chain. The program's "one fix = one bounty" rule means each independent fix surface is a separate bounty. Frame the chain as a severity-amplifier, not a merge request.

不要将完整的链条叙述粘贴到每份基础漏洞的正文中。应使用交叉引用。
不要声称每个基础漏洞都独立构成 P1——过度声称会损害所有关联报告的可信度。
不要请求为整个链条支付单一份合并赏金。项目的“one fix = one bounty”规则意味着每个独立修复面都对应一份独立赏金。应将链条描述为严重性放大因素，而不是合并请求。

6. Target Selection — QA vs. Production

6. 目标选择——QA 与 Production

Programs that scope both production and QA assets (e.g.,

app.target.com

vs.

app-qa.target.com

) require careful target selection.

如果项目同时将 production 和 QA 资产纳入范围（例如

app.target.com

与

app-qa.target.com

），则需要谨慎选择目标。

6.1 Picking the right target dropdown entry

6.1 选择正确的目标下拉项

If you tested...	Pick this target	Why
Production app/API	The production target	Most accurate; signals the impact landed on real users
QA app/API (per program rules for non-US researchers)	The QA target (e.g., `Sign In - (QA)` , `Enrollment - (QA)` )	Accurate per program rules; signals friendly tester
QA but no specific QA target exists	Closest matching production target with a clear QA disclaimer in the body	Triager will reassign correctly if needed
Cross-asset finding (multiple targets affected)	The asset where the bug originates / has the highest impact	Add list of other affected targets in the body

测试对象	应选择的目标	原因
Production app/API	Production target	最准确，能够表明影响已波及真实用户
QA app/API（依据项目对非美国研究者的规则）	QA target（例如 `Sign In - (QA)` 、 `Enrollment - (QA)` ）	符合项目规则，并表明你是友好测试者
QA 中没有对应的特定 QA target	最接近的 production target，并在正文中清楚添加 QA 免责声明	如果选择不当，triager 会重新分配
涉及多个资产的漏洞	漏洞起源所在或影响最高的资产	在正文中列出其他受影响的 target

6.2 QA-disclaimer paragraph (when filing a QA-tested finding)

6.2 QA 免责声明段落（提交基于 QA 测试的漏洞时）

markdown

undefined

markdown

undefined

Notes for triagers

Tested in the QA environment ([qa-host]) per the program's instruction for non-US researchers / per the program's QA-testing scope.
Production may enforce additional controls that QA does not — please confirm whether the same resolver code path runs on production.
All testing limited to my own QA test account; no other accounts were interacted with.
Selected target:
```
[chosen-target]
```
. Selected VRT:
```
[chosen-VRT]
```
. Both selected as closest available matches; please reassign if more appropriate options exist.

---

Tested in the QA environment ([qa-host]) per the program's instruction for non-US researchers / per the program's QA-testing scope.
Production may enforce additional controls that QA does not — please confirm whether the same resolver code path runs on production.
All testing limited to my own QA test account; no other accounts were interacted with.
Selected target:
```
[chosen-target]
```
. Selected VRT:
```
[chosen-VRT]
```
. Both selected as closest available matches; please reassign if more appropriate options exist.

---

7. Researcher-Side Hygiene (Bugcrowd-specific)

7. 研究者侧操作规范（Bugcrowd 专属）

These are program-rule items that affect submission quality even though they're not part of the report body itself.

以下项目规则虽然不属于报告正文，但会影响提交质量。

7.1 Account email — Bugcrowdninja alias

7.1 账户邮箱——Bugcrowdninja 别名

Most Bugcrowd-managed programs ask researchers to use their

@bugcrowdninja.com

alias as the account email on the target. This flags traffic as friendly-tester to the target's fraud team. Steps:

Sign up for the target using your Bugcrowd alias (looks like
```
username@bugcrowdninja.com
```
)
If you already have an account, update the email to the alias before testing
If the program offers a contact path for multi-account testing, use that to coordinate additional aliased accounts (
```
alias+test1@bugcrowdninja.com
```
, etc.)
Document the alias in the report's "Notes for triagers" section so the triager can correlate test traffic in their logs

大多数由 Bugcrowd 管理的项目都要求研究者将 target 账户邮箱设置为

@bugcrowdninja.com

别名。这会向目标的反欺诈团队标记流量属于友好测试者。步骤如下：

使用你的 Bugcrowd 别名注册 target，形式类似
```
username@bugcrowdninja.com
```
如果已经拥有账户，请在测试前将邮箱更新为该别名
如果项目提供了用于多账户测试的联系渠道，请通过该渠道协调其他带别名的账户，例如
```
alias+test1@bugcrowdninja.com
```
在报告的“Notes for triagers”部分记录该别名，以便 triager 在日志中关联测试流量

7.2 Account-state restoration after PoC

7.2 PoC 后恢复账户状态

After demonstrating any state-changing action (password change, email change, device removal, money transfer):

Restore the account to its pre-PoC state immediately (e.g., revert the password to what it was)
Document the restoration in the report — "Account state was restored immediately after the PoC."
If restoration is impossible (e.g., a sent email cannot be unsent), document the residual state honestly

演示任何会改变状态的操作后，例如更改密码、更改邮箱、移除设备或转账：

立即将账户恢复到 PoC 前的状态，例如恢复原密码
在报告中记录恢复情况——“PoC 后已立即恢复账户状态。”
如果无法恢复，例如已发送的邮件无法撤回，应如实记录剩余状态

7.3 Cookie / session rotation after submission

7.3 提交后轮换 Cookie / Session

After submitting any report that includes session-cookie-derived evidence:

Log out and log back in to rotate the session cookie
Any cookie value visible in screenshots / HARs you submitted is now dead
Optionally, rotate the test-account password to a fresh value not used elsewhere — that way passwords visible in PoC screenshots are also dead

提交任何包含 session cookie 衍生证据的报告后：

退出登录后重新登录，以轮换 session cookie
截图中或 HAR 文件中显示的 cookie 值现已失效
可选地，将测试账户密码轮换为未在其他位置使用的新值——这样 PoC 截图中可见的密码也会失效

7.4 If the test account gets locked

7.4 如果测试账户被锁定

Don't create a second account to bypass the lock — that looks like fraud
Email the program-specific contact (if provided) with your Bugcrowd username and the report ID
Wait for the program team to unblock you; testing during the lock period damages credibility

不要创建第二个账户来绕过锁定——这种行为看起来像欺诈
使用项目提供的专用联系方式（如果有），并提供你的 Bugcrowd 用户名和报告 ID
等待项目团队解除锁定；在锁定期间继续测试会损害信誉

8. Submission-Order Strategy for Multi-Finding Engagements

8. 多漏洞项目的提交顺序策略

When you have multiple findings from a single engagement, the order matters.

当一次 engagement 中存在多个漏洞时，提交顺序非常重要。

8.1 Recommended order

8.1 推荐顺序

Chain primitives before their consumer. A consumer references the primitives' report UUIDs, which only exist once the primitives are filed (see §5.1). File the best-evidenced primitive first to lock your timestamp, then the rest of the chain's primitives.
The chain consumer next — fill in the real primitive UUIDs, then edit each primitive to backfill the consumer's UUID (Bugcrowd allows post-submission body edits).
Standalone P3 findings next. Order by quality of evidence: best-evidenced first, riskier (OOS-adjacent) findings later.
OOS-risky findings last. By the time these land, you've established a credible track record on this engagement.

先提交链条基础漏洞，再提交链条消费方。 消费方需要引用基础漏洞的报告 UUID，而这些 UUID 只有在基础漏洞提交后才会生成。先提交证据最充分的基础漏洞以锁定时间戳，然后再提交链条中的其他基础漏洞。
接下来提交链条消费方。 填入真实的基础漏洞 UUID，然后编辑每份基础漏洞并回填消费方 UUID（Bugcrowd 允许提交后编辑正文）。
然后提交独立的 P3 漏洞。 按证据质量排序：先提交证据最充分的漏洞，再提交风险较高或接近 OOS 边界的漏洞。
最后提交 OOS 风险较高的漏洞。 到这时，你已经在本次 engagement 中建立了可信记录。

8.2 Tracking submission IDs

8.2 跟踪报告 ID

Maintain a simple text file with each submission's UUID, severity, and one-line description. You'll reference these IDs across reports and during any subsequent triager dialogue.

维护一个简单的文本文件，记录每个提交的 UUID、严重性及一句话说明。你会在不同报告以及后续与 triager 的沟通中引用这些 ID。

8.3 What to avoid

8.3 应避免的做法

Don't file all findings in a single batch within minutes. Triagers see this as low-effort spam.
Don't file an OOS-risky finding before a clean P3 from the same engagement. The clean one establishes credibility; the risky one benefits from being read in that context.
Don't disclose any findings publicly until the program explicitly says it's OK. Bugcrowd's confidentiality applies to both unresolved AND resolved issues.

不要在几分钟内一次性批量提交所有漏洞。Triager 会将其视为低质量刷量。
在同一次 engagement 中，不要先提交 OOS 风险较高的漏洞，再提交证据充分的 P3 漏洞。证据充分的漏洞可以建立可信度，而高风险漏洞会因此获得更有利的审查语境。
除非项目明确表示可以，否则不要公开披露任何漏洞。Bugcrowd 的保密规则同时适用于未解决和已解决的问题。

9. Pairing with Other Skills

9. 与其他 Skill 配套使用

For this question / task	Use this skill
"Should I report this finding at all?"	`triage-validation` (7-Question Gate)
"What's the report body template for Bugcrowd?"	`report-writing`
"What VRT do I pick?"	This skill ( `bugcrowd-reporting` ) §1
"How do I argue for higher severity?"	This skill §2-3
"How do I rebut an OOS objection?"	This skill §4
"How do I redact cookies / PII in screenshots?"	`evidence-hygiene`
"Where do I find the payload for this exploitation step?"	`security-arsenal`
"Where do I find recon probes for this asset class?"	`offensive-osint`

针对以下问题／任务	使用此 skill
“我是否应该报告这个漏洞？”	`triage-validation` （7-Question Gate）
“Bugcrowd 的报告正文模板是什么？”	`report-writing`
“我应该选择哪个 VRT？”	此 skill（ `bugcrowd-reporting` ）§1
“如何论证更高的严重性？”	此 skill §2-3
“如何反驳 OOS 异议？”	此 skill §4
“如何对截图中的 cookies / PII 进行脱敏？”	`evidence-hygiene`
“在哪里查找此利用步骤所需的 payload？”	`security-arsenal`
“在哪里查找此类资产的 recon probes？”	`offensive-osint`

Notes on usage

使用说明

This skill is small and focused. It does NOT duplicate content from

report-writing

(per-platform templates, CVSS scoring, downgrade counters, 60-second pre-submit checklist) — load both skills together when filing a Bugcrowd report. The two skills' content composes naturally because their boundaries are clean:

report-writing

is the body templates,

bugcrowd-reporting

is the program-specific tactics layered on top.

此 skill 短小且聚焦。它不会重复

report-writing

中的内容，例如各平台正文模板、CVSS 评分、降级反驳方式以及提交前 60 秒检查清单——提交 Bugcrowd 报告时应同时加载两个 skill。这两个 skill 的内容可以自然组合，因为它们的边界十分清晰：

report-writing

提供正文模板，

bugcrowd-reporting

则在此基础上叠加项目专属策略。