- Status Closed
-
Assigned To
cbay - Private
Opened by asad - 22.11.2025
Last edited by cbay - 24.11.2025
FS#242 - Unauthorized Account Deletion via Cookie Manipulation
Description:
The /user/delete/ endpoint allows deleting an account by sending a POST request. By replacing the sessionid cookie with that of another user, it is possible to delete any user account without knowing their password or performing any authentication.
This indicates a broken authentication / session management vulnerability where the server blindly trusts the sessionid cookie for critical actions.
Steps to Reproduce:
1.Log in as the victim account.
2.Obtain the victim’s sessionid.
3.In another browser/session, log in as the attacker.
4.Capture the delete account request: POST /user/delete/
5.Replace the attacker’s sessionid in the Cookie header with the victim’s sessionid.
6.Send the modified request.
7.Observe that the victim account gets deleted.
“Note: An attacker can brute-force these session IDs with the help of AI.”
Impact:
An attacker can delete any user's account by guessing or brute-forcing session IDs and using them in the delete request.
*Any attacker with a valid sessionid can delete any user’s account.
*No password, no verification, no re-authentication.
*Leads to complete account loss and permanent data deletion.
Severity: Critical (P1).
Recommended Fix:
*Bind session to user identity server-side and reject modified session cookies.
*Require full re-authentication (password) for account deletion.
*Add strict CSRF validation and session consistency checks.
Screencast from 11-22-2025 06...
(8.35 MiB)
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
"My bug is different — it is an IDOR that allows deleting another user’s account.”
"this is not a same bug"
FS#17- Lack of password confirmation on account deletion"My bug is different — it is an IDOR that allows deleting another user’s account.”
"this is not a same bug"
FS#17- Lack of password confirmation on account deletion"My bug is different — it is an IDOR that allows deleting another user’s account.”
"this is not a same bug"
FS#17- Lack of password confirmation on account deletionIf you manage to steal the victim's cookie, it's not a bug.
Hello,
My report is not about “cookie stealing.”
It is about server-side trust of any supplied sessionid, which makes it an IDOR / Broken Authentication issue.
To clarify:
I did not steal a cookie.
I simply replaced my own sessionid with another valid sessionid, and the server accepted it without verifying user identity.
This means anyone who obtains or guesses a sessionid — even without account access — can delete any account.
FS#17is only about missing password confirmation.My report is about authorization bypass and session misbinding, which is a different and much more severe issue.
The vulnerability is not “cookie theft”; the vulnerability is the server accepting a forged session for a critical action.
This falls under:
Broken Authentication
Session Fixation / Session Misbinding
IDOR on sensitive endpoint
Critical ATO → Account Deletion
This is technically different from
FS#17.Thank you.
You cannot "guess" a sessionid as there are 10^62 combinations.
What do you suggest to not accept a "forged" session, in technical terms?
A “forged session” doesn’t mean guessing a sessionid.
It simply means the server is not binding the session to the authenticated user. Because of this, any valid sessionid can be swapped and reused to perform actions on another account.
Technical fixes to prevent this:
1.Bind session → user at login (proper server-side session binding)
Server should internally store something like: session.user_id = <logged_in_user_id>
2. For every sensitive action, enforce identity check
if session.user_id != authenticated_user.id:
3. Regenerate session on login + enforce session consistency
If the sessionid in the request does not match the identity stored server-side, invalidate it.
4. Implement session fixation resistance
Reject any session that was not legitimately generated by the server during login.
Short summary:
The issue is not about “guessing” a sessionid.
The real problem is session misbinding — the server accepts any valid sessionid for critical actions without verifying that the session actually belongs to the logged-in user.
This is a standard Broken Authentication vulnerability, not a duplicate of “no password confirmation.”
Best regards,
The session ID IS the authenticated user.
Anyway, your video doesn't show anything weird. If you steal a session ID, you gain access to the user.
Thanks for your reply. I understand your point.
I just want to clarify that my report is not about stealing a session ID, but about session misbinding / authorization bypass. The server blindly trusts any valid session for critical actions like account deletion.
For reference, Mozilla Firefox Accounts had the exact same type of vulnerability:
https://hackerone.com/reports/3154983
Their bug was also about the server not verifying that the session performing the deletion belongs to the account being deleted, which is the same root cause as my report.
Thanks again.
That report is totally different.