Video summary

Should I report this vulnerability? Will I get a bounty?

Main summary

Key takeaways

Technology

Technology / Security Focus

  • Bug bounty decision-making: Don’t rush to report just because you found something. Confirm it’s truly a real vulnerability, understand how it works, and ensure it meets bounty requirements (impact + scope).
  • Scope & ownership checks: Verify the target/asset is in-scope for the specific program. Out-of-scope issues usually won’t earn a bounty and can result in platform/client penalties.
  • Requirements & exploit conditions: Understand exactly what the attacker can do, what the victim must do (or whether the victim can be affected without interaction), and what permissions/accounts are required.
  • Impact-driven severity: Bounties generally increase with invasiveness and attacker leverage (e.g., account takeover > other issues). Escalate impact where possible.
  • Common misreports: Many “findings” are actually misunderstood expected behavior or incorrectly demonstrated.

Key Points, Examples, and Rules of Thumb

1) Confirm it’s actually a vulnerability (avoid false positives / misunderstandings)

Ask: “Is it impactful / a genuine security issue?”

  • Minor or debatable issues may cause long triage disputes with a low chance of reward.
  • IDs / session/cookie misunderstanding (IDOR example):
    • Copying a cookie from Account A into Account B and getting a 200 response is not an IDOR.
    • A true IDOR requires using Account A’s authenticated context on an endpoint intended for Account B’s identifiers, and it must affect Account B with A’s cookie/context.
    • Emphasis: understand how cookies work and how the IDOR condition differs from normal cookie behavior.

2) Understand “prerequisites” (what must happen for exploitation)

XSS prerequisite barrier

  • If it’s “reflected XSS” but only visible to the attacker (e.g., requires self-triggering / self XSS-like conditions), it may not be considered a real vulnerability due to significant user-action requirements.

SSRF prerequisite barrier

  • If the SSRF “ping back” or measurable effect isn’t controllable and doesn’t come from the intended target server (i.e., doesn’t meet the program’s meaningful exploitation criteria), it may be out of reportable scope.

3) Ensure it’s in scope / owned by the company

  • Out-of-scope expectations: If assets are out of scope or covered under another disclosure program (e.g., a recent acquisition), you should generally not expect a bounty.
  • Repeated out-of-scope reports can lead to penalties or removal from programs.

4) Account / organization setup requirements (don’t assume triage can reproduce easily)

  • The speaker shares a personal example where a report couldn’t be reproduced by triage due to misunderstanding/complexity in account and organization role setup.
  • Lesson: include clear reproduction details, including initial setup of users/organizations/permissions, since ambiguity can cause acceptance failure.

5) Severity / impact guidance (P1/P2/P3 logic)

  • Don’t report every bug: Low-impact findings can waste time due to triage arguments.
  • Anecdote from a pro (Alex Chapman): focus often lands on critical/high and doesn’t push everything below P2.
  • Severity escalation concept: Even if the initial bug is smaller, demonstrating an escalation path (especially toward account takeover) can increase severity.
  • Common P1 drivers: Account takeover.
    • Example: moving from XSS/CSRF scenarios to takeover by chaining actions that trigger reset-password flows in the right context.
  • Business logic matters: security teams care about what can actually be done to real accounts and permissions.

6) “Is it worth fixing?” (time-value triage)

  • If you’re debating whether something is P4 vs P5, it’s likely not worth investing more time.
  • Some fixes can take a long time (example: a vulnerability taking years to be marked resolved), so continual pushing may have low ROI.

7) Duplicate risk and scanner limitations

  • Automated scanning (e.g., Nuclei) can produce duplicates, especially without deeper recon.
  • Public programs and insufficient subdomain/recon depth can make findings less novel and more likely to be duplicates.

Practical “TL;DR” Checklist

  1. Is it a good bug to report? Is it impactful and genuine?
  2. Confirm exploitation works as a vulnerability, not as expected behavior:
    • XSS: payload should be usable by others, not just self-triggered.
    • IDOR: real cross-account data/ability impact.
  3. Confirm scope / ownership: ensure it’s an in-scope asset and aligns with the correct program boundaries.
  4. Understand requirements: attacker/victim prerequisites, including accounts and permissions. Demonstrate initial setup.
  5. Understand impact + escalation potential: try to push toward account takeover and business-critical outcomes.
  6. Is it worth your time to debate with triage? If it triggers long P4/P5 arguments, move on.

Product / Platform Content (Sponsor)

  • Bugcrowd is the sponsor:
    • References Bugcrowd’s University, monthly challenges, community, and “Level Up” education.
    • Frames Bugcrowd as a platform for earning money, learning methodology/tools, and building community.

Main Speakers / Sources

  • Main speaker: Alex Chapman is referenced as a full-time bug bounty hunter (used for advice/inspiration).
  • Primary source content: The video host (unnamed in the subtitles, but delivering personal tips and examples) + Alex Chapman (mentor/pro reference).

Original video