Loading
Hunt Forgot Password / Account Recovery Authentication Flaws — 5 distinct patterns: (1) username enumeration via different responses for valid vs invalid email, (2) reset token exposed directly in the
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add elementalsouls/Claude-BugHunter --skill hunt-forgot-password -a cursor -y
Hunt Forgot Password / Account Recovery Authentication Flaws — 5 distinct patterns: (1) username enumeration via different responses for valid vs invalid email, (2) reset token exposed directly in the API response body, (3) reset token not invalidated after use (replay), (4) password reset link works from a different IP/browser (no binding), (5) no rate limit on the reset request endpoint. These are the standalone recovery-flow broken-auth primitives — distinct from reset-email host-header poisoning (hunt-host-header) and the full ATO chain (hunt-ato owns password-reset as an ATO path; prove the primitive here, chain it there). Detection: trace the full forgot-password flow from request to token to use; check response diffs between valid/invalid emails; test token replay after consumption. Medium to High (enumeration=Medium, token-reuse=High, account-takeover=Critical when chained to known-email).
Hunt Forgot Password / Account Recovery Authentication Flaws — 5 distinct patterns: (1) username enumeration via different responses for valid vs invalid email, (2) reset token exposed directly in the API response body, (3) reset token not invalidated after use (replay), (4) password reset link works from a different IP/browser (no binding), (5) no rate limit on the reset request endpoint. These are the standalone recovery-flow broken-auth primitives — distinct from reset-email host-header poisoning (hunt-host-header) and the full ATO chain (hunt-ato owns password-reset as an ATO path; prove the primitive here, chain it there). Detection: trace the full forgot-password flow from request to token to use; check response diffs between valid/invalid emails; test token replay after consumption. Medium to High (enumeration=Medium, token-reuse=High, account-takeover=Critical when chained to known-email).
Start with username enumeration — it's the fastest win and gates the rest.
Pattern 1 — Username enumeration (response difference for valid vs invalid email):
[email protected]) — record the response body, status code, and length[email protected], [email protected], [email protected])Pattern 2 — Reset token exposed in the API response: Some APIs return the reset token directly in the response body (instead of only emailing it). POST to the forgot-password endpoint and look for a token, link, or code in the JSON/HTML response. If a token appears that lets you reset the password, that's an immediate account-takeover vector.
Pattern 3 — Reset token replay (reuse after use):
Pattern 4 — No rate limit on reset requests: Submit the forgot-password endpoint 10-20 times rapidly with the same email. If all succeed without a 429, lockout, or CAPTCHA → no rate limit (enumeration + token flooding is possible).
Content-type: Forgot-password endpoints are often JSON-based REST APIs. Use application/x-www-form-urlencoded only if the endpoint is a traditional HTML form (check the login page's HTML to determine form encoding).
Proof: Username enumeration = measurably different response (body/status/length). Token exposure = token in response body. Token replay = second successful use of a consumed token.
Different error messages for valid vs invalid accounts leaks the user list without authentication. Even timing differences (fast "no user found" vs slow "email queued") count.
High-value targets: admin accounts, employee email patterns, API keys derived from usernames.
A reset token derived from timestamp, username, or sequential IDs can be brute-forced:
base64(email + timestamp) — decodabletoken=1234, token=1235 — trivially enumerableMost apps generate a token, email it, and accept it from any browser. A truly bound token should only work from the same IP or require the original session cookie. If neither is enforced → link forwarding = account takeover.
Token leak via Referer / third-party resources. When the token rides in the reset-page URL (/reset?token=…) and that page loads any cross-origin resource (analytics, ads, fonts, a CDN image), the full URL — token included — leaks to that third party in the Referer header. Check the reset page's outbound requests: if the token appears in any cross-origin Referer, it's harvestable without the victim's inbox. Same leak via a <meta name=referrer> misconfig or an outbound link the victim clicks from the reset page. Disclosed token-leak→ATO class: https://hackerone.com/reports/173551.
Common best practice: reset tokens expire within ~15–60 minutes (no hard RFC mandates the exact value; OWASP recommends a short, single-use lifetime). If a token from 24 hours ago still works → persistence risk for phishing attacks.
An uncapped reset endpoint enables:
hunt-ato — owns the account-takeover CHAIN (password-reset is its path #1). This skill finds/proves the recovery-flow primitive; hand off to hunt-ato to assemble the full takeover.hunt-cache-poison — host-header injection during reset email generation (different vulnerability, same flow)hunt-brute-force — rate-limit testing pattern applies to the reset endpoint toohunt-auth-bypass — if the reset flow can be skipped entirely (go to /reset-password?token= with empty/null token)hunt-mfa-bypass — if MFA is required after reset, test the bypass there