Security vulnerabilities

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.

A publicly accessible .git directory was discovered on the target domain https://security.alwaysdata.com. This vulnerability allows unauthorized users to download the entire Git repository, potentially exposing sensitive source code, configuration files, credentials, API keys, and historical commit data.

Affected Asset
FieldValueURLhttps://security.alwaysdata.com/.git/Domainsecurity.alwaysdata.comProtocolHTTPSVulnerabilityGit Repository Exposure

Technical Details
Vulnerability Description
The .git directory is a hidden folder that Git uses to store all version control information for a repository. When this directory is exposed on a web server, attackers can reconstruct the entire source code repository, including:

Complete source code files
Historical commits and changes
Developer information (names, emails)
Configuration files that may contain credentials
API keys, database passwords, and other secrets
Internal documentation and comments

Proof of Concept
Step 1: Access the exposed .git directory
curl -I https://security.alwaysdata.com/.git/ Step 2: Check for accessible Git objects
curl -s https://security.alwaysdata.com/.git/HEAD curl -s https://security.alwaysdata.com/.git/config curl -s https://security.alwaysdata.com/.git/index Step 3: Dump the repository using git-dumper or similar tools
bash# Using git-dumper
git-dumper https://security.alwaysdata.com/.git/ ./dumped_repo

# Alternative: Using wget
wget -r -np -nH https://security.alwaysdata.com/.git/ Step 4: Reconstruct and analyze the repository
bashcd dumped_repo
git checkout – .
git log –oneline

Impact Assessment
Confidentiality Impact: HIGH

Complete source code exposure
Potential credential leakage
Internal business logic revealed

Integrity Impact: MEDIUM

Attackers can study the code for additional vulnerabilities
Understanding of security mechanisms enables bypass attempts

Availability Impact: LOW

No direct impact on availability
However, discovered vulnerabilities could lead to service disruption

Business Impact

Intellectual Property Theft: Competitors or malicious actors can steal proprietary code
Credential Exposure: Hardcoded secrets may grant unauthorized access to databases, APIs, or third-party services
Further Exploitation: Source code analysis enables discovery of additional vulnerabilities (SQL injection, XSS, authentication bypasses)
Reputation Damage: Public disclosure of poor security practices
Compliance Violations: Potential GDPR, PCI-DSS, or other regulatory violations

Summary:

Hi team, hope you are doing well.

During security testing of the AlwaysData webmail service, I identified a vulnerability that allows an attacker to send emails while impersonating any AlwaysData user account (e.g., anyuser@alwaysdata.net) without authentication or authorization.

This flaw enables a malicious actor to fully spoof internal user identities via the webmail interface, making the emails appear legitimate and trusted.

Description:

Improper authorization in AlwaysData webmail allows an attacker to send emails on behalf of any registered @alwaysdata.net user without authentication, resulting in unauthorized account impersonation and loss of email integrity across the domain.

Severity:

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

7.5 High

Steps to Reproduce:

1. Open the AlwaysData webmail interface.(https://webmail.alwaysdata.com/?from_roundcube=1)

2.Navigate to the (https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=identities)

In the “Email” field, manually specify any valid AlwaysData email address
(e.g., victimuser@alwaysdata.net) that does not belong to the authenticated session.

3. Save it

4. Compose email select the victim mail.

5.Enter any recipient email address.

6.Send the email.

Observe that the email is successfully delivered and appears to originate from the impersonated AlwaysData user, despite no authorization or ownership validation.

Expected Result

The system should restrict the sender address to only the authenticated user’s own email identity.

Actual Result

Emails can be sent using any registered @alwaysdata.net address without authorization.

Poc:

Added short video poc for confirmation

(https://drive.google.com/file/d/1iJY5OQev2Uz2aDDTFBLw3hhnhvYT77xf/view?usp=sharing)

Impact:

This vulnerability allows unauthorized use of trusted @alwaysdata.net email identities, breaking sender authenticity and undermining the integrity and reliability of the AlwaysData email system.

Thanks

Summary: The application exposes the XML-RPC endpoint with the pingback.ping method enabled and accessible without authentication. This allows an unauthenticated attacker to supply an arbitrary external URL, causing the server to initiate outbound network requests.
This behavior was confirmed via an out-of-band DNS interaction using a controlled Burp Collaborator (OAST) domain, demonstrating a Server-Side Request Forgery (SSRF) condition.
Severity: High
Affected Component: •URL: https://blog.alwaysdata.com/xmlrpc.php
•Protocol: XML-RPC •Authentication: Not required
Vulnerability Type: •Server-Side Request Forgery (SSRF)
•XML-RPC Pingback Abuse
Description: The XML-RPC interface allows the pingback.ping method to be invoked without authentication. By providing a specially crafted request containing an attacker-controlled URL, the server performs a DNS resolution and attempts to connect to the supplied domain.
This behavior enables an attacker to coerce the server into making arbitrary outbound requests, which is the core condition of SSRF.
The issue was validated by observing a DNS lookup from the target server to a Burp Collaborator domain, confirming that the request originated from the vulnerable server itself.

Steps to reproduce: 1] Capture the request of this url in burp suite and send it to repeater
https://blog.alwaysdata.com/xmlrpc.php

2] add this injection in the burp suite repeater (add your own collaborator link)
<methodCall>

<methodName>pingback.ping</methodName>
<params>

<param>
<value>
<string>http://collaborator_link</string>
</value>
</param>

  <param><value><string>https://blog.alwaysdata.com/xmlrpc.php</string></value></param>
</params>

</methodCall>

3]Observe Out-of-Band Interaction
The Burp Collaborator server records a DNS lookup originating from the target server:
•Interaction Type: DNS
•Source IP: 185.31.40.97
•And other info
This confirms that the target server processed the supplied URL and initiated a server-side network request.

Impact: An attacker can abuse this vulnerability to:
•Force the server to make arbitrary outbound network requests
•Perform internal network reconnaissance (SSRF scanning)
•Bypass firewall and IP-based access controls
•Leak internal infrastructure behavior
•Abuse the server for reflected or indirect denial-of-service (DDoS) attacks
In certain environments, this may allow access to internal services not exposed to the public internet, increasing the risk of further compromise.

Mitigation: • Disable XML-RPC entirely if not required
• Disable the pingback.ping method specifically
• Restrict XML-RPC access to trusted IPs only
• Validate and allowlist outbound URLs
• Block arbitrary outbound DNS and HTTP requests from the application server

Regards, Vishal Sanjay Jadhav.
Ethical Hacker & Cyber Security Analyst.
vp666159@gmail.com

Summary The application fails to normalize Gmail addresses during signup. Gmail treats email variations involving dots (.) and plus tags (+) as the same address, but the website processes each variation as a unique account.

As a result, an attacker can register unlimited accounts using a single Gmail inbox, bypassing restrictions such as:

one-user-per-email
free trial limits
referral abuse
promo codes
account creation throttling
Proof of Concept (PoC)

Step 1 Sign up with a real Gmail address Email: kalihunter001@gmail.com → Receive verification code. Step 2 Sign up again using a dot variation Email: ka.lihunter001@gmail.com → Also receive confirmation email in the same inbox.

Impact An attacker can:

Create unlimited fake accounts
Abuse free trials or credits
Abuse referral or promo systems
Circumvent limits on number of accounts per user
Spam the system with mass-registered accounts
Evade anti-fraud mechanisms
Potentially escalate privilege in systems that trust email uniqueness
This is a Business Logic Vulnerability that can directly affect revenue, analytics, and operational integrity.

Recommendation (Fix) Normalize email addresses before storing or checking uniqueness:

Remove dots from Gmail usernames
Strip anything after + in the username
Convert to lowercase
Convert googlemail.com to gmail.com
Enforce uniqueness on normalized email
Example normalized form for all Gmail inputs: kalihunter001@gmail.com POC ATTACHED BELOW

Regards Kali Hunter

Target Application: https://help.alwaysdata.com/en/ (Search Function)
Date of Test: December 8, 2025
Tester: Abhishek V
Mail id: abhi18vedamurthy@gmail.com

Description: The search functionality of the test website is vulnerable to SQL injection. A classic payload (OR 1=1;–) was entered into the search field, and the application returned 94 results, indicating that the input was directly concatenated into a SQL query without proper sanitization or parameterization.

Steps to Reproduce:
1. Navigate to the target website.
2. Locate the search input field.
3. Enter the following payload with a space after the double – OR 1=1;–
4. Submit the search.
Observation: 94 results are returned, bypassing any intended filtering logic.

Impact Assessment
1. Risk Level: Medium to High depending what results are returned
2. Potential Impact:
a. Unauthorized data access
b. Data leakage or manipulation

Recommended Remediation
1. Input Validation and Escaping
2. Reject or sanitize unexpected characters in user input.
3. Rejecting the statements that have the syntax of SQL queries.

POC: Refer to the video attachment named SQLi