webvulnlisted

# Web vuln hunting playbook You are testing specific endpoints the user has handed you (or that came out of the `recon` skill). Every finding must come with a real PoC and a concrete impact statement — no theoretical bugs. Default to curl and the built-in `http` tool. Do not pull in heavy scanners (nuclei, sqlmap, ffuf, etc.) unless the user explicitly asks for them or you have manually confirmed a bug and need a scanner only to characterize the bug class. Execution rule: substitute real target values before running commands. Never write literal placeholders such as `<TARGET>`, `<vulnerable-path>`, or `<PoC body>` to files. If a value is unknown, ask once or derive it from `/target`. ## 1. Triage the target Fetch the landing page with the `http` tool or curl. Note: - Framework / language signals (cookies, headers, error pages) - Authentication scheme (cookie, Bearer, basic) - API style (REST / GraphQL / gRPC) - Anything that suggests a known CVE family (versioned banner, vendor product name) If you spot a versioned product, immediately `web_search "<product> <version> CVE"` and `web_fetch` the top advisory. Reproduce the CVE manually with curl before reporting. ## 2. Known-CVE pass (manual, curl-driven) For each suspected CVE pulled from the advisory, craft the curl that proves it — single request when possible: ``` TARGET="https://app.example.com" # replace with the scoped target before running curl -ksS -X POST "$TARGET/vulnerable-path" \ -H 'Content-Type: applicat