Security vulnerabilities

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

Summary

A DOM-based Open Redirection vulnerability was identified on the target application. The issue allows an attacker to manipulate client-side JavaScript to redirect users to arbitrary external domains. This can be exploited for phishing, social engineering, or chaining into more severe attacks.

Affected URL https://www.alwaysdata.com%2f@evil.com/

Steps to Reproduce
Navigate to the following crafted URL:
https://www.alwaysdata.com%2f@evil.com/

Observe that the application’s client-side code interprets the encoded path (%2f) and @evil.com portion incorrectly.
The browser resolves the URL in a way that causes redirection to the attacker-controlled domain (evil.com).
This behavior occurs without server-side validation, indicating a DOM-based flaw.

Impact

Phishing attacks: Users can be tricked into believing they are visiting a trusted domain ( www.alwaysdata.com ) but are redirected to a malicious site.
Session hijacking: If combined with other vulnerabilities (e.g., cookie theft, XSS), attackers can escalate impact.
Reputation damage: Users may lose trust in the brand if exploited in phishing campaigns.

**Recommended Fix

Implement strict validation and sanitization of client-side URL parameters.
Use a whitelist of allowed redirect domains.
Encode and validate user-controlled input before processing in JavaScript.
Avoid relying on DOM methods (location, document.URL, etc.) without proper sanitization.

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

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

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

for furthur info please see the poc

Thank you
Anant

Description:

The /user/delete/ endpoint allows deleting an account by sending a POST request. By replacing the sessionid cookie with that of another user, it is possible to delete any user account without knowing their password or performing any authentication.

This indicates a broken authentication / session management vulnerability where the server blindly trusts the sessionid cookie for critical actions.

Steps to Reproduce:

1.Log in as the victim account.

2.Obtain the victim’s sessionid.

3.In another browser/session, log in as the attacker.

4.Capture the delete account request: POST /user/delete/

5.Replace the attacker’s sessionid in the Cookie header with the victim’s sessionid.

6.Send the modified request.

7.Observe that the victim account gets deleted.

“Note: An attacker can brute-force these session IDs with the help of AI.”

Impact:

An attacker can delete any user's account by guessing or brute-forcing session IDs and using them in the delete request.

*Any attacker with a valid sessionid can delete any user’s account.

*No password, no verification, no re-authentication.

*Leads to complete account loss and permanent data deletion.

Severity: Critical (P1).

Recommended Fix:

*Bind session to user identity server-side and reject modified session cookies.

*Require full re-authentication (password) for account deletion.

*Add strict CSRF validation and session consistency checks.

Hello Team,

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

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

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

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

Thank you

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

no task description

Hello Team,

Summary:
There exists a Race Condition in which the subscription are added multiple times which will make them unremovable. As you know, same subscription is not added in admin.alwaysdata.com, but through race condition same subscription can be added multiple time and admin can't remove that in which another user are created them.

Steps To Reproduce:

1. Go to https://admin.alwaysdata.com/transfer/add/?type=account.
2. Fill the form which have new owner(for e.g: example@gmail.com) and click on validate it.
3. Go to admin.alwaysdata.com and login your account example@gmail.com. 4. Then go to https://admin.alwaysdata.com/transfer/ and accept the transfer request and intercept the request on Burpsuite.

5.Make 10 to 15 request and group them to send it from repeater.
6. You can see that any subscription are added and if want to delete them you can't.

Impact
Irremovable/permanent subscription. Even the admin cannot remove that subscription in which another user created it in that account.

Thank You,

Waleed Anwar

Description: The registration page at https://www.alwaysdata.com/en/register/ requires mandatory credit card validation ("Validation par carte bancaire") to proceed, as noted in the warning: "Pour continuer l'inscription et afin de limiter les abus vous devez impérativement valider une carte bancaire." This is likely an abuse prevention measure.

However, the Google OAuth flow at https://www.alwaysdata.com/oauth/google/login/ allows bypassing this requirement. By signing in with a Google account and completing the CAPTCHA, I created a new account without providing or validating a credit card.

Steps to Reproduce: 1. Visit https://www.alwaysdata.com/en/register/.
2. Observe the mandatory credit card validation step ("Valider ma carte" button).
3. Navigate to https://www.alwaysdata.com/oauth/google/login/.
4. Sign in with a Google account .
5. Confirm the creation of a new account without credit card validation.

Impact: - This allows bypassing the intended abuse prevention mechanism, potentially enabling multiple free account creations without validation.
- The impact is limited to potential resource consumption (e.g., bandwidth, storage) if scaled, with no access to customer data or core platform architecture.

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

Steps to reproduce:

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

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

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

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

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

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

Suggestion for fix:

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

Description:
While testing the ticket feature in the support system, I noticed that the sender’s IP address is visible to all users participating in the same ticket. This behavior leads to an unjustified exposure of sensitive information and constitutes a violation of user privacy, as the IP address can reveal the user’s approximate location and service provider.

Steps to Reproduce:

1. Create a new support ticket.

2. Add another user to the same ticket.

3. Send a message from user account (A).

4. Observe that the IP address of user A appears next to the message and can be seen by the other user.

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

Impact:
Any participant in the ticket can view the IP address of other users.
This is a clear violation of user privacy and conflicts with data protection policies and laws.

Recommendation:
Hide the IP address from regular users and make it visible only to support staff or administrators.

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

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

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

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

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

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

No context-aware defense such as:

IP or ASN consistency checks

Browser/device fingerprinting

Geo-velocity anomaly detection

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

Summary:
The OAuth implementation relies solely on bearer tokens (RFC 6750). Bearer tokens act like “keys to the kingdom” — anyone holding them gets full access. Without Proof-of-Possession (PoP) or sender-constrained tokens, a stolen token can be reused by an attacker from any device, IP, or session.

Steps to Reproduce:

Log in to the alwaysdata.com application and obtain a valid bearer access token (e.g., via browser dev tools).

Replay the same token from a completely different environment:

Another browser,

Another machine,

Or a proxy/intercepting tool.

Observe that the API/service still accepts the token without verifying the device, TLS channel, or binding key.

Impact:

Token Replay Attacks: Stolen tokens from XSS, CSRF, or insecure storage can be reused by attackers.

Session Hijacking: An attacker can impersonate users indefinitely until the token expires/revoked.

High-Severity Risk: Any token leak = full account compromise.

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

Steps to Reproduce:

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

Navigate to the Change Password or Password Reset functionality.

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

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

Impact:

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

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

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

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

Security Best Practices Reference:

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

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

Recommendation:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Recommended Fixes
Enforce account-based throttling (primary)

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

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

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

Severity:
High

Summary:
OAuth account linking occurs automatically and implicitly on the company's web application, without requiring user verification, which can enable account takeover. Suppose an attacker signs up using OAuth with the same email as an existing account (registered via email/password). In that case, they are granted access to that existing account without any ownership validation, which is a critical authentication flaw.

Steps to Reproduce:
Create a target account (victim):

Go to alwaysdata.com

Register a new account using email/password, e.g., victim@example.com.

Log out.

Trigger the issue (attacker):

Go to the website

Log in using an OAuth provider (e.g., Google or Apple) that uses the same email address: victim@example.com.

Observe:

The OAuth login automatically links to the existing account created via email/password.

No verification (like password prompt, email confirmation, or user consent) is required.

The attacker now has full access to the victim's account.

Impact:
This vulnerability allows an attacker to fully compromise accounts by using an OAuth provider with an email address matching an existing account, without needing the victim’s password or any verification step.

Possible consequences:

Unauthorized access to personal data.

Tracking information leakage

Service misuse or device control.

Breach of privacy and user trust.

Recommended Fixes:
Do not auto-link OAuth accounts based solely on email.

Prompt the user for verification when an existing account with the same email exists (e.g., via:

Password input,

Email confirmation,

Explicit linking process in settings).

Provide clear UI/UX for account linking that ensures user intent.

Suggested CVSS (3.1) Score:
8.8 (High)

Attack Vector: Network

Attack Complexity: Low

Privileges Required: None

User Interaction: None

Confidentiality Impact: High

Integrity Impact: High

Availability Impact: Low

Regards,
Mehedi Hasan

Note: I was awarded a $500 reward for the same vulnerability reported to some other companies. They marked this as valid and attempted to fix the bug.

Summary:
Revoking an application's access via the OAuth provider's settings should terminate the session in the main application. However, users are still logged in if the session remains active despite the OAuth disconnection.

Steps to Reproduce:
01. Log in to alwaysdata.com using Google OAuth.
02. Let's say an attacker hijacked your OAuth session, or you logged in to another device not owned by you and forgot to log out from there after using the account, and you wanted to destroy the OAuth session there.
03. Go to the Google OAuth provider’s settings from your Google account and revoke the application’s access.
04. You will see that, even after the OAuth provider disconnects, the session remains valid and doesn't terminate.

Mitigation:
If a user’s OAuth access is revoked, force the application session to require re-authentication using OAuth. This ensures unauthorized sessions cannot continue.

Impact:
This flaw allows users or attackers with an active session to retain access even after OAuth access is revoked, creating a significant security risk and bypassing expected session termination mechanisms.

## Note: I was awarded $300 by reporting the same issue to some other companies and they accepted it and fixed it.

Summary:
It is possible to remain authenticated in the application even after deleting the identity account (email/SSO provider) used to log in, resulting in a user session that continues to function despite the underlying identity no longer being valid. This breaks the identity-assurance model and may allow long-term unauthorized access.

Steps To Reproduce:
01. Create an account in the alwaysdata.com application using any email/password registration.
02. Log in successfully and confirm access to protected features.
03. While the session remains active, open a new browser/tab and permanently delete the associated identity account (e.g., delete the Google account/email used to register).
04. Return to the application and refresh or continue using your session.
05. Observe that the application continues to function normally and the user retains complete access.

Impact:
01. Allows long-term access for a user whose identity has been destroyed, violating ownership-based trust assumptions.
02. Increases risk of orphaned sessions or unauthorized access

Recommendation:
01. Implement continuous/periodic checks to verify that the backing identity still exists.
02. Invalidate all user sessions upon account deletion response from the identity provider.
03. Force re-authentication if account verification fails.

Best Regards,
NH Limon

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

Hello Team,

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

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

#Steps to Reproduce:

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

Impact:

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

#Note:

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

Thank You,

Waleed Anwar

Bug Report — Critical: Registration & Instance Creation — T&Cs / Consent Bypass

Target: https://admin.alwaysdata.com Endpoint(s): /register (web-form POST), root / POST (form that registers/creates instances)
Reported by: Ritanshu Sharma
Testing header: X-Bug-Bounty: SecurityTester-RitanshuSharma-2025
Date: (attach your submission date when sending)
IP: 106.219.120.29
Executive summary (one line)

A critical business-logic vulnerability allows account registration and instance provisioning to succeed without server-side enforcement of Terms & Conditions / consent fields (contract_28, contract_36). The frontend requires checkboxes but the backend accepts requests where those parameters are omitted, empty, or tampered — enabling automated mass account/instance creation and creating major legal/compliance exposure.

Vulnerability classification

Type: Business Logic / Missing Server-side Consent Enforcement

CVSS (reported): 7.5 (High)

Auth required: None

Attack complexity: Low

Root cause

Server-side registration/instance-creation logic does not enforce required consent fields. Frontend checkboxes exist but backend validation is missing or bypassable; consent is not consistently persisted or validated before provisioning.

Proof of Concept (PoC) — exact requests tested
PoC A — Working example (with consent fields included)

This is the valid POST observed (raw headers + body):

POST / HTTP/2
Host: admin.alwaysdata.com
Cookie: django_language=fr; csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7
Content-Length: 164
Cache-Control: max-age=0
Sec-Ch-Ua: "Not)A;Brand";v="8", "Chromium";v="138"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://admin.alwaysdata.com Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://admin.alwaysdata.com/ Accept-Encoding: gzip, deflate, br
Priority: u=0, i

csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123&contract_28=on&contract_36=on

PoC B — Exploit (omit consent fields)

Send the same request body but remove contract_28 and contract_36. Result: registration / instance creation still succeeds.

curl example (exploit):

curl -k -v -X POST 'https://admin.alwaysdata.com/' \

1. H 'Host: admin.alwaysdata.com' \
2. H 'Content-Type: application/x-www-form-urlencoded' \
3. H 'Cookie: csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7' \
4. H 'Origin: https://admin.alwaysdata.com' \
5. -data 'csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123'

Observed behavior: The server responds as if registration succeeded (account/instance created). Screenshot and HTTP traces included in attachments.

Note: I used the csrftoken and sessionid values seen in the browser trace; exploit also succeeds when supplying a valid CSRF + session or when using other valid sessions in testing.

Additional tests to confirm scope

Submit POST from a curl client (no JS) — succeeds.

Submit POST with empty contract_28= or contract_36= — succeeds.

Submit POST to any other registration/instance endpoint (API or admin console) — behavior appears consistent (same lack of server-side consent check).

Check DB (see Audit queries) — many users exist without associated consent records.

Impact

Legal / Compliance: No recorded user consent → GDPR violations (no lawful basis under Article 6 for processing personal data), exposure to regulatory fines and complaints. Noncompliance with contractual terms can void protections.

Operational abuse: Automated mass account/instance provisioning → resource exhaustion, spam, abuse channels.

Business risks: Reputational damage, audit failures (SOC2/ISO27001), insurance/contractual risk, and potential litigation where users deny agreement to terms.

Reproduction evidence (attach when sending)

Screenshots of successful registration via exploit POST.

Video showing: form submission without consents → successful account/instance creation.

Raw HTTP request/response traces (attached).

Root-cause analysis (concise)

Frontend enforces checkbox UI but backend registration/instance creation handler(s) do not require or validate the presence/value of required consent parameters. Consent values are either not required for account creation, not stored, or not validated prior to resource provisioning.

Immediate remediation (apply within 24 hours)

Enforce server-side validation for required consent fields (contract_28, contract_36) in every code path that creates a user or provisions resources. If missing or false, return HTTP 400 with a clear error message. Do not proceed to create accounts or provision resources until consent is validated and persisted.

Persist consent records on acceptance: store {user_id, consent_key, consent_value, consent_version, timestamp, ip, user_agent, request_id}.

Temporarily enable rate-limiting + CAPTCHA on /register and any programmatic registration endpoints to reduce abuse.

Audit & quarantine: Identify accounts/instances created without consent; flag/quarantine them pending follow-up and retroactive consent collection.

Add monitoring/alerts for abnormal registration rates and missing consent storage events.