Security vulnerabilities

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/

When logging into https://admin.alwaysdata.com, the application issues a 302 redirect containing sensitive authentication parameters (user_id and token) directly in the URL.

This login URL can be reused multiple times, from any browser, any device, and any location, even after the user logs out. As a result, anyone in possession of this URL can gain full access to the victim’s account without credentials.

Affected Endpoint

https://admin.alwaysdata.com/login/?user_id={USER_ID}&token={TOKEN}

Vulnerability Class

Steps to Reproduce

https://admin.alwaysdata.com/

HTTP/2 302 Found
Location: /login/?user_id=425062&token=1767520125-e3a2cf1655e9da2b0a3f

https://admin.alwaysdata.com/login/?user_id=425062&token=1767520125-e3a2cf1655e9da2b0a3f

https://admin.alwaysdata.com/login/?user_id=425062&token=1767520125-e3a2cf1655e9da2b0a3f

Expected Behavior

Actual Behavior

Impact

Severity

Recommended Remediation

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

Title

Critical Exposure of alwaysdata.com User Credentials via Alien TxtBase (Plaintext Passwords, Emails & Phone Numbers)

URL

Multiple alwaysdata endpoints are present in the leak, including:

https://alwaysdata.com/

https://alwaysdata.com/fr/inscription

https://alwaysdata.com/fr/inscription/

https://alwaysdata.com/en/register

https://alwaysdata.com/en/register/

https://alwaysdata.com/en/signup/account/

https://alwaysdata.com/fr/signup/account/

https://alwaysdata.com/fr/signup/

https://alwaysdata.com/en/marketplace/bookstack/

Evidence spread across all uploaded LeakBase / Alien TxtBase HTML files.

Description

The uploaded Alien TxtBase datasets show large-scale exposure of alwaysdata.com account credentials, collected by infostealer malware that steals browser-saved logins.

Across all the files, there are hundreds of entries for alwaysdata.com, including:

Emails (Gmail, Hotmail, Yahoo, corporate domains, etc.)

Plaintext passwords

Nicknames / device usernames

Phone numbers in some entries

Direct registration and signup URLs on alwaysdata.com

Examples of leaked patterns (all values redacted here):

Email + password + registration link, e.g.:
Email: …@gmail.com / Password: Fahendrena / Link: alwaysdata.com/fr/inscription

5202727960

Password + nick + registration URL (no email), e.g.:
Password: Footballclub972 / Nick: nathanv / Link: alwaysdata.com

5202727960

Email + password + /en/register or /fr/signup/account URLs, e.g. multiple developer / project owner accounts

Entries including phone number and “App: alwaysdata.com” metadata

The data confirms that real alwaysdata.com user accounts, including hosting users, developers and small businesses, have their credentials exposed in plaintext in a public leak collection.

While the initial compromise is on user devices (infostealers), the effect is a direct, ongoing compromise of alwaysdata.com accounts, as the credentials are valid and can be reused by attackers at any time.

Impact

Severity: CRITICAL

1. Full Account Takeover (ATO)

Attackers can use any email/password pair from the logs to log into alwaysdata.com and:

Access hosting control panels for websites and apps

Modify or delete customer sites

Inject malicious content, phishing pages, or malware

Change account email, password, and billing details

Because passwords are in clear text, there is no need for cracking or guessing.

2. Website & Application Compromise

As alwaysdata is a hosting provider, compromised accounts may be:

Production sites for individuals, startups, and small businesses

Internal dashboards or admin panels

Hosted APIs or backends

This allows attackers to:

Deface or replace websites

Steal data from web applications

Use compromised infrastructure for further attacks (phishing, malware hosting, C2, etc.)

3. Reputational & Legal Risk

Leaked credentials include:

Emails

Passwords

In some cases, phone numbers

This exposes alwaysdata users to:

Identity theft

Targeted phishing

Credential reuse on other services

It may also create privacy and regulatory exposure for alwaysdata if not addressed (e.g., GDPR if EU users are affected).

4. Ongoing Automated Exploitation

Alien TxtBase:

Is widely shared through Telegram breach channels

Is integrated into OSINT and credential-stuffing tools

Is resold on dark-web marketplaces

This means alwaysdata.com accounts will be continuously targeted, not just once.

Evidence (Redacted)

Representative examples from the uploaded leak files (all real, but anonymized):

Email: <redacted>@gmail.com Password: Link: alwaysdata.com/en/register/

5202727960

Password: Nick: Powerbyte
Link: alwaysdata.com/fr/signup/account/

Email: <redacted>@hotmail.com Password: Link: alwaysdata.com/fr/inscription/

Email: <redacted>@gmail.com Telephone: <redacted>
App: alwaysdata.com

No raw passwords, emails or phone numbers are reproduced in this report.

Recommendation
Immediate

Force password reset for all alwaysdata.com accounts whose credentials appear in Alien TxtBase.

Invalidate active sessions and login cookies for those users.

Alert affected users and advise them to:

Clean their devices of infostealer malware

Change reused passwords on other platforms.

Short-Term

Implement breached-password protection:

Block login with passwords known to be exposed in public leaks (including Alien TxtBase).

Enforce or strongly encourage MFA for all alwaysdata accounts.

Add rate limiting and bot protection on login, signup and password reset endpoints.

Monitor for abnormal login patterns from known bad IP ranges or TOR exit nodes.

Long-Term

Move toward passwordless authentication (WebAuthn / security keys) for control-panel access.

Deploy continuous dark-web / Telegram breach monitoring for “alwaysdata.com” credentials.

Provide security guidance for customers (blog / documentation) on:

Risks of storing passwords in browsers

Infostealer malware

Using password managers and MFA.

Summary:

After enabling 2FA, during login the system asks for email, password, and then a valid 2FA code. When a valid 2FA code request is captured and sent through Burp Repeater, sending multiple parallel copies of the same request returns multiple valid 2FA responses for a single correct code. These valid responses can then be replayed at any time to bypass the 2FA challenge completely. As a result, an attacker can repeatedly access the account without entering any new 2FA code, fully bypassing the authentication layer.

Steps to Reproduce:

Enable 2FA on your account.

Log out and attempt to log in again.

Enter a valid email and password.

When the system asks for the 2FA code, enter a valid code and capture this request in Burp Suite.

Send the 2FA request to Burp Repeater and create multiple parallel copies.

Send all parallel requests simultaneously — observe that the server returns multiple valid 2FA success responses for one single valid code.

Now try logging in again: enter any invalid 2FA code.

Capture the invalid response and replace it with one of the previously captured valid parallel responses.

Forward the modified response — you will gain full account access without needing a new 2FA code.

This method works repeatedly.

Impact :

This vulnerability breaks the entire 2FA security model. By replaying the multiple valid responses generated from a single 2FA code, an attacker can repeatedly log in without providing any fresh 2FA code. This completely bypasses multi-factor authentication, rate limiting, and OTP expiration logic, allowing persistent unauthorized access to any protected account.

Note: Please don't disclose this report

Description: User A can raise a Closure Request to user B's task.

Steps to Reproduce: 1. Create two accounts A and B in Bug Tracking Interface.
2. From each account create a task.
3. Now turn of Burp Suite intercept, from account A click on "Request Closure" and enter a reason, then submit.
4. Change the task id of user A to user B's everywhere in the request, intercept response, then click forward.
5. Will see status code "200 OK" confirming the request has been made, turn off intercept.
6. Now go to account B see the request is successful and the reason is also added as shown in POC-4.png.

For any further information please let me know.

Regards,