- Status Closed
-
Assigned To
cbay - Private
Opened by X_XO - 08.08.2025
Last edited by cbay - 08.08.2025
FS#201 - IDOR lead to account takeover
Description:
There is a logic flaw in the permissions system. When a user is deleted through the /permissions/[id]/delete/ endpoint, the system does not properly check if the requester is allowed to delete that specific user.
By intercepting the request and changing the id value, a user can delete the main admin — even if they don't have permission to do so. This can lead to full account takeover if the attacker had added themselves earlier as a user
Steps to Reproduce:
1. Create a new account on alwaysdata with the following email:
`ebrahimmagdy517@gmail.com`
(will be referred to as the **primary account** / Account A)
2. Inside the admin panel, go to:
`https://admin.alwaysdata.com/permissions/`
3. Add a second email address as a team member/user:
`testhackers663@gmail.com` (will be referred to as (secondary account) / Account B)
4. Accept the invitation and activate Account B via the link received in email.
5. As Account A (ebrahimmagdy517@gmail.com), go to the Permissions panel again.
6. You will (see Account B) listed and a “delete” button next to it.
However, you **cannot delete Account A (yourself)** — which is expected.
7. Use Burp Suite to intercept the deletion request for Account B, for example:
POST /permissions/402834/delete/
8. Modify the ID in the request to match Account A’s ID (e.g.,402812 ):
9.Send the modified request. (It will succeed), even though you are trying to delete the owner of the project
10. As a result:
- Account A is no longer part of the project and has lost access.
- Account B now fully controls the project/domain (`aqaqwq.alwaysdata.net`) including settings, databases, and any hosted files.
Impact:
An attacker can exploit an IDOR vulnerability to delete the main admin account by modifying the user ID in a delete request. This leads to:
Full account and domain takeover
Loss of access for the original owner
Complete control over data, settings, and services
If an attacker gains temporary access to the admin’s email, they can add their own account, then remove the real owner — resulting in a critical security breach
Recommendation:
- Implement strict access control checks on the `/permissions/[id]/delete/` endpoint.
- Deny deletion requests for project owners, regardless of ID manipulation.
- Ensure server-side validation enforces user role & permissions.
- Consider using UUIDs or scoped IDs instead of numeric incremental IDs for more secure object references.
Proof of Concept (Video):
https://drive.google.com/file/d/1XMGLchHjj1Wl6EsgRPUZeniTexVCTJsb/view?usp=drive_link
Severity:Critical
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
Hello,
It was account A's choice to remove its own permissions.
That was the case when account A added all permissions to account B.
I don't see any issue here.
Kind regards,
Cyril
Hi Cyril,
Thanks for the reply.
Just to clarify — the issue is not that Account A chose to remove itself. In fact, the UI doesn't allow users to delete their own permissions, which shows that this action is intentionally blocked.
However, by manually changing the permission ID in the delete request, I was able to remove Account A (my own account), which shouldn't be allowed.
After doing that:
So the issue is a logic flaw: the backend doesn't properly check who is being deleted, allowing users to bypass the restriction and kick out project owners/admins.
This could lead to a full account takeover if an attacker gets temporary access to the admin account.
Let me know if you'd like a detailed PoC.
,Best
ebrahim