Account Deletion — Password Confirmation Bypass — bug bounty

We noticed that the account deletion feature sometimes requires a password before allowing the deletion, as a protection mechanism. For example, if an attacker steals a victim's session cookie and tries to delete their account, they should hit a password prompt and fail to complete the deletion.

Possible bypass approaches considered

• Response manipulation
• IDOR
• A third approach (explained below)

The Setup

In this scenario, the site relied on an id parameter for the deletion request. I tried IDOR first, but it didn't work, since the request also included a security token tied to the session. The request looked like this:

POST /users/1234
Host: example.com
id=1234&token=xxxxx&DELETE

POST /users/1234
Host: example.com
id=1234&token=xxxxx&DELETE

I considered swapping the id value, but that wouldn't work because of the token binding.

what happens if the id parameter is removed entirely? Would it delete every user on the platform? Would it throw an erroThe answer removing the id caused the site to automatically delete the currently authenticated user Without the need for a password

After the team's response, it became clear that the password check was only enforced at one specific step, before reaching the password confirmation form — and removing the id bypassed that step entirely.

## Additional Tests

I also ran additional tests:

1. Deleting the account after the session cookie had been active for 1 full day
2. Registering and deleting the account via the cookie alone, to confirm the cookie's validity/authority on its own

After reporting this, the team initially rejected it, stating that the behavior was tied to a temporary 5-minute window after login, and that the system would require a password again after that window expireThis explanation turned out to be incorrectct**, and I had proof across 3 videos covering different test scenarios.

Outcome

After about two days, the report was accepted and confirmed as a valid vulnerability.