All Projects

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

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…..

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: 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,

Vulnerability
The password-reset endpoint https://admin.alwaysdata.com/password/lost/ accepts unlimited requests for any e-mail address without rate limiting, CAPTCHA, or cooldown.

Impact
- An attacker can flood any user’s mailbox with hundreds/thousands of password-reset e-mails
- Targeted denial-of-service against a specific user
- PTP (Password-reset Token Poisoning) & Password Reset Abuse
- Loss of trust and bypassing of normal security controls

Steps to Reproduce
1. Go to https://admin.alwaysdata.com/password/lost/ 2. Enter any valid e-mail address that has an alwaysdata account
3. Capture the request in Burp Suite / Intruder
4. Send it to Intruder, remove all payloads except the e-mail parameter
5. Start the attack with multiple threads
→ The victim instantly receives a flood of password-reset e-mails (see attached PoC video/screenshots)

Proof of Concept
(Attach your video or screenshots here – click “Choose File”)

Recommended Fix
Implement at least one of the following on the password-reset endpoint:
- Strict per-IP + per-e-mail rate limiting (e.g., max 3–5 requests per hour)
- CAPTCHA (hCaptcha/reCAPTCHA)
- Temporary account lockout after X attempts

Researcher: TrinityXploit

vulnerability name : open redirection

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

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

for furthur info please see the screenshot

Thank you
Anant