Gotchas

Vulnerability-Class Gotchas

For each class: minimum proof (what the PoC must show), common N/A (typical false positives that get auto-closed), overclaim traps (impact claims that need extra evidence).

Apply only the section matching the report's claimed class.

---

XSS

Minimum proof

• JS execution on target origin (alert(document.domain) proves it).
• Injection context stated: HTML body / attribute / JS / CSS / URL / JSON.
• Type stated: reflected / stored / DOM.

Common N/A

• alert(1) on null origin, sandboxed iframe, data: / blob: URL.
• Self-XSS.
• HTML injection without JS execution, unless tied to a real attack.
• XSS via a Markdown / template renderer the target doesn't actually use.
• javascript: href requiring the victim to manually paste the URL.

Overclaim traps

• "Session theft" claim but cookie is HttpOnly — JS can't read it.
• "Account takeover" without a PoC that actually takes over an account.
• "CSP bypass" without showing the CSP header and the bypass technique.

---

SQLi

Minimum proof (one of)

• Data extraction: sentinel value, table name, DB version returned.
• Time-based: controlled SLEEP(n) payload, multiple runs at varying n.
• Boolean-based: controlled true/false oracle with response differential.

Common N/A

• WAF blocked the payload → "SQLi confirmed". The WAF blocked; that's it.
• Error message mentioning SQL without controlled injection.
• Generic HTTP 500 on quote characters (could be many things).
• DB banner / version leaked without proving injection.

Overclaim traps

• "Full database compromise" without dumping a controlled sentinel row.
• Don't escalate the PoC into destructive or intrusive post-exploitation to "prove" impact. A confirmed injection (sentinel value, controlled time-delay, boolean oracle) is enough — stop there. Dumping the whole DB, chaining to xp_cmdshell / INTO OUTFILE, or writing files goes past proof into damage and can breach the program rules. Prove the primitive, describe the impact, don't exercise it.

---

SSRF

Minimum proof

• Inbound request observed on hunter-controlled endpoint (Burp Collaborator, webhook.site, hunter's server). Include the inbound log.
• For blind SSRF: time-based confirmation with multiple controlled hosts.
• Reach demonstrated: at least one of internal hostname, cloud metadata (169.254.169.254), localhost service, or protocol smuggling (file://, gopher://, dict://). Collab hit alone is not enough.
• Response data exfiltrated if claimed (internal endpoint content shown).

Common N/A

• DNS resolution only — proves lookup, not HTTP request.
• Blind SSRF to attacker-controlled domain only, no reach demonstrated. Legitimate webhooks / link previews / image proxies make outbound HTTP too.
• SSRF to public domains only.
• Request blocked by WAF / library / network policy.

Overclaim traps

• "Cloud metadata access" without showing the metadata response body.
• "Internal network scan" without one successful internal hit.
• "Blind SSRF" claimed High/Critical without demonstrated reach → typically Low or N/A.

---

IDOR / BOLA

Minimum proof

• Two hunter-controlled accounts, A and B.
• Account A reads / modifies / deletes a resource belonging to B.
• Response containing B's data shown, with B's identifier visible.

Common N/A

• Sequential / predictable IDs without showing actual access.
• Reading own data via someone else's ID (same effective access level).
• Resources that are public by design.
• Admin endpoints accessible only to admins (not broken).

Overclaim traps

• "Mass account takeover" without showing the takeover primitive on B.
• Single-account "discovery" with cross-tenant impact claims but no second tenant tested.
• Non-guessable identifier (random UUIDv4, HMAC, long opaque token) scored as if IDs were enumerable. If an attacker can't discover a victim's ID at scale, exploitation needs the ID to leak elsewhere — score AC:H and say where the ID would come from. Don't claim mass exploitation off a single self-owned resource whose ID you already knew. Sequential / short / predictable IDs are the ones that justify AC:L.

---

CSRF

Minimum proof

• Working PoC HTML page (hosted or pasted in full) that, when visited by an authenticated victim, performs the sensitive action.
• The action must be sensitive (state change, privilege grant, data modification — not logout, not search).
• SameSite cookie status verified — Lax blocks most cross-site POSTs; the PoC must work despite it.

Common N/A

• CSRF on logout, search, or other low-impact actions.
• "No CSRF token present" without showing exploitation.
• SameSite=Lax/Strict cookies blocking the cross-site request.

Overclaim traps

• "Account takeover via CSRF" without a chain that actually takes over.
• Rating a CSRF by the mechanism rather than the action. The severity is capped by what the forced action is worth. CSRF on a reversible, low-value state change (add item to cart, toggle a UI preference, change display name) is Low even with a perfect PoC. High severity needs a genuinely sensitive action: email/password change, fund transfer, privilege grant, deletion of the victim's data.

---

RCE

Minimum proof (one of)

• In-band command output (id, whoami, hostname).
• Out-of-band callback to hunter-controlled endpoint with a unique payload-specific marker.
• Injection point and payload shown literally.

Common N/A

• "Suspicious behavior on payload submission" without command execution.
• Stack trace mentioning system() / exec() without controlled execution.
• Theoretical RCE via a vulnerable dependency without proving reachability in the application's code path.

Overclaim traps

• "Full server compromise" without showing the privilege level. Prove execution with a harmless marker (id, whoami, hostname, or an OOB callback) and stop. Do not pivot, escalate privileges, move laterally, read other users' data, or run destructive commands to "demonstrate" reach — that's past proof and into damage, and it breaches most program rules. Report the execution primitive; describe the impact without exercising it.
• "RCE" that's actually code injection in a sandboxed context (sandboxed template engine, browser-side eval — that's XSS, not RCE).

---

SSTI

Minimum proof

• Template syntax confirmed ({{7*7}} → 49, <%=7*7%> → 49, etc.).
• Template engine identified (Jinja2, Twig, Velocity, Freemarker, ...).
• Sandbox escape shown if the engine is sandboxed.
• For RCE impact: see RCE section minimum proof.

Common N/A

• HTML / text reflection of {{7*7}} as a literal string (no evaluation).
• Math eval in a sandboxed expression engine without an escape path.

Server-side vs client-side

• {{7*7}} → 49 in a client-side framework (Angular, Vue) is CSTI, not server-side SSTI. Its impact is XSS (JS execution in the browser), not server RCE — report it as XSS and prove JS execution accordingly. Don't claim server compromise from a client-side template evaluation.

---

XXE

Minimum proof

• External entity defined and resolved.
• File read: content of a known file returned (e.g. /etc/passwd).
• Or OOB: callback with file content base64'd or named entity.

Common N/A

• XML parser accepts external DTD references but does not resolve entities.
• Error mentioning entity processing without a controlled file read.

Do not

• Demonstrate impact with an entity-expansion bomb (billion laughs / quadratic blowup). That's a DoS against the target — excluded by most programs and a rules violation, not an XXE proof. Prove XXE with a controlled file read or an OOB callback instead.

---

Open Redirect

Minimum proof

• Single URL that redirects to a hunter-controlled domain.
• The redirect mechanism sits on a security-relevant path: auth callback, OAuth redirect_uri, password reset link, login flow.
• A chain showing real impact (OAuth token theft, credential phishing leveraging the program's domain reputation).

Common N/A

• Open redirect on non-security-sensitive paths with no chain.
• Redirect requiring the victim to manually paste a URL.
• Same-origin redirects.

Overclaim traps

• Claiming token/code theft via an OAuth/OIDC redirect_uri you can't actually PoC. If proving the token leak requires an authenticated account (or the IDP's real consent flow) you don't have, the impact is theoretical and non-reproducible — a triager can't replay it, so it isn't valid. Either obtain an account and show the token landing on your endpoint, or report only the redirect you can prove (typically Low) and state plainly the ATO chain is unverified.

---

Auth Bypass

Minimum proof

• Specific endpoint or flow accessed without the required auth state.
• Endpoint is sensitive (admin, paid feature, other user's data).
• Bypass mechanism shown (request manipulation, missing header, modified parameter, parser confusion).

Common N/A

• Endpoint returns data also available unauthenticated by design.
• "Bypass" using test credentials the program intentionally exposes.
• Public endpoints documented as such in API docs.
• Reaching a protected route that only renders the client-side app shell. Loading /admin and seeing the SPA's JS/HTML render is not a bypass — the framework serves the bundle to everyone and the API calls behind it still return 401/403. You must show a protected action or data actually returned without auth (an admin API responding with real data, a privileged operation succeeding). "The page loads" is not an impact.

---