report-preflight

name	report-preflight
description	Pre-submission eligibility check for bug bounty findings. Catches ineligible patterns, AI/scanner false positives, and generates impact justification for borderline lows. Use before writing a report or when assessing whether a finding is worth reporting.

Report Preflight

Pre-submission eligibility gate. Run BEFORE committing to a report.

Usage

/report-preflight <target> <finding-type> <severity> <one-line description>

Or invoke with no args during active testing to check the current lead.

Process

Step 1: Map finding against three tiers

HARD INELIGIBLE — Platform core ineligible (see Tier 1). Do not report regardless of program.

SOFT INELIGIBLE — Common AI/scanner over-inflation (see Tier 2). Reportable ONLY with demonstrated impact beyond the pattern itself.

PROGRAM-SPECIFIC — Check target program policy for per-program exclusions. Do not conflate with universal ineligibility.

Step 2: Check against lists

Tier 1: Core Ineligible Findings

Universally ineligible across major bug bounty platforms. Do not report.

Source: HackerOne Core Ineligible Findings. Other platforms (Bugcrowd, YesWeHack, Intigriti) maintain similar lists — check the specific platform's policy.

Theoretical / unlikely user interaction:

• Vulns only affecting unsupported/EOL browsers or OS
• Broken link hijacking
• Tabnabbing
• Content spoofing / text injection (no security impact)
• Self-exploitation (self-XSS, self-DoS) unless cross-account
• Attacks requiring physical device access (unless in scope)

Theoretical / no real-world impact:

• Clickjacking on pages without sensitive actions
• CSRF on non-sensitive forms (logout, language change, etc.)
• Permissive CORS without demonstrated exploitation
• Software version disclosure / banner identification / descriptive error messages or headers
• CSV injection
• Open redirects without additional security impact (no OAuth chain, no token theft)

Missing hardening / best practices (not bugs):

• SSL/TLS configuration opinions
• Lack of SSL pinning
• Missing jailbreak detection in mobile apps
• Cookie flags (missing HttpOnly/Secure) without demonstrated exploitation
• CSP configuration opinions
• Email security features (SPF/DKIM/DMARC)
• Most rate limiting issues

Hazardous testing (never attempt):

• DoS/DDoS / availability attacks
• Social engineering / phishing
• Notification/form spamming
• Attacks on physical facilities

Tier 2: Common AI/Scanner Over-Inflated Patterns

NOT vulnerabilities without specific proof of impact. Reportable only with demonstrated exploitation.

Pattern	Not a bug because	IS a bug when
Source map exposure	Dev tooling artifact	Contains hardcoded secrets, API keys, or PII
REACT_APP_* env vars in webpack	Client-side config by design	Contains actual secrets (write-access API keys, not public client IDs)
Services returning 401/403	Auth working correctly	Bypass found, or response body leaks data despite status code
CORS misconfiguration	Informational without exploit	Demonstrates credential theft or data exfil cross-origin
Staging/dev endpoint exposure	May be intentional	Contains real user PII, valid creds, or unauth admin access
Blind SSRF (boolean oracle only)	No demonstrated data access	Demonstrates port scanning, internal service interaction, or metadata access
Username/email enumeration	Low impact, often by design	Enables account takeover chain or violates privacy regulations
Rotated/expired credentials in JS	No longer valid	Still valid and grant access
Public OpenAPI/Swagger schemas	Documentation, not a vuln	Contains validated API keys or reveals exploitable unauth endpoints
Exposed admin panels	Access != vulnerability	Unauth access to sensitive data or actions
GraphQL introspection enabled	Often intentional	Reveals hidden mutations with unauth access
Verbose stack traces	Informational	Leaks secrets, internal IPs, or exploitable version info
Public .git directory	Depends on contents	Contains secrets, credentials, or sensitive source
"Dummy" data on staging	Test data, not real	Contains real PII or valid production credentials
Open redirect	Informational alone	Chains with OAuth token theft, session fixation, or phishing
Missing rate limiting	Best practice	Enables brute force with demonstrated account compromise
Subdomain takeover candidate	Often false positive	Verified against can-i-take-over-xyz and actually claimable

Tier 3: Program-Specific Exclusions

Check the target's program policy for:

• Explicit out-of-scope vulnerability types
• Severity minimums (some programs only reward High/Critical)
• Specific endpoint or domain exclusions
• Testing restrictions

Step 3: Render verdict

ELIGIBLE — No ineligible pattern matched. Proceed to report.

NEEDS_JUSTIFICATION — Matches soft-ineligible but has demonstrated impact. Generate the justification block (Step 4).

INELIGIBLE — Matches hard-ineligible or lacks demonstrated impact. Do not report. Log as a gadget or lead if useful as a chain component.

Step 4: Generate justification block for NEEDS_JUSTIFICATION

For borderline findings (especially lows matching common ineligible patterns), include in the report:

Note for program review: This finding surfaces a pattern commonly associated with [ineligible category]. However, the demonstrated impact differs materially: [concrete evidence with specifics]. Full reproduction steps and network evidence are provided below for independent verification. We acknowledge this is a nuanced scenario and present it based on the demonstrated impact rather than the pattern classification alone.

Adapt to the specific finding. No filler, no inflation — if the impact is genuinely low, say so honestly. The goal is to prevent instant triage-as-informational by surfacing evidence that distinguishes this case from the generic pattern.

Step 5: Confidence check

After classification, use assess-confidence to evaluate the finding with the evidence gathered, exploitation demonstrated, and verdict from this preflight. If confidence is low, reconsider reporting. Document override reasoning if proceeding anyway.

Skill Pipeline

vuln-critic (evidence quality) → report-preflight (eligibility) → exploit-verifier (confirmation) → report_item (structured output)