Security vulnerabilities

Hello Team,

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

Steps To Reproduce
1.SignUp with new alwaysdata account
2.Use email address adding with character like % or %0d%0a, account will be created and you will get a account validation

3.Even if you try now to login using same above email and password then you will get account validation message.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used

Thank You,

Waleed Anwar

Hello Security Team,

I would like to report a security issue identified while testing site configuration through the API.

Name of vulnerability:
Apache directive injection through vhost_additional_directives in site configuration API

Description:
The vhost_additional_directives field appears to accept Apache directive content without filtering. In testing performed on a site under my own account, a directive supplied through this field was applied to the generated virtual host configuration and became active on the hosted site.

A simple Alias directive was accepted and mapped a local file to a public path, indicating that directives provided through this field are interpreted by Apache as part of the site configuration.

Steps to reproduce:
Using a site under my own account, I sent the following PATCH request:

curl -u "<account>:<password>"
-X PATCH "https://api.alwaysdata.com/v1/site/<site_id>/"
-H "Content-Type: application/json"
-d '{"vhost_additional_directives":"Alias /readfile /etc/passwd"}'

After the configuration was applied, I accessed:

https://<test-subdomain>.alwaysdata.net/readfile

The response returned the contents of /etc/passwd. A screenshot showing both the request and the resulting response is attached for reference.

Impact:
This behavior suggests that directives supplied through the API may be applied without validation, allowing configuration changes beyond the intended scope of this field. In the tested case, it resulted in local file exposure through a web-accessible path on a site under my own account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/site/<site_id>/ HTTP/1.1
Content-Type: application/json

{
"vhost_additional_directives": "Alias /readfile /etc/passwd"
}

Observed response after visiting the configured path:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…

Remediation:
A possible remediation would be to validate or restrict directives accepted in vhost_additional_directives, allow only expected configuration directives, and reject directives that expose filesystem paths or alter request routing outside the intended use of this field.

Testing was limited to infrastructure associated with my own account. No destructive actions were performed, and only read verification was used to confirm the behavior.

Please let me know if any additional details would be helpful.

Best regards

Dear alwaysdata Security Team,

I hope this message finds you well. I am writing to submit a vulnerability report through your Bug Bounty program as outlined in your policy at https://www.alwaysdata.com/en/technical-specifications/bug-bounty/.

Vulnerability Summary
I have discovered a critical security misconfiguration involving a customer site hosted on your platform. An admin panel with default login credentials is publicly exposed, allowing unauthorized administrative access to the CMS installation.

Affected Assets
Domain: https://boidcms.alwaysdata.net

Admin Panel: https://boidcms.alwaysdata.net/admin

IP Address: http://1.92.94.174 (also hosts the same CMS)

Service: boidCMS installation on alwaysdata infrastructure

Discovery Details
Date of Discovery: March 13, 2026
Steps to Reproduce
Navigate to http://1.92.94.174/admin

Observe the login page which explicitly displays credentials:

text
Login Credentials:
Username: admin, Password: password
Enter the provided credentials (admin/password)

Observe successful authentication and redirect to https://boidcms.alwaysdata.net/admin

Full administrative dashboard becomes accessible with permissions to:

Create/Update/Delete content

Manage media files

Install/modify plugins and themes

Access system settings

Proof of Concept
I have attached screenshots documenting:

Screenshot 1: The login page at http://1.92.94.174/admin showing exposed credentials

Screenshot 2: Successful login redirect to boidcms.alwaysdata.net/admin

Screenshot 3: The admin dashboard confirming full access

Security Impact
An attacker exploiting this vulnerability could:

Gain complete control over the website

Deface or modify site content

Upload malicious files through media management

Install backdoor plugins for persistent access

Potentially leverage this access to probe other alwaysdata services

Use the domain for phishing or malware distribution

CVSS Assessment
Based on your scoring guidelines, I believe this qualifies as:

CVSS Score: 9.1 (Critical)

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Category: Access Control Issues / Broken Authentication

Please let me know if you need any additional information, clarification, or if you would like me to test a fix once deployed. I am happy to assist in any way to ensure this issue is properly addressed.

Thank you for maintaining a bug bounty program and for your commitment to platform security.

Best regards,

Actual Issue:

A user that does not have backup permissions is still able to access backup-related task and log details by replaying previously captured requests.

The following endpoints return backup-related information even after the user’s backup permission has been removed:

GET /task/<id>/detail/ HTTP/2
Host: admin.alwaysdata.com

GET /log/<id>/detail/ HTTP/2
Host: admin.alwaysdata.com

Since backup access is denied, the user should not be able to access any backup-related task or log information.

Steps To Reproduce

accountA@gmail.com

accountB@gmail.com

Security Impact.

Additional Notes

Steps to reproduce:

1. Navigate to https://www.alwaysdata.com/en/register/ and create 2 accounts, accountA@gmail.com, accountB@gmail.com

1. In accountA@gmail.com, invite accountB@gmail.com and grant it all access(this is so that we can capture the request to make testing easy.)

1. Login to accountB@gmail.com, click on advanced → backup recovery, fille in the necessary details and submit while proxying the traffic through burp.

1. In burp, identify the traffic to these endpoints and intercept.

Summary:
The alwaysdata.com implements Time-based One-Time Password (TOTP) authentication using Google Authenticator. However, it is possible to successfully authenticate using a previously used and expired OTP code. This indicates that the system does not properly invalidate used or expired OTPs, significantly weakening the security guarantees of two-factor authentication.

Steps to Reproduce

1.Navigate to: https://admin.alwaysdata.com/login/

2.Log in using valid credentials.(must be turn on 2fa on the account)

3.When prompted for Authenticator 2FA, enter a correct OTP code and complete login successfully.

4.Copy and store the OTP used in step 3.

5.Wait until the OTP expires in Google Authenticator and a new OTP appears.

6.Log out from the account.

7.Attempt to log in again using valid credentials.

8.When prompted for 2FA, enter the previously used and expired OTP code from step 3.

9.Observe: Authentication succeeds even though the OTP is expired and already used.

PoC:video attached

Expected Behavior
An OTP code should be valid only once.Expired OTPs must be rejected.Previously used OTPs must be invalidated immediately after successful authentication.

Actual Behavior
Expired and previously used OTP codes are still accepted.Login succeeds with replayed OTP values.

Impact
This vulnerability allows attackers to bypass two-factor authentication by reusing expired and previously used OTP codes, leading to unauthorized account access and potential account takeover.
Beyond direct security impact, exploitation of this issue can cause significant reputational damage to the company. Users expect 2FA to provide strong protection; a failure in its implementation may lead users to perceive the platform as insecure, resulting in loss of user trust, reduced confidence in the service, and potential customer churn. Additionally, if exploited at scale, this could expose the company to compliance, legal, and brand credibility risks.

Recommended solution
Enforce single-use OTP validation by immediately invalidating a TOTP code after successful authentication.Strictly verify OTP expiration time and reject any expired or previously used codes on the server side.Implement replay protection and ensure TOTP validation fully complies with RFC 6238, allowing only minimal clock skew.

Summary:
The application allows users to enable TOTP-based Two-Factor Authentication (2FA) for additional account security. However, when a user logs in using Google OAuth, the system completely bypasses the account’s configured TOTP verification. This allows anyone with access to the linked Google account to log in without providing the required TOTP code, effectively defeating the purpose of 2FA on the platform.

Steps to Reproduce
1.Create a valid account using Gmail at:https://www.alwaysdata.com/en/register/ 2.link the account with Google OAuth.
3.Enable Two-Factor Authentication (TOTP) in account settings.
4.Log out of the account.
5.Attempt to log in using email + password.Observe that the system correctly prompts for the TOTP code.
6.Log out again.
7.Attempt to log in using Google OAuth.
8.Observe that login is successful without being prompted for TOTP.No 2FA code needed.

PoC:video attached.

Expected Behavior:
TOTP-based 2FA should be enforced for all authentication methods, including OAuth logins. Users should not be able to access the account without successfully completing TOTP verification, regardless of whether they authenticate via password or Google OAuth.

Actual Behavior:
OAuth login completely bypasses the TOTP verification, allowing immediate access to the account. This effectively nullifies the additional security layer that the user explicitly enabled.

Impact
If an attacker gets access to the victim’s Google OAuth account they can log in to alwaysdata.com without TOTPT .This bypasses 2FA protection and allows full account takeover.The attacker can access sensitive data and change account settings.2FA security is completely defeated and the account can be fully compromised

Recommended Fix
Enforce TOTP verification after all authentication methods, including OAuth.Ensure OAuth login completes only the primary authentication step, requiring TOTP before creating a session.Implement centralized authentication middleware to check 2FA status before granting access.

admin = mysuperpassword

The application allows users to register and authenticate using Google OAuth.
However, when a user changes their email address, the application fails to properly manage the OAuth binding.

As a result, the original Google account remains permanently linked to the user account, even after the email is updated.

Steps to Reproduce

1- Register a new account using Google OAuth with: user1@gmail.com 2- Navigate to Account Settings
3- Change the email address to: user2@gmail.com 4- During this process, the application requires setting a new password,
resulting in two active authentication methods: Email & Password and Google OAuth
5- Log out
6- Log in again using Google OAuth with the original Google account

Actual Result

Login via Google OAuth succeeds
The original Google account still has full access
Email change and password setup do not affect OAuth access

Impact

Persistent unauthorized access
Full account takeover
Users cannot secure their accounts by changing email
High risk in cases of Gmail compromise or lost devices

Attack Scenario
Attacker gains access to the victim’s Google account
Victim changes the email to secure the account
Attacker continues logging in via Google OAuth
Long-term access without detection

Root Cause

OAuth identity is permanently bound to the account
Email changes do not trigger OAuth revocation
Missing OAuth lifecycle management controls

Recommended Fix

Revoke all OAuth sessions on email change
Require re-authentication and OAuth re-linking
Allow users to disconnect OAuth providers

Thank You,

Waleed Anwar

Description

There is a flaw in permission management within Alwaysdata’s Mailing system that allows the Owner role to remain associated with an old user identity even after the email address is modified, the user is deleted, and the domain is transferred to another account. This results in an attacker being able to retain full control over a Mailing instance linked to a domain that is now owned by the victim.

—

Steps to Reproduce

1. The attacker creates an Alwaysdata account (Account A).

2. Creates a Domain within the account and then creates a Mailing associated with this domain.

3. Creates an email user such as: a@example.com.

4. From the Mailing settings, grants the user a@example.com the Owner role.

5. From user management, modifies the email from a@example.com to b@example.com by intercepting the request (Burp) and sending the modified request.

6. After the modification succeeds, deletes the user b@example.com.

7. Transfers the domain to the victim’s account (Account B).

8. The victim receives the domain with an existing Mailing.

9. The attacker is able to access the Mailing management interface using the old identity a@example.com and still has the Owner role.

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

Impact

Full control of a Mailing that belongs to a domain the attacker does not own.

Full unauthorized access.

Compromise of the victim’s data confidentiality and integrity.

—

Suggested Fix

Add additional validation to prevent any Owners from existing outside the current domain owner’s account.

Hello Alwaysdata Security Team
I would like to report a security vulnerability.

Severity level: Medium

Target: https://admin.alwaysdata.com

Category: Business Logic Flaw

Summary
A business logic flaw was discovered in the user registration system that allows a single individual to register an unlimited number of free trial accounts using a single primary email address. This is achieved by exploiting the additional addressing feature (the "+" sign) in email providers like Gmail.

Reproduction Steps
Example accounts:
laminasi0390@gmail.com (Primary Account)
laminasi0390+2@gmail.com (Detected as a new account)
laminasi0390+3@gmail.com (Detected as a new account)

1. Register and log in to the first account (primary account) using the email address: laminasi0390@gmail.com. Activate the free trial.
2. Register a second new account using the email address: laminasi0390+2@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the second account. Verify it and note that the free trial is valid for this "new" account again.
3. Register a third new account using the email address: laminasi0390+3@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the third account. Verify it and note that the free trial is valid for this "new" account again.
4. Repeat the process with +4, +5, and so on.

Business Impact
1. Financial Loss: Users can continue to enjoy premium features without paying.
2. Resource Abuse: Server load increases due to serving duplicate accounts.
3. Abuse of unlimited free trials

Recommended Fixes
1. Remove Aliases: Identify the + signs and delete all characters between them up to the @ sign.
2. Normalize email formats
3. Enforce uniqueness on canonical email values.
4. Optionally, block email aliases if they are not supported.

Regards,
Muchamad Alfian

Hello Security Team,

During a security review, I identified a vulnerability on one of your subdomains that is running BoidCMS. The service is currently accessible using default credentials, which allows unauthorized access to the CMS panel.

After logging in, it is possible to upload HTML files to the server. The input fields (such as the description field) are not properly sanitized, allowing the injection of JavaScript code.
As a result, when the uploaded file’s URL is accessed, the injected script is executed, leading to a Stored Cross‑Site Scripting (XSS) vulnerability that affects any user who visits the link.

The root cause appears to be insecure default configuration, unrestricted HTML file upload, and lack of input validation.
For clarity and verification, I have attached a video Proof‑of‑Concept demonstrating the full exploitation flow.
This report is submitted responsibly and solely for remediation purposes.

Urls :
https://boidcms.alwaysdata.net/admin

Best regards,
saman

Severity: Critical (P1)

—

Summary

The Alwaysdata system suffers from a logic flaw in verifying domain ownership and handling the domain identifier (domain_id) during mailbox modification. This flaw allows an attacker to use an internal system domain identifier (alwaysdata.net) to create unauthorized local-parts on the Alwaysdata domain itself. As a result, this behavior can be abused to create paid subscriptions without billing (Billing Bypass) and to pre-register local-parts and link them to future subscriptions, leading to control over the primary email address of the subscription.

This root flaw leads to privilege escalation and bypass of financial and email security mechanisms, posing a critical risk to the platform infrastructure as a whole.

—

Vulnerability #1 – Unauthorized Paid Subscription Creation (Billing Bypass)

Description:

An attacker can modify the mailbox update request and change the domain_id value to the one belonging to the system domain alwaysdata.net. After that, they can create a subscription account using the created local-part and choose any paid plan, and the subscription will be created successfully without requesting any payment method or billing verification. This results in a complete bypass of the subscription system and obtaining paid features for free.

Steps:

1. Create a regular domain inside the account.

2. Create a mailbox on this domain.

3. Intercept the mailbox modification request using Burp Suite.

4. Change domain_id to 1 and set any local-part.

5. Send the request → a mailbox named name@alwaysdata.net appears.

6. Go to the subscription creation page.

7. Enter the same name and choose any paid plan.

8. Observe that the subscription is created without requesting payment details.

Impact:

Billing bypass, privilege escalation, and unlimited resource consumption.

—

Vulnerability #2 – Mailbox Local-Part Takeover on alwaysdata.net

Description:

The same flaw allows an attacker to reserve an unlimited number of local-parts on the alwaysdata.net domain. When any legitimate user later creates a subscription using one of these local-parts as the name, the subscription is linked to the pre-registered mailbox, making the primary email address of the subscription under the attacker’s control.

Steps:

1. Perform steps 1–5 from the first vulnerability to create a mailbox on alwaysdata.net.

2. Wait for another user to create a subscription using the same name.

3. Observe that the primary email address of the subscription is linked to the mailbox owned by the attacker.

Impact:

Control over the primary subscription email, interception of sensitive messages, and unauthorized access.

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

It is possible for an account to claim and reserve a domain name without proper ownership validation. Once claimed, the domain becomes unavailable for other accounts, including the legitimate owner.

This allows an attacker to block domains they do not own and potentially prevent legitimate users from using their domains on the platform.

  Create two alwaysdata accounts: Account A and Account B.
  From Account A, add a domain that I own (example: evil.com).
  Complete the domain claim process WITHOUT performing any real ownership verification (no DNS TXT / HTTP challenge).
  Observe that the domain is marked as reserved or claimed by Account A.
  From Account B, attempt to add the same domain.
  The platform refuses the domain, even though no ownership verification was completed.

Date: 12-01-2026
Researcher: Vinit Mevada
Severity: High - Critical

Hello alwaysdata Team,

I hope you are doing well. While performing a security assessment of your application, I identified a potential security issue related to the public exposure of the .git directory. Due to improper server configuration, the .git repository is accessible without authentication, which may lead to sensitive information disclosure.

Impact:

An attacker can download the complete Git repository, including source code and commit history.

Sensitive information such as configuration details, credentials, or API keys (if present in commits) can be exposed.

Access to source code enables attackers to analyze application logic and identify further vulnerabilities.

Disclosure of internal development information can result in intellectual property loss and increase the overall attack surface.

Steps to Reproduce:

Open a web browser.

Navigate to the following endpoint:

https://security.alwaysdata.com/.git/config

Observe that the .git directory or its internal files are accessible without authentication.

A screenshot of the accessible endpoint has been attached for reference.

email to contact - vinitharsh20@gmail.com

Vulnerable URL : https://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=

Parameter : server=

Payload : "autofocus onfocus=alert(document.domain) ======================
Reproduce… Visit this URL you get an XSS pop-up : https://phppgadmin.alwaysdata.com/phppgadmin/index.php?server=%22autofocus%20onfocus=alert(document.domain)%20

The application allows a logged-in user to change the account email address without requiring any verification of the new email address and without sending a notification to the original email owner. This behavior can be abused by an attacker to silently change the victim’s email address and perform account take over.

Vulnerability Type: Improper Account Management
Affected Functionality: Email change feature
Impact Severity: Medium

Steps to Reproduce:

1. Go to this following URL: https://admin.alwaysdata.com 2. Log in to a valid user account.
3. Navigate to Profile Settings.
4. Change the registered email address to Another email address(*You can use victim's email)
5. Submit the request
6. Observe that: No verification email is sent to the new email address and No notification or alert sent. 7. Now, Any attacker can enable 2MFA and lockout another email address even perform pre-account takeover.

Impact:

1. Account Lockout
2. Pre-Account Takeover

Recommendation:

1. Enforce mandatory verification for any email address change.
2. Send immediate security notifications to both the old and new email addresses.

Reference:

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

Description

The application allows users to upload files without properly validating the file content and type. An attacker can upload a malicious file (such as an HTML, SVG, or disguised image file) containing embedded JavaScript code. When the uploaded file is later accessed or rendered by other users, the malicious script executes in their browser context.

Because the payload is stored on the server and executed whenever the file is viewed, this issue qualifies as Stored (Persistent) XSS.

Impact

A successful Stored XSS attack may allow an attacker to:

Execute arbitrary JavaScript in victims’ browsers

Steal session cookies or authentication tokens

Perform actions on behalf of authenticated users

Deface application content

Deliver phishing payloads

Escalate to account takeover depending on session handling

This vulnerability affects all users who view or access the uploaded file, increasing its severity compared to reflected XSS.

Steps to Reproduce

Navigate to a file upload functionality.
Create a malicious file, for example:

<script>alert(document.domain)</script>

Save it as:

xss.pdf

Upload the malicious file through the application.

Access the uploaded file directly or via the application interface.

Observe that the JavaScript payload executes in the browser.

Hello Security Team,

I would like to responsibly disclose a security issue identified on your website.

Affected URL:
https://security.alwaysdata.com/.git/config

It appears that the .git directory is publicly accessible. This allows unauthenticated users to retrieve Git configuration files, indicating an exposed Git repository on the web server.

Issue Overview:
Public access to the .git directory exposes Git metadata such as repository configuration and structure. In some scenarios, this may allow an attacker to reconstruct the entire source repository and discover sensitive information (e.g., internal paths, credentials, remote URLs, or configuration history).

Impact:
An exposed .git directory may allow an attacker to:

Access the source code or intellectual property of the application

Discover internal file paths, branches, and historical changes

Potentially identify sensitive data such as keys or credentials if present

Facilitate additional targeted attacks or exploit development

Severity:
High

Suggested Remediation:

Block public access to the .git directory using server configuration (e.g., web server rules)

Remove the .git directory from the web root in production environments

Confirm that only necessary files are deployed in public‑facing assets

This disclosure is submitted in good faith and does not involve destructive testing.

Please let me know if you need any further information.

Kind regards,
Devansh Chauhan
Security Researcher
LinkedIn: https://www.linkedin.com/in/devansh-chauhan-b36b6a1b1/

Vulnerability Summary:- A critical security flaw has been identified in the AlwaysData Admin Panel that allows any logged-in user to permanently delete their account without any form of re-authentication, identity verification, or confirmation mechanisms.

This behavior violates standard security best practices and creates a serious risk of: Accidental account loss Malicious account destruction Irreversible data loss Abuse by attackers if session hijacking occurs

Steps to Reproduce:- Step 1 – Create an Account Visit the AlwaysData admin panel and create a new account: https://admin.alwaysdata.com/

Step 2 – Log In Log into your account using the created credentials.

Step 3 – Access Profile Page Navigate to the profile section: https://admin.alwaysdata.com/user/

Step 4 – Locate Delete Option On the top area of the profile page, you will see an option labeled: “Delete this profile”

Step 5 – Click Delete Click on Delete this profile, then proceed to the next step.

Step 6 – Account Gets Deleted Boom! Your account is immediately deleted without: Password re-entry Email verification OTP confirmation Security warnings Multi-step confirmation

Security Impact Permanent Data Loss –> Account and all associated data are erased instantly Session Hijacking Abuse –> Any attacker with temporary session access can wipe accounts No Recovery –> Deleted accounts cannot be restored Compliance Violation –> Fails to meet basic security & privacy standards

Why This Is Dangerous This allows single-click irreversible account deletion, which is extremely dangerous in modern web applications. Industry standards require: Password confirmation Multi-factor authentication Email verification links Grace periods before deletion None of these protections are present.

Recommended Fix AlwaysData should immediately implement: Mandatory password re-authentication Email/OTP verification Two-step deletion confirmation 24–72 hour grace period before permanent deletion

Severity: High
Due to public exposure of credentials, cryptographic secrets, and insecure runtime configurations.

Affected Component:
Django application configuration file: settings.py
Public GitHub repository (source code exposure)

Vulnerability Summary:
The application’s Django configuration file (settings.py) contains multiple sensitive secrets and insecure configurations that are publicly accessible via a GitHub repository. These include:
Hardcoded database credentials (username & password)
External database host information
Hardcoded Django SECRET_KEY
Debug mode enabled (DEBUG = True)
Although some configurations are commented, they are still exposed to anyone with access to the repository, which represents a serious security risk.

Description:
The Django SECRET_KEY, which is used for cryptographic signing and session security, is hardcoded in a publicly accessible repository.
SECRET_KEY = 'django-insecure-yt()50-c2ul547)8_eu$%@o7)-w=aj809ocuparihd#b+)_70w'

MySQL Database Credentials (Critical)

# DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.mysql',
# 'NAME': 'secu_bdd',
# 'USER': 'secu',
# 'PASSWORD': '<REDACTED>',
# 'HOST': 'mysql-polytech.alwaysdata.net',
# 'PORT': '3306',
# }
# }

Githuh Url: https://github.com/<REDACTED>
( you can check it

Also i have attached some pictures of it you can check it…..

Impact:
Unauthorized database access
Disclosure of sensitive user data
Data modification or deletion
Potential full application compromise
High likelihood of credential reuse across environments

Affected Endpoint: https://admin.alwaysdata.com/ Severity: Medium
Functionality: Database user provisioning
Affected Services: RabbitMQ, PostgreSQL, MySQL

Vulnerability Type
Race Condition
Business Logic Flaw
CWE: CWE-362 (Race Condition)

Description:
The application does not properly handle concurrent (parallel) requests during database user provisioning.
When multiple creation requests are sent in parallel, the backend processes them simultaneously without enforcing serialization, locking, or queuing. This allows multiple database users to be created at the same time, across several backend services.
Although duplicate names are correctly rejected, the system fails to restrict concurrent provisioning, resulting in uncontrolled creation of database users and triggering infrastructure-level actions.

Steps to Reproduce:
Log in to the admin panel.
Initiate database user creation.
Capture the POST request using Burp Suite.
Send multiple parallel requests (race condition).
When duplicate name validation occurs, change the username.
Immediately resend parallel requests.
Observe that multiple database users are created simultaneously.

Actual Behavior:
Multiple database users are created simultaneously.
Backend services execute provisioning tasks in parallel.
No locking or concurrency control is applied.

Impact
An attacker could:
Mass-create database users rapidly
Abuse provisioning workflows
Trigger repeated service restarts
Exhaust system or paid resources

Note: I have attached some pictures and video as a evidence so you can check it…..

Title: IDOR allows authenticated users to view other users’ action history entries

Summary
An authenticated user can view action history (audit log) entries belonging to other users by modifying the numeric identifier in the following endpoint:

https://admin.alwaysdata.com/log/{log_id}/detail/

The application does not verify ownership of the requested action history entry, resulting in horizontal privilege escalation and unauthorized read-only disclosure of user data.

Affected Endpoint

```
GET https://admin.alwaysdata.com/log/{log_id}/detail/
```

Proof of Concept (Steps to Reproduce)

1. Log in to `https://admin.alwaysdata.com` using a valid account.
2. Navigate to the History of actions page:

  

  https://admin.alwaysdata.com/log/
 
  

3. Click the 🔍 (details) icon for one of your own action history entries.
4. You are redirected to a URL similar to:

  https://admin.alwaysdata.com/log/11043498/detail/
  

5. Confirm that the displayed action history entry belongs to your account.
[Screenshot 1: My own action history entry]

6. Modify the numeric `log_id` value in the URL to another valid identifier:

  
 
  https://admin.alwaysdata.com/log/11040670/detail/
 

7. Observe that the application displays an action history entry belonging to another user, without any authorization error.

[Screenshot 2: Action history detail belonging to another user (email and IP address redacted)]

Observed Result
- The server responds with HTTP 200 OK - An action history entry belonging to a different user is displayed

The disclosed information includes:

- User email address
- IP address (IPv4 / IPv6)
- Authentication method (e.g. OAuth Google)
- Timestamp of the action
- Source of the action (Administration Interface)

Expected Result

Users should only be able to view their own action history entries.

Requests for action history entries not owned by the authenticated user should return:

- `403 Forbidden`

  or   

- `404 Not Found`

Impact

- Unauthorized read-only access to other users’ action history entries
- Disclosure of sensitive personal information (email addresses, IP addresses)
- Disclosure of authentication methods and account activity
- Horizontal privilege escalation - Violation of user privacy and confidentiality

Due to the predictable nature of the numeric identifier, this issue is enumerable in theory, although testing was intentionally limited to a minimal proof of concept in accordance with the program rules.

Vulnerable Assets
- Activity Log Module
- /log/{log_id}/detail/

Menu menus whose logs are accessible to limited access accounts:
1. https://admin.alwaysdata.com/site/configuration/
2. https://admin.alwaysdata.com/domain/
3. https://admin.alwaysdata.com/environment/
4. https://admin.alwaysdata.com/advanced/log/

Vulnerability Type
Broken Access Control

Vulnerability Description
In the test scenario, there are two types of accounts:
- Account A: Full access (Admin/Owner)
- Account B: Limited access
By design, account B does not have permission to view the system audit logs. The log menu is not available in account B's UI. However, by manually adding the URL path, account B can still access certain log details. By accessing the endpoint: /log/{id}/detail/
Account B successfully views audit log information without any authorization validation on the backend. This indicates that access control is only implemented at the user interface (UI) level, not the backend API.

Sensitive data accessible to account B includes:
1. Actions (Create, Update, Delete)
2. Objects (modified resources)
3. Users (accounts performing the actions)
4. Resources
5. IP addresses
6. Date and time
7. Change details (Detail)

Reproduction Steps
1. Log in using account B (limited access).
2. Ensure the audit log menu is not available in the UI.
3. Access the URL directly, for example: /log/11032585/detail/
4. Audit log details are successfully displayed even though the account does not have permissions.

Security Impact
1. Leakage of Sensitive Information
2. Reconnaissance for Advanced Attacks
3. Violation of the Principle of Least Privilege

Recommended Improvements
1. Implement authorization validation in the backend for each audit log endpoint.
2. Ensure that only roles with appropriate permissions can:
View log lists and Access log details
3. Avoid relying on UI restrictions as the sole security control.

Vulnerable Assets
- Activity Log Module
- /log/{log_id}/detail/

Menu menus whose logs are accessible to limited access accounts:
1. https://admin.alwaysdata.com/site/configuration/ 2. https://admin.alwaysdata.com/domain/ 3. https://admin.alwaysdata.com/environment/ 4. https://admin.alwaysdata.com/advanced/log/

Vulnerability Type
Broken Access Control

Vulnerability Description
In the test scenario, there are two types of accounts:
- Account A: Full access (Admin/Owner)
- Account B: Limited access
By design, account B does not have permission to view the system audit logs. The log menu is not available in account B's UI. However, by manually adding the URL path, account B can still access certain log details. By accessing the endpoint: /log/{id}/detail/
Account B successfully views audit log information without any authorization validation on the backend. This indicates that access control is only implemented at the user interface (UI) level, not the backend API.

Sensitive data accessible to account B includes:
1. Actions (Create, Update, Delete)
2. Objects (modified resources)
3. Users (accounts performing the actions)
4. Resources
5. IP addresses
6. Date and time
7. Change details (Detail)

Reproduction Steps
1. Log in using account B (limited access).
2. Ensure the audit log menu is not available in the UI.
3. Access the URL directly, for example: /log/11032585/detail/
4. Audit log details are successfully displayed even though the account does not have permissions.

Security Impact
1. Leakage of Sensitive Information
2. Reconnaissance for Advanced Attacks
3. Violation of the Principle of Least Privilege

Recommended Improvements
1. Implement authorization validation in the backend for each audit log endpoint.
2. Ensure that only roles with appropriate permissions can:
View log lists and Access log details
3. Avoid relying on UI restrictions as the sole security control.