Scope of "STOP" in this skill: This skill's gates kill INDIVIDUAL FINDINGS that fail validation. They do NOT authorize stopping the engagement. Killing a finding via the 7-Question Gate just means that finding doesn't get submitted — every other test class in the engagement is still pending. See

redteam-mindset

"DO NOT STOP primary directive" for the coverage-axis rule.

"N/A hurts your validity ratio. Informative is neutral. Only submit what passes all 7 questions."

• Critical: Any-user ATO without interaction, RCE, SQLi with data exfil, admin auth bypass
• High: Mass PII exfil, privilege escalation, internal SSRF with data, stored XSS all users
• Medium: IDOR on specific user non-critical data, XSS on sensitive page requiring click
• Low: Non-sensitive info disclosure, clickjacking with PoC

• Vulnerable domain is on the in-scope list (not

  *.internal.target.com

  )
• It's a production asset (not staging/dev unless explicitly in scope)
• It's not a third-party service the company just uses (not Stripe, Salesforce, Google Auth)

• "Admin can do X" = centralization risk = KILL IT (on 99% of programs)
• "Non-admin can do X that only admin should do" = valid
• "Requires physical access / MFA device" = usually invalid
• "Requires compromised victim account to work" = questionable, low severity at best

1. Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class
2. GitHub issues on target repo:

   is:issue label:security ENDPOINT_NAME

3. Changelog/CHANGELOG.md — does it mention this behavior?
4. API docs / design docs — is it documented as intended?

• XSS → show actual cookie theft or session hijack, not just

  alert(1)

  or

  alert(document.domain)

• SSRF → hit an internal endpoint that returns data, not just DNS ping
• SQLi → show actual data exfil from a real table, not just error message
• IDOR → show actual other-user's data in response, not just a 200 status code

"I sent an unauthenticated request and got back

400 — field X is required

. A validation error means the request cleared auth and reached business logic. Therefore auth is missing."

undefined

UI for stored XSS is a judgment call. Stored XSS that fires on page view is a long-standing CVSS gray area — NVD/FIRST frequently score it UI:R (which drops the stored-XSS row above to ~7.6). The UI:N above models "no extra action beyond normal page use"; if your triager expects UI:R, defend the choice or re-score before copying the number into a report.

1. 5-minute rule: If you can't fill in Q1's template in 5 minutes → move on
2. Precondition count: More than 2 preconditions simultaneously required → kill it
3. Impact test: "What does attacker walk away with?" — if nothing tangible → kill it
4. Admin bypass: "Admin can do X" is NEVER a bug → kill it immediately
5. Design doc test: If it's documented behavior → kill it immediately
6. Rabbit hole signal: 30+ min on Q6 with no reproducible PoC → kill it

1. Have I validated the FULL chain to attacker-attainable impact, or only one primitive in the middle? — "Primitive confirmed at layer N" ≠ exploitable. Multi-stage chains require ALL stages validated before the severity matches the chain's top end.
2. What does the attacker walk away with, in one concrete sentence? — "RCE on the SP front-end web server" is concrete. "Could lead to RCE" is not — that's High at best, often Medium.
3. Have I personally reproduced the full chain end-to-end at least twice? — Twice = once during discovery, once for the report screenshot/PoC. Not "I'm sure it would work."
4. Is there an inheritance gate, signature check, audience check, or other validation step still gating the chain? — If yes, the chain is not Critical. Document it as "primitive present" at lower severity until the gate is bypassed.
5. Has the program rejected this severity class before? — Many programs cap "info disclosure with no concrete impact" at Low/Info regardless of the data type. Read the program scope.

alg:none

• Original signal: <one-line description of what looked like a bug>
• Disproving evidence: <concrete reproduction-step + observation that disproves it>
• Why it looked like a bug: <root cause of the false positive — e.g., natural marker collision, network jitter, status-code-only confidence>
• Retraction date: <YYYY-MM-DD>

**Concrete retractions from an authorized engagement — pattern reference:**

- **X-Forwarded-Proto reflection** — looked like header reflection across 4 pages; was the literal word `javascript` in SP help-link hrefs. Cause: non-unique marker.
- **Host header `:80@evil` bypass** — 200 OK on a path that normally 403s; body byte-identical to baseline (8341 bytes). Cause: status-code-only confidence; ELB Host normalisation dropped the `@evil` portion.
- **`download.aspx` file-existence oracle** — looked like a file-existence differentiator across path types; was SP's file-extension blocklist (`.ashx`/`.asmx`/`.svc`/`.config` always blocked regardless of existence). Cause: confusing server-side policy with file state.
- **`Administrator` timing leak** — single-shot 1527 ms vs ~700 ms control on Authentication.asmx Login; n=80 interleaved reproduction collapsed every group to 685-716 ms. Cause: single-sample statistical claim.

**Why this matters:** retracted findings put in an appendix demonstrate methodological honesty. Silently dropping them looks like you cherry-picked. A clean 11-finding report with a retraction appendix is more trustworthy than a 13-finding report where 2 fall apart at triage.

---

• report-writing

  — When all 7 questions pass and the Pre-Severity Gate is clean. Workflow primitive: this skill is the gate that runs BEFORE

  report-writing

  ; only findings that clear all 7Q + 4 pre-submission gates get the report-template handoff.

• bugcrowd-reporting

  — When a Bugcrowd VRT mapping is needed for an accepted finding. Workflow primitive: after this skill validates the finding,

  bugcrowd-reporting

  decides the VRT category and severity-request paragraph.

• evidence-hygiene

  — When the validated finding needs PoC evidence captured. Workflow primitive: this skill says "Q6 requires proof of impact";

  evidence-hygiene

  provides the capture-and-redact protocol for that proof.

• security-arsenal

  — When checking the always-rejected / conditionally-valid tables. Workflow primitive: this skill's "Never Submit List" and

  security-arsenal

  's "Always Rejected" table are aligned; either entry-point lookup decides whether a primitive is reportable alone or only with a chain.

• bb-methodology

  — When Phase 5 (Validate & Report) starts. Workflow primitive: Phase 5's pre-report gate explicitly invokes

  /validate

  (this skill's 7Q gate) before any report is drafted.

Engagement-derived additions to the vendored foundation. Wisdom from real authorized engagements + Phase 2 verification across this repo's 31+ skill-area live tests. The upstream methodology covers the WHAT; this layer covers the WHEN-IT-ACTUALLY-WORKS and the FAILURE-MODES.

1. URL echo dressed as reflection — payload appears in the response body because the response IS the URL. Q1 (is this a real HTTP request that does something on the server) kills it.
2. Word collision dressed as marker hit — the canary string

   XSS-test

   matched a CSS class name, not your injection. Marker Discipline + Q1 kill it.
3. Server policy mistaken for state oracle —

   download.aspx?file=foo.config

   always returns "blocked" regardless of whether the file exists. Q6 (impact beyond technically possible) kills it: there's no oracle, just a deny-list.
4. 200 OK without leak — status code differs from baseline 403; body is byte-identical. Body-Diff Rule + Q6 kill it.

1. Triagers retract for you with downgraded scoring. A self-retraction reads "the researcher validates their own work." A triager-retraction reads "the researcher submitted noise."
2. Validation rate is platform-tracked. Self-retractions don't hit the same metric as triager-closed-as-N/A. Your reputation signal stays cleaner.