Security vulnerabilities

  • Status Closed
  • Assigned To
    cbay
  • Private
Attached to Project: Security vulnerabilities
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

Closed by  cbay
08.08.2025 11:14
Reason for closing:  Invalid
08.08.2025: A request to reopen the task has been made. Reason for request: Hello, I’d like to kindly request a reconsideration of this report. The key issue is that the system blocks self-deletion in the UI, but allows it in the backend by changing the ID — which clearly indicates a logic flaw or missing access control. This allows an attacker with temporary access to an account to: Add their own email as a user, Bypass frontend restrictions using IDOR, Fully take over the project/domain. This isn’t just about “giving access” — it’s about bypassing intended system logic using a weak point in authorization checks. I’d be happy to provide a clear PoC video if needed. ,Best regards ebrahim
Admin
cbay commented on 08.08.2025 07:22

Hello,

Account A is no longer part of the project and has lost access.

It was account A's choice to remove its own permissions.

Account B now fully controls the project/domain (`aqaqwq.alwaysdata.net`) including settings, databases, and any hosted files.

That was the case when account A added all permissions to account B.

I don't see any issue here.

Kind regards,
Cyril

X_XO commented on 08.08.2025 10:48

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:

  I lost access to the entire project.
  I got a 403 error on /permissions/.
  The second account (Account B) became the full owner.

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing