How a Researcher Found a Critical Password Reset Bug (and Earned $4,000)

Disclaimer:
This report is a knowledge-sharing educational rewrite of a real-world finding originally disclosed by another security researcher.
Its purpose is to educate developers and security professionals on how such API authentication flaws can emerge - and how to prevent them.
Always test only systems you are authorized to test.

🧩 Introduction: When One Endpoint Changed Everything

In bug bounty hunting, not every big reward comes from complex exploit chains.
Sometimes, it’s a single overlooked endpoint - one parameter - that flips an entire authentication model upside down.

This post analyzes how a researcher discovered a critical password reset vulnerability in a school-parent communication app, leading to a $4,000 bounty.

Through fuzzing, Burp Suite interception, and keen observation, they found a logic flaw that allowed complete account takeover - with nothing more than a target’s email address.

🔍 Step 1: Setting the Stage - Recon and Endpoint Discovery

When testing mobile applications, a strong habit is to route all app traffic through Burp Suite. This lets you monitor backend API calls and understand how different features interact with the server.

The researcher began by performing static and dynamic analysis of the Android app’s network behavior:

1. Extracted .js files from the APK using apktool.
2. Parsed the codebase for interesting URLs and endpoints.
3. Built a custom wordlist of potential API routes.
4. Fuzzed those endpoints with FFUF to find hidden or undocumented paths.

Command example:

ffuf -w custom-wordlist.txt -u https://www.redact.com/parents/application/v4/admin/FUZZ -mc 200,403,405

After several attempts, a curious response appeared for:

https://www.redact.com/parents/application/v4/admin/doRegistrationEntries

It hinted at registration functionality - but what happened next changed everything.

⚙️ Step 2: The Vulnerability - Password Reset via Registration

This endpoint, intended for user registration, had a fatal flaw:
It didn’t check whether the submitted email was already associated with an existing account.

That meant:

If you submitted an existing user’s email along with a new password, the system didn’t throw an error - it silently replaced the password.

Here’s the crafted payload that triggered the issue:

{
  "email": "victim@example.com",
  "password": "New@12345"
}

Upon sending this via POST, the response came back with:

{
  "success": 1
}

The researcher then logged into the victim’s account - no OTP, no verification, no challenge.
It was a total authentication bypass.

🧪 Step 3: Step-by-Step Reproduction (Educational Breakdown)

For learners and security engineers, here’s how the issue was reproduced ethically in a controlled test:

1. Intercept the app’s registration request in Burp Suite.

2. Identify the base endpoint pattern:
   https://www.redact.com/parents/application/v4/admin/FUZZ

3. Fuzz for hidden endpoints:
   Replace FUZZ with words like register, entries, new, create, doRegistrationEntries, etc.

4. Switch request method from GET to POST if you see a 405 Method Not Allowed.

5. Set headers properly:

   Content-Type: application/json
   

   HTTP

   Copy

6. Craft the payload using a known user’s email address.

7. Send the request - if you receive success: 1, the bug is confirmed.

8. Login using the victim’s email and the new password - access granted.

This exploit demonstrated a logic flaw in authentication flow - not a typical injection bug, but a broken trust assumption in the registration handler.

⚠️ Step 4: The Impact - Account Takeover via Simple API Call

This vulnerability gave complete control over any user’s account, provided their email was known.
In the context of a school-parent app, this meant potential exposure of:

• Student personal information
• Communication records
• Private schedules or school-related data
• Sensitive contact details

Since the affected endpoint was part of a production mobile API, the issue had both technical and privacy implications.

💥 Security Classification:

The researcher rightfully classified it as Critical, highlighting that password reset logic must be isolated and protected by user verification, not reused from registration endpoints.

🧰 Step 5: The Tools & Techniques Used

The discovery relied not on complex tooling but on smart reconnaissance and disciplined endpoint analysis.

By combining static extraction (APK) and dynamic fuzzing (Burp + FFUF), the researcher built a complete visibility map of the backend API.

🧱 Step 6: Developer Perspective - Why This Happened

The flaw stemmed from backend logic reuse.
The /doRegistrationEntries route was likely designed for onboarding, but its validation step didn’t differentiate between:

• New user creation, and
• Existing user password modification

This oversight turned a simple convenience endpoint into a critical security hole.

Here’s what likely went wrong (simplified pseudocode):

def register_user(email, password):
    user = db.find_user(email)
    if not user:
        create_user(email, password)
    else:
        # ❌ Flawed logic: Update password instead of throwing error
        user.password = hash(password)
        db.save(user)
    return {"success": 1}

Proper design should enforce uniqueness and block any attempts to reuse registered emails.

def register_user(email, password):
    if db.find_user(email):
        return {"error": "Email already registered"}, 400
    create_user(email, password)

🧠 Step 7: Responsible Reporting & Reward

The researcher responsibly reported the issue via HackerOne’s private bug bounty program.

Within days:

• The triage team acknowledged the bug.
• Developers patched the endpoint by enforcing unique email registration.
• All exposed accounts were reviewed and reset.

A week later, the researcher received an email notification:

“We appreciate your responsible disclosure.
The issue has been fixed. A $4,000 bounty has been awarded.”

That single API endpoint had been quietly granting attackers full access for months - now, it was locked down.

💡 Key Takeaways

🧩 Defensive Recommendations for Developers

✅ Backend Best Practices

Example Secure API Response

{
  "error": "Account already exists. Please use the password reset flow.",
  "status": "400 Bad Request"
}

🧠 Final Thoughts: The Power of Simple Observation

What makes this $4,000 story inspiring isn’t the bounty - it’s the simplicity.

No exotic exploit chains.
No complex payloads.
Just patience, curiosity, and attention to how APIs behave differently under fuzzed conditions.

This story reinforces a timeless truth in cybersecurity:

The biggest vulnerabilities often hide in plain sight.

Whether you’re a beginner or an experienced pentester, remember - every endpoint deserves a second look.

References

• OWASP Top 10: Broken Authentication
• HackerOne: API Vulnerabilities 101
• PortSwigger: Authentication Testing
• Bugcrowd University: Password Reset Flaws

Published on herish.me - turning real bug bounty reports into security education for everyone.